From: cross@spitfire.i.gajendra.net   
      
   In article <106lbus$155i0$1@dont-email.me>,   
   David Brown   wrote:   
   >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:   
   >>> [snip]   
   >>> 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").   
      
   Oh, many people are saying it, and they are even saying it   
   seriously, but they are not serious people.  By which I don't   
   mean people who are serious about replacing C with Rust, but   
   rather, people who are serious in the sense of being both   
   qualified and having the judgement to understand the tradeoffs.   
      
   Given those definitions, I maintain what I said: no one who is   
   serious is actually suggesting that we just dump all C code in   
   the world and replace it with Rust.  Ok, maybe a few are, but I   
   think those people mean on an extremely long timeframe, measured   
   in decades, at a minimum.   
      
   >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).   
      
   I agree with all of the above points.   
      
   Well, I don't know about encouraging folks to quit; some folks   
   may realize it's not for them and opt out, but I kind of look at   
   someone who struggles to become a competent programmer as a   
   failure of that person's mentors, teachers, managers, and so on.   
      
   That's a topic for another time, though.   
      
   >(To be clear, I am not saying that /you/ are claiming Rust is anything   
   >like that.)   
      
   No problem; I understood 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.   
      
   Agreed.   
      
   >> 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),   
      
   Oops! Thanks.   
      
   >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 write a lot of low-level Rust code, and I don't think that's   
   quite accurate.  Using unsafe at all?  Sure, but canonically one   
   still tries to minimize it, and wrap it up in a safe interface.   
      
   Of course, in real world low-level code, we have to do things   
   like manipulate machine and device registers, manipulate address   
   spaces, write memory allocators, and so forth.  Some amount of   
   `unsafe` code is generally going to be required.  And this is   
   qualitatively different than those writing (say) userspace code,   
   but even there, we need to do things like invoke system calls,   
   write memory allocators, and deal with `mmap`.  But it doesn't   
   follow that every other line is `unsafe`, or that `unsafe` in   
   low-level code needn't be significantly more common than in high   
   level code.   
      
   Here's a somewhat trivial example; this is the code for writing   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)