- cross-posted to:
- rust@lemmy.ml
- cross-posted to:
- rust@lemmy.ml
I can only speak out of my own experience, which is mostly C++, C#, C and Rust, but I also know a bit of Haskell, Java, Fortran, PHP, Visual Basic, and, to my deepest regret, also JavaScript.
For additional context: I have been working in game development for the last 7 years, my main language is C++ for Unreal, but I've also worked on some Unity projects with C# as main language. Before I switched to game dev I worked in material science, and used C, mostly. I use Rust for my spare time projects, and the game company I work at is planning to introduce it into our Unreal projects some point later this year.
Of all the languages I mentioned above, (Safe) Rust and Haskell are the only ones that have not yet made me scream at my PC, or hit my head against the desk.
So, some of the reasons why I personally love Rust:
- Rust is extremely simple compared to the other languages I mentioned above. If you read the official introduction you know all you need to write Safe Rust code.
- Rust's syntax is elegant. It's not as elegant as Haskell, but it's a lot more elegant than any C-based language.
- Rust is (mostly) type safe. There are (nearly) no implicit conversions.
- Rust is memory-safe, without the runtime overhead that garbage collected languages incur.
- This is a bit of a neutral point though. The Rust compiler will complain if you make mistakes in memory management. Unlike in managed languages, you still need to do the memory management by hand, and find a working solution for it.
- The memory management model of Rust ("borrow checker") makes data dependencies explicit. This automatically leads to better architecture that reflects dependencies, because if the architecture doesn't match them, development will become an uphill battle against the borrow checker.
- Due to the borrow checker, you can use references extensively, and rely on the referenced object to valid, and also that it is up-to-date (because it cannot be muted or go out of scope as long as you hold the reference).
- Traits are an amazing way to abstract over types. Either at zero-cost (static dispatch), or, in the rare cases where it's needed, using virtual function tables.
- Rust aims to have no undefined behaviour. If it compiles the behaviour of the code is well defined.
- This, together with the borrow checker, ensures that there are (nearly) no "weird bugs". Where in C++ one quite regularly hits issues that at first glimpse seem impossible, and only can be explained after several days of research on cppreference ("oh, so the C++ standard says that if this piece of code gets compiled on a full moon on a computer with a blue power LED, it's undefined behaviour"), that almost never happens in Rust.
- Macros in Rust are amazing. There are macros-by-example that work by pattern-matching, but there are also procedural macros, which are Rust functions that take Rust code as input, and generate Rust code as output. This gives you amazing power, and one of the most impressive examples is the Serde serialization framework, that allows you to add serialization to your data types simply by adding an attribute.
- Tooling for Rust is pretty good. The Rust compiler is well known for its helpful error messages. The rust-analyzer plugin for Visual Studio Code is great too. (It also works with vim, Qt Creator and others, but the but Visual Studio Code works best imho.)
The points mentioned above mostly apply to Safe Rust though. Unsafe Rust is a different story.
This brings us to the downsides. Rust isn't perfect. Far from it, actually. Here are some of the things that aren't great about Rust.
- No Higher Kinded Types. This is my main issue with Rust. Even C++ has them (as usual for C++ in a horrible un-ergonomic and utterly confusing way). If Rust had Higher Kinded Types, the language could have been simpler still. For instance, there would have been no need for the
async
keyword in the language itself. - Unsafe Rust is hard. In my opinion even harder than C++, because of Rust's aliasing rules. Unlike C++, Rust doesn't allow mutable memory aliasing. That's because mutable aliasing can never happen in Safe Rust, and not supporting it improves performance. This means that when writing Unsafe Rust, one has to be careful about aliasing.
- Luckily one only rarely needs Unsafe Rust, usually only in order to call functions from other languages. Still, it's hard, and I'd generally suggest to use an automated code generator like cxx.rs for interfacing with other languages.
- Interior Mutability. I understand why it exists, but it breaks a lot of the guarantees that make Rust a great language. So, my conclusion is that one should avoid it as much as possible.
However, the upsides clearly outweigh the downsides imho.
tl;dr If a (Safe) Rust program compiles, chances are pretty high that it also works. This makes programming with it quite enjoyable.
For downsides, i'd like to add that the lack of function overloading and default parameters can be really obnoxious and lead to [stupid ugly garbage].
A funny one i found in the standard library is in
time::Duration
.Duration::as_nanos()
returns a u128,Duration::from_nanos()
only accepts a u64. That means you need to explicitly downcast and possibly lose data to make a Duration after any transformations you did.They cant change
from_nanos()
to accept u128 instead because that's breaking since type casting upwards has to be explicit too (for some reason). The only solution then is to make afrom_nanos_u128()
which is both ugly, and leaves the 64 bit variant hanging there like a vestigial limb.This, together with the borrow checker, ensures that there are (nearly) no "weird bugs". Where in C++ one quite regularly hits issues that at first glimpse seem impossible, and only can be explained after several days of research on cppreference ("oh, so the C++ standard says that if this piece of code gets compiled on a full moon on a computer with a blue power LED, it's undefined behaviour"), that almost never happens in Rust.
Ah yes, the Chaos Theory principal of programming.
You've settled my mind on which language to tackle next. There are a couple projects that have been calling my name, one in Go and one in Rust. Strictly speaking, I might be able to contribute to their documentation and tutorials without ever looking at the code (nobody in their right mind would ever accept code from me anyway), but I like to have some idea of what goes on under the hood.
Rust it is.
to my deepest regret, also JavaScript
I can relate. And thanks for this high-effort comment.
Rust and Haskell are the only ones that have not yet made me scream at my PC
As someone who likes Rust and uses it every day, how have you never screamed at your PC as a direct result of the borrow checker or trait solver? Have you never encountered errors such as
higher-ranked lifetime error: failed to prove $FOO: Send
, which is sometimes actually just a bug in the compiler? Or the classicthe trait bound $FOO: $BAR is not satisfied
.axum
even has a#[debug_handler]
macro just to improve this error. I have spent literal days of my life fixing these kinds of errors, when the compiler not only doesn't provide a solution but fails to pinpoint the cause of the problem.I can only hope diagnostics continue to improve, because I know they matter to the Rust team.
I have seen some errors along those lines (but not exactly those) while working on the Free Monads proof of concept. Especially while trying to come up with a solution that doesn't require macros (which I didn't manage in Stable Rust, exactly due to such issues).
I have yet to see them in actual production code though, but maybe I was just lucky up to now?
For instance, there would have been no need for the
async
keyword in the language itself.Can you explain how?
First things first: I haven't fully thought this through, as I haven't attempted to implement it (yet). It was just an idea I had while working on higher-free-macro.
It wouldn't yield the same syntax of course, but you could express the flow of the async computation in the terms of a Free Monad based embedded domain specific language. The interpreter for the eDSL in question would then do the equivalent of the async runtimes we have currently.
I could imagine that the syntax could be pretty nice when using the do-notation from higher.
However, since I haven't tried implementing it, I can't say for certain that there aren't any hard walls one could hit, especially related to Rust's ownership model, or more complex dependency trees.