[boris]

> There are however valid questions, like if Rust slows down your development say, 5%, would you get more net safety from spending 5% more time testing/fuzzing c++ code instead? etc.

I think a similarly valid question is how often you resorted to dynamic allocations just to get the borrow checker off your back. If your Rust version uses 5% more dynamic memory (with the corresponding performance and memory footprint penalty), is it perhaps worth staying with C/C++ and spending more development time on testing/fuzzing?

[duckerude]

Some people make the opposite claim: Rust lets you get away with less dynamic allocation (and more data shared between threads) because you can rely on the compiler checking your work.

The effect might be positive or negative depending on the circumstances.

[smolder]

If you're willing to jump back to C++ to get around the borrow checker strictness, couldn't you just use Rust's unsafe block where you're sure it won't result in a bug?

Is it harder to fuzz Rust? Honest question, because fuzzing is something I occasionally read about but am not practiced in.

[duckerude]

I've found it very easy to get started with fuzzing in Rust using cargo-fuzz. I didn't do anything very advanced, and my closest point of reference is testing Python with Hypothesis, but it did turn up bugs.

Here's a Rust fuzzing story from yesterday: https://hacks.mozilla.org/2022/06/fuzzing-rust-minidump-for-...

It claims that Rust is particularly suitable for it because integer overflow panics in debug builds (and out of bounds indexing always panics), which sounds reasonable.

[ttfkam]

> And what did we screw up? Some legit stuff! It’s Rust code, so I am fairly confident none of the issues were security concerns, but they were definitely quality of implementation issues, and could have been used to at very least denial-of-service the minidump processor.

This is so much better than the outcome would have been in any C or C++ project despite the many protestations of "just follow modern best practices" adherents. The author of minidump is no novice, is well versed in best practices in multiple languages including C++, was sure the code was solid, and still got spanked hard by the fuzzer. Denial of service outcomes aren't ideal, but they were likely fewer in number and are unambiguously better than security vulnerabilities.

[jackmott42]

That is a fair thing to wonder about, but at the moment most of the design decisions Rust pushes you toward tend to be better for performance on modern hardware. For instance using an array based arena to store a graph, instead of the traditional allocation of a chunk of memory per node on the heap. Or just keeping more stuff on the stack.

[jnordwick]

But it takes a lookup hit and you need an arena per object type with its memory overheard. You'll get more cache misses.

A lot of the rust performance talking points just aren't true. Rust is slower than C and C++, not by much but you can't get a true believe to even recognized this. Rust has turned into a religion.

Rust also disallows some things that you can do fine on C++ if you know our architecture because thing won't work on some machine 20 years ago (eg, it has more strict alignment requirements than any machine a consumer can see).

Throughput may only be 5% or more slower, but latency issues for rust is a much bigger issue. The devs I've talked to don't even try to pretend they have a good latency profile.