Empowering everyone to build reliable and efficient software.
Traits now support async fn and -> impl Trait (with some limitations), the compiler got faster, version = in Cargo.toml is now optional, and many small functions have been stabilized!
I kept reading the same few chapters of the rust book. It's a yearly ritual for me. Same as installing Bethesda games and the Sims and just playing a few hours before uninstalling.
Haha also yearly for me. I have actually written a small utility in rust that interacts with mysql, but it was basically just transposing python to rust, plus it's hacky as hell and I didn't really learn anything.
I've stuck that rust book in the "one day" silo, along with the guitar, learning French, eating healthy, and getting enough sleep. One day.
Build a ray tracer in Rust. Follow something like Ray Tracing in One Weekend. Don't be scared that the example code is in C, translating it to Rust is easy enough and is part of the learning process; it's good that you can't just copy paste.
Sorry to ask, is Rust derived from another language? I know some c++, would that benefit me if I want to learn Rust?
What is powerful about Rust in comparison to other languages?
I find it's a mix between ML languages and C++, and knowing one of them would help yes.
If you're tired if chasing a wild pointer because of a subtle use-after-free in a multithreaded monster under gdb, you'll love #rust.
Honestly the only things that are similar to C++ are small amounts of C-like syntax, RAII, smart pointers, and iterators. And even so, Rust improves those features a lot. The list of things that Rust rejects from C++ is much larger; Rust does not have:
new and delete (perhaps discouraged in modern C++)
function overloading
inheritance (replaced by composition or traits)
friend classes (replaced by modules)
exceptions (replaced by Result values)
6 different kinds of first-class constructors (hallelujah)
templates (replaced by constrained parametric polymorphism)
variable mutability by default
Rust does OOP very differently and leans harder into functional paradigms.
Maybe Rust isn’t a good tool for massively concurrent, userspace software.
This conclusion is a very weak one.
The only argument the article successfully makes is that using the raw async/await mechanisms of the Rust language leads to situations where it's tricky to figure out how to structure your code, and that the raw async mechanisms of some other languages don't have that friction.
But why would we only consider the strengths of the pure out-of-the-box Rust language and forget that it has an enormous robust ecosystem of crates? For any given use case there will be suitable frameworks that make async Rust programming both natural and performant. Or if such a framework doesn't exist it is possible to develop one on top of the async mechanisms of the raw language because those mechanisms are so unopionated by design.
My colleagues struggle with async Rust as-is. I did too for quite a while. But that's why I'm developing two different async Rust frameworks for two different software architecture paradigms (one that fits nicely into an ECS and one that fits nicely into a deterministic scheduled worker pool) each of which we have different use cases for. If the Rust async design was more opinionated and imposing (which is what this article is recommending) then I likely wouldn't be able to produce frameworks that are as effective for each of these use cases.. one or the other would have suffered, likely both.