246
Productivity of Rust teams at Google
(programming.dev)
Slide with text: “Rust teams at Google are as productive as ones using Go, and more than twice as productive as teams using C++.”
In small print it says the data is collected over 2022 and 2023.
See this example for Scala:
https://blog.tmorris.net/posts/scala-exercise-with-types-and-abstraction/index.html
Now go further and say you can't compile a call that leaks memory, or things like that.
Disclaimer: I don't know Rust so can't verify the claim. All I can say is it sounds somewhat plausible.
You can leak memory in Rust if you want to (and it's occasionally desirable). What the type system prevents is mainly accessing memory that has been deallocated. The prevention of memory leaks uses RAII just like C++. The main difference related to allocation is that there's no "new" operator; you can pretty much only allocate memory through the initialization of a smart pointer type.
I'd argue it also prevents you from accidentally leaking memory. You have to be pretty explicit about what you're doing. That's true for pretty much anything in Rust, every bad thing from C/C++ is possible in Rust, you just have to tell the compiler "yes, I REALLY want to do this". The fact that most of the really dangerous things are locked behind unsafe blocks and you can set the feature flag to disable unsafe from being used in your code goes a long way towards preventing more accidents though.
I agree Rust makes it virtually impossible to leak memory by accident. The difference I wanted to point out is that leaking memory is explicitly not considered unsafe, and types like Box have a safe "leak" method. Most "naughty" things you can do in Rust require using the "unsafe" keyword, but leaking memory does not.
Cyclic reference-counted pointers are the most probable way to accidentally leak memory. But it's a pretty well known anti-pattern that is not hard to avoid.
Yeah, I didn't think of that case, because any time I use ref counting, cyclic references are at the from of my mind.