Nice! Just in time for my yearly "I should finally learn rust" and then forget about it a week later habit.
this post was submitted on 28 Dec 2023
112 points (96.7% liked)
Rust
6005 readers
1 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 1 year ago
MODERATORS
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.
Async traits 🤩
Nice! Looks like a more ergonomic, faster Rust.
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:
newanddelete(perhaps discouraged in modern C++)- function overloading
- inheritance (replaced by composition or traits)
- friend classes (replaced by modules)
- exceptions (replaced by
Resultvalues) - 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.
You could argue that C++'s new is Rust's Box::new, and delete is replaced by RAII. Same concepts but way better ergonomy.
A lot of Rust concepts were also influenced by Haskell even though Rust uses different terms for them.
The way I often describe it is "Rust makes functional programming feel as intuitive as object oriented programming".
Pedantically, Rust does offer a subset of object oriented programming paradigms so one could argue that it counts as an object oriented language, but the design patterns that work the best with the language are all coming from functional programming, all without feeling too alien to someone coming from a strictly object oriented background (.. which was my own path into Rust).
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.