What is your favorite thing about Rust?

I'm in the slow process of getting my company to adopt Rust. We have one small production service running Rust now, and I'm pushing for more widespread adoption.

On Friday, I'll be giving a presentation to the rest of the software engineers on why we should continue Rust adoption and use it more widely. This presentation won't make or break the adoption as a whole, but if it goes well it may speed things up a bit.

So my question: what is your favorite thing about Rust? I've already filled my presentation with all the reasons I think it's great, but I want to make sure I cover things from as many perspectives as possible.

Some background on the company / tech stack in case it's useful:

We're an IoT company, our embedded firmware is all C/C++ today. We do a ton of work on in the cloud turning telemetry into useful data, all in Python (that's my role). We also have a bunch of UIs for consuming that data, Angular/TypeScript. I'll be presenting to engineers from all three of those domains.

If you have any other tips for successful strategies for integrating Rust, I'd also love to hear them, thanks!

1 Like

Coming from C++, I love the freedom that I get from not having to manually think about whether all my references might be dangling. I'll attempt designs I wouldn't even think about in C++ because they're checked, and I'm willing to make changes I'd be too scared to do in C++ for not knowing all the hidden lifetime requirements. (The PRs I've made to rustc I wouldn't have been brave enough to try in clang, for example, since I don't have the extra security blanket in C++.)

4 Likes

Why not reference the AWS post this last week about why AWS is turning to Rust. In brief, "Rust’s cardinal virtues: performance and reliability."

For me the killer reason is that Rust offers compiler-proven memory and thread safety, with easily identifiable code in those few areas where a programmer may need to provide part of the proof.

6 Likes

For me, it's definitely:

  1. The type system, which is both advanced and strict enough to ensure memory safety, but at the same time flexible enough to allow creating my own abstractions that I can also use for ensuring higher-level semantic correctness.
  2. The (sometimes surprising) uniformity, extensibility, and the resulting malleability of the language. The fact that Rust is an expression-based language removes a lot of unnecessary noise. Procedural macros are an absolute blessing – they are the dream come true that Lisp advocates kept talking of but never quite delivered.
  3. Relatedly, the fact that the language is designed to be machine-readable, as well as human-readable at the same time. An example of the former is the context-free grammar, while an example of the latter is the familiar, simple, sensible names for concepts and features (i.e. none of the gibberish that half-logic-half-pure-FP languages try to invent for no good reason).
9 Likes

Coming from Python, I really like the type inference. It allows you to write code in a strongly typed system and get type checks done at compile time, but it also allows you to write less boilerplate code. Python is a strongly typed language too, but it is also dynamic and seeing your bugs on runtime really slows down the production.

4 Likes

I think it's useful to split the why into separate buckets:

  1. What one personally/irrationally loves about the technology?
  2. What are actual technical reasons to use the technology?
  3. What is the broader economic/network context, which drives technology's adaption?

My own takes on roughly these points are:

  1. https://matklad.github.io/2020/02/14/why-rust-is-loved.html
  2. https://matklad.github.io/2020/07/15/two-beautiful-programs.html
  3. https://matklad.github.io/2020/09/13/your-language-sucks.html (which mostly hopes that Rust's 2 is big enough to cause 3)
15 Likes

Compared to C/C++/Python, the big thing for Rust is that once the code compiles, it often works correctly, at least as far as language-level issues are concerned. You won't be surprised by NULL/None, unhandled errors, or data races. OTOH in C or Python running the program for the first time is just the beginning of the debugging stage.

Compared to Python it's just amazingly fast and memory efficient. Types that are considered expensive by Rust's standards, e.g. Arc<Mutex<T>> are similar to what Python uses for everything. C can achieve the same speed, but making safe and reliable network service in C takes more work.

Cargo has the good aspects of npm, but dependencies in Rust are less risky thanks to strong type system, docs.rs, and stronger backwards compatibility (Node.js had 15 semver-breaking versions, Rust is 1.x forever).

Compared to C/C++ the nice thing is that there aren't multiple build systems, there aren't multiple package managers.

15 Likes

I agree with all of what @kornel said. I'd like to add that if Rust hadn't had macros in all its forms, it wouldn't be nearly as useful in practice.
Just look at the mess that is Java annotation processors to get an idea of what I mean.

3 Likes

Check Jon's presentation: https://www.youtube.com/watch?v=DnT-LUQgc7s

Hard to beat that.

3 Likes

Give a 45min presentation on Alias Analysis making everyone bored and confused and thinking this is deep complex stuff. After a short pause, quickly give explanation of the Rust way. Then let them make the choice.

2 Likes

I'd say from all the areas in which you're writing code, it'd make most sense to replace python on the server first. Rust can be just as high level and easy to rad, but with much better performance and proven protection against data races.

In embedded I think it's not quite ready for widespread adoption yet. If you want to be early adopters, using Rust on embedded is possible. However, I think Rust needs 5-10 more years before it can be adopted broadly in that space. Debug support and issues like debug binaries not fitting in flash of your microcontroller will need to be addressed.

GUI and web front-end are also possible, but not quite mature and developed enough to make me use Rust if I'm not explicitly being an early adopter.

2 Likes

I've watched that talk before, but rewatched at your suggestion. Most of what he talks about is what I already have in my presentation, he just said it better :grin:

Funnily enough, no one has mentioned dev tools yet. I love rust because the tools just work and get out of my way. cargo just works, rustdoc just works. I don't have to debug why the entire project is being rebuilt when I just changed the README (cough cmake cough). I have tools for auditing my dependencies, and for updating them without having to dig through a requirements.txt file.

I also think the incremental compilation is really well done - I love that cargo knows when I've updated my toolchain and automatically rebuilds (although not when bootstrapping, boooo). Incremental is almost good enough to make me forgive the slow compilation times :slight_smile:

All the functional programming and lifetime things are nice, but they're not the reason I love rust.

8 Likes

Right now I am working on implementing a heap profiler in Rust. It's very similar to two heap profilers that I have implemented previously, one in C, one in C++.

With Rust, I have a wealth of necessary low-level features readily available, such as: global allocator replacement, stack trace gathering, mutexes, thread-local storage, hash tables, lazy global initialization, fine-grained timing, and JSON output. These features are either in the standard library or on crates.io. They have nice APIs. Everything fits together well and it just works. I have only had to deal with one crash, in some unavoidably unsafe code (within an implementation of GlobalAlloc::realloc).

It's so much easier and faster to write than in C and C++, the resulting code is nicer, and I have far more confidence in its correctness.

8 Likes

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.