[continued from previous message]   
      
   information.  All functions would be either static to their files, or   
   declared "extern" in the appropriate header.   
      
   And for code like this that is already compiler-specific, I would also   
   want to see use of compiler extensions for additional static error   
   checking - at least, if it is reasonable to suppose a compiler that is   
   modern enough for that.   
      
   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.   
      
   > 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.   
      
   > 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 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, 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.   
      
   >> (As for the topic of this thread - Rust is getting steadily more popular   
   >> regardless of what anyone may think about the language, so it's own   
   >> newsgroup seems perfectly reasonable to me.)   
   >   
   > Fair point.  I changed the "Subject:" header to reflect the   
   > drift.   
   >   
   > 	- Dan C.   
   >   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)