Hacker News Reader

Comment by uecker | Hacker News Reader

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.

View on HN

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.

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...

Reply on news.ycombinator.com