4 ms·

The advantage is actually pretty simple and I think this article overcomplicates it. The Rust community considers safety violations to be the language's fault

by dcow 5y ago

The advantage is actually pretty simple and I think this article overcomplicates it. The Rust community considers safety violations to be the language's fault not the implementer’s fault. In C++ if you violate the language spec then you’re and idiot who just blew their foot off. In Rust the people responsible for the project take it upon themselves to make sure that nobody blows their foot off. If you happen to cause UB in safe code, the community says “oops yeah we messed up how do we fix that”. This is a huge difference and the article alludes to it but I don't think the author states it clearly enough. Rust’s “hole problem” is that it forces developers to write safe code (conform to the language spec) up front which ultimately saves time and money. Developers are the audience and they want the best tools. Users want a hole (often as a means to an end, sure) and don’t care how it gets there; developers who make holes all day want the hole in the wall and not in their foot as frequently as possible.

treekogreen 5y ago
This is it right here, a similar analogy this brought up was car manufacturers of old making an excuse that fatalities were the idiot drivers fault and not because of the inherent lack of safety features of the vehicle. It's too damn easy to make the wrong assumption in C & C++ and spend a painful amount of time debugging. In my experience the added safety guarantees have made me more comfortable in "going faster" and back to vehicular terms the choice is still there to not fasten the seatbelt and go `unsafe`.
- deleted 5y ago
  [deleted]
littlestymaar 5y ago
For the record, the author is the lead of the Rust compiler team.
- dcow 5y ago
  Which we all appreciate. It doesn't mean the essay didn't turn out less articulate than it could be. It’s fair to critique writing regardless of the author’s credentials. The “hole” analogy is interesting but doesn't really serve to land a clear and coherent point as used by the author in my opinion.
- avgcorrection 5y ago
  That doesn’t matter if it is poorly written.
leshow 5y ago
That's well and good for safe Rust, but unsafe Rust is hard as hell to audit because nobody _really_ knows what the rules are. We're kind of still figuring out how to write unsafe Rust safely. Have a look at the "too many linked lists" book, which turns out to have had a fundamental error in it for years. I think miri is a part of the answer to this, but it is not perfect. At the end of the day, you need unsafe at some level to do anything useful, and we need more explicit rules about how to do it properly.
- avgcorrection 5y ago
  What was the Rustonomicon error?
  - steveklabnik 5y ago
    I think they're talking about https://github.com/rust-unofficial/too-many-lists/issues/213 https://github.com/rust-unofficial/too-many-lists/issues/213
  - leshow 5y ago
    not rustonomicon, https://rust-unofficial.github.io/too-many-lists/fifth-layout.html https://rust-unofficial.github.io/too-many-lists/fifth-layou... there are new sections that were recently added to this
- zozbot234 5y ago
  It should be at least no harder than modern C, where any undefined behavior is a license for the optimizer to outright ignore the code you actually wrote. The main practical difficulty stems from the fact that Safe Rust rules are fully in effect even in an unsafe block, so you need to assess where references can be used instead of general pointers etc.

by dcow 5y ago

treekogreen 5y ago

This is it right here, a similar analogy this brought up was car manufacturers of old making an excuse that fatalities were the idiot drivers fault and not because of the inherent lack of safety features of the vehicle. It's too damn easy to make the wrong assumption in C & C++ and spend a painful amount of time debugging. In my experience the added safety guarantees have made me more comfortable in "going faster" and back to vehicular terms the choice is still there to not fasten the seatbelt and go `unsafe`.

deleted 5y ago
[deleted]

littlestymaar 5y ago

For the record, the author is the lead of the Rust compiler team.

dcow 5y ago
Which we all appreciate. It doesn't mean the essay didn't turn out less articulate than it could be. It’s fair to critique writing regardless of the author’s credentials. The “hole” analogy is interesting but doesn't really serve to land a clear and coherent point as used by the author in my opinion.
avgcorrection 5y ago
That doesn’t matter if it is poorly written.

leshow 5y ago

That's well and good for safe Rust, but unsafe Rust is hard as hell to audit because nobody _really_ knows what the rules are. We're kind of still figuring out how to write unsafe Rust safely. Have a look at the "too many linked lists" book, which turns out to have had a fundamental error in it for years. I think miri is a part of the answer to this, but it is not perfect. At the end of the day, you need unsafe at some level to do anything useful, and we need more explicit rules about how to do it properly.

avgcorrection 5y ago
What was the Rustonomicon error?
- steveklabnik 5y ago
  I think they're talking about https://github.com/rust-unofficial/too-many-lists/issues/213 https://github.com/rust-unofficial/too-many-lists/issues/213
- leshow 5y ago
  not rustonomicon, https://rust-unofficial.github.io/too-many-lists/fifth-layout.html https://rust-unofficial.github.io/too-many-lists/fifth-layou... there are new sections that were recently added to this
zozbot234 5y ago
It should be at least no harder than modern C, where any undefined behavior is a license for the optimizer to outright ignore the code you actually wrote. The main practical difficulty stems from the fact that Safe Rust rules are fully in effect even in an unsafe block, so you need to assess where references can be used instead of general pointers etc.