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.
this post was submitted on 28 Mar 2024
236 points (94.4% liked)
Rust
6137 readers
9 users here now
Welcome to the Rust community! This is a place to discuss about the Rust programming language.
Wormhole
Credits
- The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
This sort of violates what I've always heard about computer science. I've always heard logic is logic.
Hmm, yes and no. You can express a program that does anything in any language, but API design is as much about what can't be expressed (with that API) as what can. A well designed API lets you do the things that are desirable while making it impossible to do things that aren't. You can of course bypass APIs to do anything the language allows, even in Rust if you break out the unsafe blocks and functions there's pretty much nothing you can't bypass with enough effort, but you very much have to set out to not use the API to do that.
I think your quantifier of "any other language" is the issue. There are certainly languages with far more powerful type systems than Rust, such as Coq or Lean.
Maybe, although I'm not aware of any other language that has the same abstraction around ownership and lifetimes. Most other languages I'm aware of that have more (or equivalently) powerful type systems are also GCed languages that don't let you directly control whether something gets stack or heap allocated. Nor due they allow you to guarantee that a variable is entirely consumed by some operation and no dangling references remain. While at a high level you can write something that accomplishes a similar result in other higher level languages, you can not express exactly the same thing due to not having direct access to the lower level memory management details.
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.