4 ms·

There are parts of mozilla that will need significant rewrites anyways, and writing parts of those in Rust could be a win if they can keep the interfaces clean.

swsieber 4y ago
And they did that for a while; my understanding is that letting the rust language team didn't stop that, but that's mostly a guess.
tialaramex 4y ago
Right, the finding from Google's Android team was that security bugs tend to be in new code, and so therefore choosing a safe language for new code is a much bigger win than rewriting stuff that you weren't going to change otherwise and which might be fine.
- tadfisher 4y ago
  I hope they took into consideration a corollary: that new code often _exposes_ bugs in the old, by exercising untested code paths or just by breaking assumptions. When a bug arises this way, do you attribute it to the new code or the old? A good takeaway is that the old code should not have exposed paths that didn't yet have a consumer. I frequently fall into the trap of making my code too general to support future use cases, and this usually ends up being rewritten when those use cases are actually implemented, or the code is just dead for the lifetime of the project.
  - tialaramex 4y ago
    > When a bug arises this way, do you attribute it to the new code or the old? Rust has a hard rule here, if your code wasn't marked unsafe, but it can be (ab)used in a way which causes unsafety, then the code is wrong. If the code is marked unsafe, but the safety documentation misses a key requirement and as a result you can obey the documented safety rules and still get unsafe behaviour, that code or its documentation is still wrong. Thus in Rust it's never OK to say "You were using it wrong" on APIs unless they explicitly say they're unsafe and provide documentation on how to use them safely knowing that. Rust's sort() and sort_unstable() are trickier than the equivalents in the C++ standard library because a silly or erroneous Ord implementation like claiming to be Greater even than yourself is (stupid but) safe in Rust and must not induce unsafety in the sort() methods. In C++ 20 if your ordering constraints are bogus, you've got Undefined Behaviour immediately. Rust can't "correctly" sort six Ponies that all insist they're the Best Pony, but it can promise that attempting to sort them is safe. Obviously legacy code in a language with no hard rule about what's required may be more fraught, most C++ ought to be labelled "unsafe" but chances are it does not adequately document all the constraints on parameters etc. for safe use.
- woodruffw 4y ago
  I don't think this is necessarily wrong, but I wonder if there's a sampling bias here: the really good memory corruption bugs might tend to not be discovered for years, or have small variants that keep giving for years (because they're in legacy parts of the codebase, and the team lacks institutional knowledge to make comprehensive fixes). (Put another way: I entirely believe that rewriting old components in Rust might introduce more bugs, but might still be a net win in terms of decreasing vulnerability researcher value: 100 silly panicking overflow bugs are preferable to one "oops, underflowed the pointer and now the attacker has arb R/W at an address of their choice" bug.)
epolanski 4y ago
Rust compilations are also very much longer. Unless you can prove that you're getting clear benefits it may not be the best option. Also, they likely hire already top level C/C++ talent and they would require this talent to start adapting on something they are less proficient with.
- nindalf 4y ago
  > Rust compilations are also very much longer Longer than? C++? You might be interested in this post that shows they’re about the same - https://quick-lint-js.com/blog/cpp-vs-rust-build-times/ https://quick-lint-js.com/blog/cpp-vs-rust-build-times/
  - gpderetta 4y ago
    from your link: > Scaling beyond 17k SLOC [...] > C++ full builds scale better than Rust Chromium has millions of line of code not 17k, so, although the scaling test is fairly artificial, rust might get worse and worse as the project get bigger. Paradoxically, the stupid include model of C++ allows to extract more parallelism form the build. I wouldn't be surprised if C++ with modules has similar scalability behavior as rust though.

swsieber 4y ago

And they did that for a while; my understanding is that letting the rust language team didn't stop that, but that's mostly a guess.

tialaramex 4y ago

Right, the finding from Google's Android team was that security bugs tend to be in new code, and so therefore choosing a safe language for new code is a much bigger win than rewriting stuff that you weren't going to change otherwise and which might be fine.

tadfisher 4y ago
I hope they took into consideration a corollary: that new code often _exposes_ bugs in the old, by exercising untested code paths or just by breaking assumptions. When a bug arises this way, do you attribute it to the new code or the old? A good takeaway is that the old code should not have exposed paths that didn't yet have a consumer. I frequently fall into the trap of making my code too general to support future use cases, and this usually ends up being rewritten when those use cases are actually implemented, or the code is just dead for the lifetime of the project.
- tialaramex 4y ago
  > When a bug arises this way, do you attribute it to the new code or the old? Rust has a hard rule here, if your code wasn't marked unsafe, but it can be (ab)used in a way which causes unsafety, then the code is wrong. If the code is marked unsafe, but the safety documentation misses a key requirement and as a result you can obey the documented safety rules and still get unsafe behaviour, that code or its documentation is still wrong. Thus in Rust it's never OK to say "You were using it wrong" on APIs unless they explicitly say they're unsafe and provide documentation on how to use them safely knowing that. Rust's sort() and sort_unstable() are trickier than the equivalents in the C++ standard library because a silly or erroneous Ord implementation like claiming to be Greater even than yourself is (stupid but) safe in Rust and must not induce unsafety in the sort() methods. In C++ 20 if your ordering constraints are bogus, you've got Undefined Behaviour immediately. Rust can't "correctly" sort six Ponies that all insist they're the Best Pony, but it can promise that attempting to sort them is safe. Obviously legacy code in a language with no hard rule about what's required may be more fraught, most C++ ought to be labelled "unsafe" but chances are it does not adequately document all the constraints on parameters etc. for safe use.
woodruffw 4y ago
I don't think this is necessarily wrong, but I wonder if there's a sampling bias here: the really good memory corruption bugs might tend to not be discovered for years, or have small variants that keep giving for years (because they're in legacy parts of the codebase, and the team lacks institutional knowledge to make comprehensive fixes). (Put another way: I entirely believe that rewriting old components in Rust might introduce more bugs, but might still be a net win in terms of decreasing vulnerability researcher value: 100 silly panicking overflow bugs are preferable to one "oops, underflowed the pointer and now the attacker has arb R/W at an address of their choice" bug.)

epolanski 4y ago

Rust compilations are also very much longer. Unless you can prove that you're getting clear benefits it may not be the best option. Also, they likely hire already top level C/C++ talent and they would require this talent to start adapting on something they are less proficient with.

nindalf 4y ago
> Rust compilations are also very much longer Longer than? C++? You might be interested in this post that shows they’re about the same - https://quick-lint-js.com/blog/cpp-vs-rust-build-times/ https://quick-lint-js.com/blog/cpp-vs-rust-build-times/
- gpderetta 4y ago
  from your link: > Scaling beyond 17k SLOC [...] > C++ full builds scale better than Rust Chromium has millions of line of code not 17k, so, although the scaling test is fairly artificial, rust might get worse and worse as the project get bigger. Paradoxically, the stupid include model of C++ allows to extract more parallelism form the build. I wouldn't be surprised if C++ with modules has similar scalability behavior as rust though.