4 ms·

This seems somewhat incoherent and is too focused on shallow claims about languages instead of trying to understand why the memory bugs happened in the first pl

This seems somewhat incoherent and is too focused on shallow claims about languages instead of trying to understand why the memory bugs happened in the first place. Are unsafe code blocks in Rust or C# okay? Presumably yes if there are good reasons to do so, sometimes it is necessary. But then as a matter of policy, why is Rust meaningfully different than something like using Valgrind with C++? Of course there are substantive differences from a developer's perspective. But just as a stressed or cynical C++ developer might give up on solving the Valgrind error, a similar Rust developer might give up fighting the borrow checker and add "unsafe" to their buggy code. A federal impetus to switch from C++ to Rust would seem to incentivize this laziness further. To be clear this isn't a criticism of Rust's design or implementation - demarcated blocks of unsafe code is pragmatic and sensible. The problem is how humans build software. In this sense I don't think we've really settled whether "rewrite the code in Rust" is actually safer than "redo our technical management to include automated memcheck testing and paired code reviews." At the very least, I don't think the latter is insufficient, and the feds are being too heavy-handed by making this about language recommendations. [If it were up to me I would rewrite it in Rust! Saying "the feds made me" is an excellent excuse :) But I don't like the feds making such strong recommendations/demands when I feel the facts are still quite murky. There simply haven't been enough case studies.] I also think the feds here (along with techies in general) are undervaluing formal specifications and underestimating the risk of undefined behavior.[1] Rust is very stable but it's not formally specified and until recently had known bugs in its very design, not merely in the rustc implementation. (I think those bugs finally got fixed this year.) Considering how cutting-edge Rust is I am sure there are other "theory bugs" somewhere. The point is that critical software also needs stability, and it is unwise to chase memory safety without considering the risks of being tied to an old version of a compiler, especially with unsafe code. Again: not saying that Rust is automatically bad because it isn't formally specified. But these issues should at least get lip service. [1] E.g. this fairly detailed document doesn't discuss this at all: https://www.cisa.gov/sites/default/files/2023-12/The-Case-for-Memory-Safe-Roadmaps-508c.pdf https://www.cisa.gov/sites/default/files/2023-12/The-Case-fo...

erik_seaberg 2y ago
Rust's borrow checker proves some invariants that the code always upholds. Valgrind only checks that this run hasn't triggered some undefined behavior so far, it's always possible that (ab)using it further or another run with different input might.
- aithrowawaycomm 2y ago
  > But then as a matter of policy, why is Rust meaningfully different than something like using Valgrind with C++? Of course there are substantive differences from a developer's perspective. I did not say they were the same or even equivalent, though I was sloppy with synecdoche and didn't specifically mean Valgrind. My point is that unsafe Rust without Valgrind is more dangerous than C++ with Valgrind, and the feds are not adequately considering this when thinking about how large organizations might rewrite their C++ applications. "We will rewrite it in 100% safe Rust" is guaranteed way to eliminate virtually all C++ memory errors. It does not follow that "we will rewrite it in 95% safe Rust, except for the tricky bits" will eliminate 95% of C++ memory errors.
  - Ygg2 2y ago
    > My point is that unsafe Rust without Valgrind is more dangerous than C++ with Valgind Your point is wrong is the issue. Doing unsafe Rust is harder – there is some syntaxic salt plus doing unsafe code in Rust requires different mindset. But it's also safer. Why? Because borrow checker is never turned off. Plus you get warning, lints, miri, clippy warning about your code being wrong. > It does not follow that "we will rewrite it in 95% safe Rust, except for the tricky bits" will eliminate 95% of C++ memory errors. Again, wrong. It should go like this "Rewrite in Rust will be memory safe (assuming we didn't bungle up the unsafe bits)". Compiler relies on you for checking the boundary between safe and unsafe. If that's correct, great. If not you only have to check like 5% of your codebase. Which is 20x less than 100%. Maybe I'm not a 20x developer. Which is a stark contrast to C++ you either write your safe abstractions and pray to God that others won't break, or you make Vec.pop be unsafe because you can't be bothered to return an Optional or null.
2y ago

erik_seaberg 2y ago

Rust's borrow checker proves some invariants that the code always upholds. Valgrind only checks that this run hasn't triggered some undefined behavior so far, it's always possible that (ab)using it further or another run with different input might.

aithrowawaycomm 2y ago
> But then as a matter of policy, why is Rust meaningfully different than something like using Valgrind with C++? Of course there are substantive differences from a developer's perspective. I did not say they were the same or even equivalent, though I was sloppy with synecdoche and didn't specifically mean Valgrind. My point is that unsafe Rust without Valgrind is more dangerous than C++ with Valgrind, and the feds are not adequately considering this when thinking about how large organizations might rewrite their C++ applications. "We will rewrite it in 100% safe Rust" is guaranteed way to eliminate virtually all C++ memory errors. It does not follow that "we will rewrite it in 95% safe Rust, except for the tricky bits" will eliminate 95% of C++ memory errors.
- Ygg2 2y ago
  > My point is that unsafe Rust without Valgrind is more dangerous than C++ with Valgind Your point is wrong is the issue. Doing unsafe Rust is harder – there is some syntaxic salt plus doing unsafe code in Rust requires different mindset. But it's also safer. Why? Because borrow checker is never turned off. Plus you get warning, lints, miri, clippy warning about your code being wrong. > It does not follow that "we will rewrite it in 95% safe Rust, except for the tricky bits" will eliminate 95% of C++ memory errors. Again, wrong. It should go like this "Rewrite in Rust will be memory safe (assuming we didn't bungle up the unsafe bits)". Compiler relies on you for checking the boundary between safe and unsafe. If that's correct, great. If not you only have to check like 5% of your codebase. Which is 20x less than 100%. Maybe I'm not a 20x developer. Which is a stark contrast to C++ you either write your safe abstractions and pray to God that others won't break, or you make Vec.pop be unsafe because you can't be bothered to return an Optional or null.

2y ago