Comment by ModernMech
6 months ago
The thing about Rust is you pay for everything up front, and the dividends come later. You pay first to learn it, which is not easy. Then you pay every time you have to compile your code, which can kill development momentum. When you are learning, often times this manifests as a moment where you have to completely rearchitect your approach because plowing forward is too costly. It's at this point a lot of people say "Rust is too hard!" and they give up.
But if you stick it out, as Google has, the dividend is that more often than with other languages, you are not paying these costs continually but instead reaping dividends on the long run.
First of all, Rust has the Haskell-like property that (as long as the logic is sound) if your code compiles, it usually runs just fine. This is why testing speeds up, because all of the edge cases that are explored during testing were already accounted for by the compiler.
It also translates into easier refactoring, where you can make sweeping changes in the codebase and feel confident that you can put it all back together again.
And then there's the fact that the programs themselves are fast. How many times has uv been brought up here and the #1 remark people have is "wow it's so fast!". Fast is a feature, and your users benefit from it every time they run your code.
It's hard to find that nexus of features in other languages. Usually they are just as fast and hard to write as Rust, without the safety guarantees. Or they are just as safe as Rust, but without the speed. And that's why Rust has hit a sweet spot where other languages can't quite get it.
Yeah, I use Rust at work and it's a boon.
It's so easy to bake in proofs/invariants into types, yet you still retain control of the memory model.
One of the main features of Rust is the community, there are so many great packages
Something that will replace/build on Rust in the future is a language based on Two Level Type theory, where you have zero cost abstractions with a language that can do full dependent type theory
I'm glad you said that because that's exactly where my research is ^_^
https://andraskovacs.github.io/pdfs/2ltt_icfp24.pdf
I think that something like this is the endgame practical programming language
I think Rust is easier to learn than C++
I agree with you as long as you don't know C++ first. I actually teach C++ and Rust to students who only know Java, and they have a much easier time picking up Rust. It's the people who approach Rust with C++ idioms who have the wort time with it. It comes down to the tooling, especially Cargo being the one-stop-shop for everything Rust. Another poster here laments that Cargo is too overloaded with disjoint functionality, but that's actually a benefit for a lot of learners.
I think tooling is big and people underestimate the lingering cognitive overhead of simply building C++ with arcane CMake files, but honestly it's more that much of Rust is informed by problems in C++ that they didn't have to inherit and don't have to maintain forever.
Like for example, how many ways are there to initialize a variable in C++? Which are you supposed to use?
C++ is the hardest, most difficult programming language to write correct (according to spec, not in the ‘it compiles’ sense) programs in ever created that isn’t a toy or specifically designed to be hard like malbolge. It takes a decade of writing it daily to realize that you know nothing, precisely because the compiler does not reject so many invalid programs.
>if your code compiles, it usually runs just fine.
This was the same argument for Java, which is memory safe, fairly strict in terms of ownership.
The fact is, Rust addresses only one memory safe thing, and that is double free. If you don't understand why that is, you probably shouldn't talk about memory safety.
The dividends never get there if you don't ever run into this.
>And then there's the fact that the programs themselves are fast. How many times has uv been brought up here and the #1 remark people have is "wow it's so fast!"
This is a vibe at best. The speed difference is surely there. But it makes very little difference when there are much slower things in the entire workflow, like pulling things from the internet.
Basically, Rust is a good choice for a small subset of things. Android happens to be one of them, because a) you need native code performance, b) you have multiple teams working on many services and c) you have a somewhat closed ecosystem where you control a lot of the low level things. Because of all of this, double frees are a real threat and can pop up as you are passing data around without strict checks.
> The fact is, Rust addresses only one memory safe thing, and that is double free. If you don't understand why that is, you probably shouldn't talk about memory safety.
How does Rust not address use after free?
Not to mention out-of-bounds access, uninitialized memory, invalid type casting, and a ton of insidious sources of undefined behavior
1 reply →
Use after free is generally VERY hard to exploit. Double free can corrupt data structures more with control. Use after free is basically at the mercy of the allocator and program state, where whatever gets written to the same memory address may or may not be relevant.
There is a reason why most vulnerabilities these days are either higher level logic bugs, or things that require code execution on the machine.