From: cross@spitfire.i.gajendra.net
In article <106apsa$2nju3$1@dont-email.me>,
David Brown wrote:
>On 29/07/2025 14:16, Dan Cross wrote:
>> In article <106a04v$2hiar$1@dont-email.me>,
>> Julio Di Egidio wrote:
>>> On 29/07/2025 00:18, Dan Cross wrote:
>>>
>>>> I'm not terribly interested in marketing slogans, to be honest.
>>>> "Safety" in this case has a very well-defined meaning, which may
>>>> not be the same as yours.
>>>
>>> Maybe you don't realise it, but you are *only* repeating
>>> the fake history and the fraudulent marketing slogans.
>>
>> Unsupported assertions coupled with a lack of engagement with
>> the material points under discussion are not persuasive. If you
>> disagree with any of my statements, you can engage with the
>> arguments in good faith and provide data.
>>
>> Or, if you prefer, how about a comparative study of a decently
>> large program, one version written in C, and the other in Rust?
>> Compare: https://github.com/dancrossnyc/rxv64 and
>> https://github.com/mit-pdos/xv6-public
>>
>> Otherwise, I suggest that you buckle up when you get behind the
>> wheel.
>
>I personally don't know enough Rust to make any reasonable comparison
>with other languages. I also think there is scope for all sorts of
>languages, and it seems perfectly reasonable to me for Rust to be
>"better" than C while also having C be "better" than Rust - different
>languages have their strengths and weaknesses.
I agree with this: modern C certainly has its place, and it
would be foolish to think that the many billions of lines of C
(or C++, for that matter) in existence today are simply going to
vanish and be replaced with well-written, idiomatic Rust
tomorrow.
But no one serious is suggesting that. What I think a number of
foks _are_ suggesting is that experience is proving that we get
better, less buggy results out of Rust than equivalent C.
>But one thing that bothers me is that Rust advocates almost invariably
>compare modern Rust, programmed by top-rank programmers interested in
>writing top-quality code, with ancient C written by people who may have
>very different abilities and motivations.
>
>Rust is the new, cool language - the programmers who use it are
>enthusiasts who are actively interested in programming, and talented
>enough to learn the language themselves and are keen to make the best of
>it. C, on the other hand, has been the staple language for workhorse
>tasks. The great majority of people programming in C over the decades
>do so because that's what they learned at university, and that's what
>their employers' pay them to write. They write C code to earn a living,
>and while I am sure most take pride in their jobs, their task is not to
>write top-quality bug-free C code, but to balance the cost of writing
>code that is good enough with the costs and benefits to customers.
>
>So it is an artificial and unfair comparison to suggest, as many Rust
>enthusiasts do, that existing C code has lots of bugs that could be
>prevented by writing the code in Rust - the bugs could be prevented
>equally well by one of those Rust programmers re-writing the code in
>good, modern C using modern C development tools.
You have a point that transcends any sort of Rust<->C debate.
Indeed, it is difficult to compare C'23 to C'89, let alone pre-
ANSI "typesetter" C, let alone the C that, say, 6th Edition Unix
was written in. Those are all very different languages.
That said, there are some things that are simply impossible to
represent in (correct, safe) Rust that are are known to be
problematic, but that you cannot escape in C. The canonical
example in the memory-safety domain is are Rust's non-nullable
reference types vs C pointers; the latter can be nil, the former
cannot. And while Rust _does_ have "raw" pointers (that can be
null), you have to use `unsafe` to dereference them. The upshot
is that in safe rust, you cannot dereference a NULL-pointer;
perhaps Andy Hoare's "billion dollar mistake" can be fixed.
>I also see little in the way of comparisons between Rust and modern C++.
Really? I see quite a lot of comparison between Rust and C++.
Most of the data out of Google and Microsoft, for instance, is
not comparing Rust and C, it's actually comparing Rust and C++.
Where Rust is compared to C most often is in the embedded space.
> Many of the "typical C" bugs - dynamic memory leaks and bugs, buffer
>overflows in arrays and string handling, etc., - disappear entirely when
>you use C++ with smart pointers, std::vector<>, std::string<>, and the
>C++ Core Guidelines. (Again - I am not saying that C++ is "better" than
>Rust, or vice versa. Each language has its pros and cons.)
And yet, experience has shown that, even in very good C++ code
bases, we find that programs routinely hit those sorts of
issues. Indeed, consider trying to embed a reference into a
`std::vector`, perhaps so that one can do dynamic dispatch thru
a vtable. How do you do it? This is an area where C++
basically forces you to use a pointer; even if you try to put a
`unique_ptr` into the vector, those can still own a `nullptr`.
>So while I appreciate that comparing these two projects might be more
>useful than many vague "C vs. Rust" comparisons, it is still a
>comparison between a 10-20 year old C project and a modern Rust design.
>
>The most immediate first-impression difference between the projects is
>that the Rust version is sensibly organised in directories, while the C
>project jumbles OS code and user-land utilities together. That has,
>obviously, absolutely nothing to do with the languages involved. Like
>so often when a Rust re-implementation of existing C code gives nicer,
>safer, and more efficient results, the prime reason is that you have a
>re-design of the project in a modern style using modern tools with the
>experience of knowing the existing C code and its specifications (which
>have usually changed greatly during the lifetime of the C code). You'd
>get at least 90% of the benefits by doing the same re-write in modern C.
Not really. rxv64 has a very specific history: we were working
on a new (type-1) hypervisor in Rust, and bringing new engineers
who were (usually) very good C and C++ programmers onto the
project. While generally experienced, these folks had very
little experience with kernel-level programming, and almost none
in Rust. For the OS bits, we were pointing them at MIT's course
materials for the 6.828 course, but those were in C and for
32-bit x86, so I rewrote it in Rust for x86_64.
In doing so, I took care to stay as close as I reasonably could
to the original. Obviously, some things are different (most
system calls are implemented as methods on the `Proc` type, for
[continued in next message]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
