From: david.brown@hesbynett.no
On 29/07/2025 20:27, Dan Cross wrote:
> 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.
>
Actually, I think many people /are/ suggesting that Rust be used instead
of C as though it were a clear and complete "upgrade" and that those who
write C today should switch to Rust and magically create "safer" code
(for some value of "safer").
Now, I /do/ think that many people who write C code today could write
code that is substantially better code (fewer bugs, more efficient
development, or other metrics) if they used different languages. (I
also think the software world could benefit if some people stopped
programming altogether.) I don't see many areas for which C is the
ideal choice of language for new code.
But I don't think Rust is the magic bullet that a number of its
advocates appear to believe. I think many of those C programmers would
be better off switching to C++, Python, or various other languages (with
Rust being included as one of those).
(To be clear, I am not saying that /you/ are claiming Rust is anything
like that.)
>> 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.
Yes, I agree with that. Languages have changed over the last few
decades, even when within the confines of just a single nominal language
(like "C", "C++", "Python", or any other living language). The way we
use languages, and what we do with them, has also changed - again, even
if you simply stick to a single language variant (such as C90). And the
tools have changed hugely too.
>
> 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.
>
That is all true (other than Tony Hoare's name), and it is definitely
one of Rust's many positive features. However, it is easy to exaggerate
the importance of this for many reasons:
1. As I understand it, "unsafe" Rust code is common, especially in
low-level code. I think it is a good thing to have the separation of
"safe" and "unsafe" code, and isolating riskier coding techniques is
beneficial. But perhaps rather than dividing a Rust program into "safe"
and "unsafe" parts, it would be better still to divide the program into
low-level efficiency-critical code written in C, and write the majority
of the code in a higher level managed language where you don't really
have pointers, or at least where any bugs in pointer-style concepts
would be caught immediately. Again, I am not saying Rust's philosophy
is bad here, merely that there are alternatives that could be better and
Rust's benefits are often over-sold.
2. It is perfectly possible to write C code without having errors due to
[continued in next message]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
