2 ms·

And I think that illustrates my point well. Yes there is MISRA C++ and CERT for C when you write safety critical code. But that is a lot of extra rules to follo

And I think that illustrates my point well. Yes there is MISRA C++ and CERT for C when you write safety critical code. But that is a lot of extra rules to follow and remember (and have linting tools check where possible). It is basically a entirely separate dialect of the parent languages. And if you aren't doing safety critical you won't be dealing with these but have to come up with your own (company specific or individual) rules. (You dont want to write MISRA C++ unless you have to, large parts of it are quite miserable). In Rust I get good defaults, and a language that guides me in the right direction. The rules for safety critical rules are somewhat still under development but so far they look a lot shorter (you still need the "don't allocate in hard realtime tasks except at startup" and similar rules for example). And if you aren't doing safety critical you can safely use all of the language as long as you stay away from unsafe. And for most code you dont need unsafe, and even when you do someone else has likely done the hard work for you already, providing safe abstractions on top. (The exception is FFI to other languages, it is impossible to avoid unsafe when calling code in another language that the compiler can't reason about, you should build a safe Rust API on top of the raw bindings. For popular libraries this often already exists.)

uecker 14d ago
And my point is that "do not do low-level pointer arithmetic" is not really much harder to follow in practice than do not use "unsafe". In safety critical systems you may also care about panics, memory leaks, etc. I am not sure this is so simply in Rust as well. That you do not get safe libraries out-of-the-box in C is a major problem. But I also see the supply chain situation in the Rust world as highly problematic.
- VorpalWay 14d ago
  Two counterpoints: Searching for "unsafe" is a lot easier when you want to audit the code (there is even a lint you can enable to forbid all unsafe in a crate (library)). And there is a pervasive culture to avoid unsafe where possible and document all the unsafe you do have explaining why it is in fact ok. There are also experiments in formalizing the safety comments with attributes. To me the current prototypes look halfway towards formal verification, with unsafe functions specifying named requirements that must be upheld when calling them and the callsites needing to "discharge" them by name. Time will tell if this is a good idea for general code and it it catches on.
  - uecker 14d ago
    I agree that searching for "unsafe" is easier, we should have this in C too. I have some local patches to GCC that emit diagnostics for some things which are unsafe in C and were GCC does not already have a warning. I think the culture is an important point, the question is how this scales when the community becomes larger and then the share of well-paid enthusiastic Rust early adopers make way to tired, less interested developers that inherit a lot of code and have to get some things to work with limited time...

uecker 14d ago

And my point is that "do not do low-level pointer arithmetic" is not really much harder to follow in practice than do not use "unsafe". In safety critical systems you may also care about panics, memory leaks, etc. I am not sure this is so simply in Rust as well. That you do not get safe libraries out-of-the-box in C is a major problem. But I also see the supply chain situation in the Rust world as highly problematic.

VorpalWay 14d ago
Two counterpoints: Searching for "unsafe" is a lot easier when you want to audit the code (there is even a lint you can enable to forbid all unsafe in a crate (library)). And there is a pervasive culture to avoid unsafe where possible and document all the unsafe you do have explaining why it is in fact ok. There are also experiments in formalizing the safety comments with attributes. To me the current prototypes look halfway towards formal verification, with unsafe functions specifying named requirements that must be upheld when calling them and the callsites needing to "discharge" them by name. Time will tell if this is a good idea for general code and it it catches on.
- uecker 14d ago
  I agree that searching for "unsafe" is easier, we should have this in C too. I have some local patches to GCC that emit diagnostics for some things which are unsafe in C and were GCC does not already have a warning. I think the culture is an important point, the question is how this scales when the community becomes larger and then the share of well-paid enthusiastic Rust early adopers make way to tired, less interested developers that inherit a lot of code and have to get some things to work with limited time...