[continued from previous message]   
      
   exactly programming in C anymore, but some dialect defined by   
   your compiler and enabled extensions.  You limit portability,   
   and you create a future maintenance burden if you ever need to   
   switch to a different compiler.   
      
   As a counter-example, we did the Harvey OS a few years ago.   
   This was a "port" of the Plan 9 OS to mostly-ISO standard C11,   
   replacing the Plan 9 C dialect and Ken Thompson's compilers.  It   
   worked, and we made it compile with several different versions   
   of several different compilers.  This discipline around   
   portability actually revealed several bugs, which we could find   
   and fix.   
      
   >Now, I realise some of these are stylistic choices and not universal.   
   >And some (like excessive use of "int") may be limited by compatibility   
   >with Unix standards from the days of "everything is an int".   
   >   
   >None of this means the code is bad in any particular way, and I don't   
   >think it would make a big difference to the "code safety".  But these   
   >things do add up in making code easier to follow, and that in turn makes   
   >it harder to make mistakes without noticing.   
      
   That's fair, but if we're talking about how the language affects   
   safety of the resulting program, mostly stylistic changes aren't   
   really all that helpful.  Even using the sized types from e.g.   
   `stdint.h` only gets you so far: you've still got to deal with   
   C's abstruse implicit integer promotion rules, UB around signed   
   integer overflow, and so on.  For example, consider:   
      
       uint16_t mul(uint16_t a, uint16_t b) { return a * b; }   
      
   Is that free of UB in all cases?  The equivalent Rust code is:   
      
       pub fn mul(a: u16, b: u16) -> u16 { a.wrapping_mul(b) }   
      
   There's plenty of crazy C code out there from the days of "all   
   the world's a VAX" that we can pick on; safety wise, xv6 is   
   actually pretty decent, though.   
      
   >> I hear this argument a lot, but it quickly turns into a "no true   
   >> Scotsman" fallacy.   
   >   
   >Agreed - that is definitely a risk.  And it also risks becoming an   
   >argument about preferred styles regardless of the language.   
      
   +1e6   
      
   >> This is less frivilous than many of the   
   >> other arguments that are thrown out to just dismiss Rust (or any   
   >> other technology, honestly) that often boil down to, honestly,   
   >> emotion.  But if the comparison doesn't feel like it's head to   
   >> head, then propose a _good_ C code base to compare to Rust.   
   >>   
   >   
   >I don't know of any appropriate C code for such a comparison.  I think   
   >you'd be looking for something that can showcase the benefits of Rust -   
   >something that uses a lot of dynamic memory or other allocated   
   >resources, and where you have ugly C-style error handling where   
   >functions return an error code directly and the real return value via a   
   >pointer, and then you have goto's to handle freeing up resources that   
   >may or may not have been allocated successfully.   
   >   
   >Ideally (in my mind), you'd also compare that to C++ code that used   
   >smart pointers and/or containers to handle this, along with exceptions   
   >and/or std::expected<> or std::optional<>.   
      
   I feel like this has been done now, a few times over, with data   
   published from some of the usual FAANG suspects, as well as in a   
   growing number of academic conferences.  Then you've got things   
   like https://ferrocene.dev/en/ as well.   
      
   >I am totally unconvinced by arguments about Rust being "safer" than C,   
   >or that it is a cure-all for buffer overflows, memory leaks, mixups   
   >about pointer ownership, race conditions, and the like - because I   
   >already write C code minimal risk of these problems, at the cost of   
   >sometimes ugly and expansive code, or the use of compiler-specific code   
   >such as gcc's "cleanup" attribute.  And I know I can write C++ code with   
   >even lower risk and significantly greater automation and convenience.   
   >If Rust lets me write code that is significantly neater than C++ here,   
   >then maybe it worth considering using it for my work.   
      
   First, I think you are totally justified in being skeptical.  By   
   all means, don't take my (or anyone else's) word about the   
   language and what we express as benefits.  Indeed, I was   
   extremely skeptical when I started looking at Rust seriously,   
   and frankly, I'm really glad that I was.  I started from a   
   default negative position about the claims, but I did try to   
   give the thing an honest shot, and I can say with confidence   
   that it surprised me with just how much it really _can_ deliver.   
      
   That said, I am still not an unapologetic fan boy.  There are   
   parts of the language that I think are awkward or ill-designed;   
   it does not fix _all_ bug, or seek to.  I just think that, for   
   the application domain that I work in most often (kernel-level   
   code on bare metal), Rust is the best available language at this   
   time.   
      
   It is not my child, though: if another language that I felt met   
   the area _better_ suddenly showed up, I'd advocate switching.   
      
   But the contrapositive of skepticism is that one has to be open   
   to evidence that disconfirms one preconceptions about a thing.   
      
   So it's fine to be skeptical, but my suggestion (if you are so   
   inclined) is to pick a problem of some size, and go through the   
   exercise of learning enough Rust to write an idiomatic solution   
   to that problem, then maybe seek out some folks with more   
   experience in the language for critique.  That is, really dig   
   into a problem with it and see how it feels _then_.  I'd   
   honestly be a bit surprised if you came away from that exercise   
   with the same level of skepticism.   
      
   >First, however, the language and tools need to reach some level of   
   >maturity.  C++ has a new version of the language and library every 3   
   >years, and that's arguably too fast for a lot of serious development   
   >groups to keep up.  Rust, as far as I can see, comes out with new   
   >language features every 6 weeks.  That may seem reasonable to people   
   >used to patching their Windows systems every week, but not for people   
   >who expect their code to run for years without pause.   
      
   That is not accurate.   
      
   A new "edition" of the language is published about once every   
   three years (we're currently on Rust 2024, for instance; the one   
   before that was 2021, then 2018 and 2015).  A new stable version   
   of the compiler comes out every 12 weeks, with a beta compiler   
   every 6 weeks, I believe (I don't really follow the beta series,   
   so I may be wrong about the timeline there) and a nightly   
   compiler approximately every day.   
      
   Usually each beta/stable compiler promotes an interface that   
   _was_ experimental to being "stable", but usually that's   
   something in a library; you can only use the experimental   
   ("unstable)" interfaces from a nightly compiler.   
      
   Intefaces give you a means for long-term support.  We have code   
   that uses 2021 and 2018, and the language hasn't changed so much   
   that it breaks.   
      
   The tooling is very good, and I would argue superior to C++'s in   
   many ways (error messages, especially).  There is robust and   
   wide support in debuggers, profilers, various inspection and   
   instrumentation tools, etc; part of that is due to the wise   
   decision to (mostly) use C++-compatible name mangling for   
   symbols, and build on the LLVM infrastructure.   
      
   There are a number of very good references for the language; the   
   official book is available online, gratis:   
   https://doc.rust-lang.org/book/   
   (Disclaimer: Steve Klabnik is one of my colleagues.)   
      
   I'd say, give it a whirl.  You may feel the same, but you may   
   also be pleasantly (or perhaps unpleasantly!) surprised.  In any   
   event, I'd like to know how it turns out.   
      
   	- Dan C   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)