A little Rust
Every so often, I like to dabble in a programming language to get exposure to a new way of thinking.
- C++ introduced me to design-patterns (the classic GoF book) and the perils of memory-management (More Effective C++, Effective C++, Template Meta-Programming).
- Lisp taught me the value of small pieces, little languages and (most importantly) macros.
- Haskell showed me the virtue (and pitfalls) of laziness and showed me that higher-level abstractions can be super powerful!
It’s been ages since I picked up something new, so I’ve started taking a look at Rust. Why Rust?
Well, firstly it’s been gaining mindshare. Rust is increasingly commonly mentioned on the blogs I read, and it’s Stackoverflow’s most loved language for the last 5 or so years.
What makes Rust different? Like C++, it doesn’t have garbage collection, but unlike C++ it has a rich ownership model guaranteeing memory and thread safety. Memory safety makes Rust super attractive as a systems-programming language.
As a learning exercise, I ported over a previous project from Haskell to Rust. You can see the sort of output it makes below, and check the code out at https://github.com/fffej/learning-rust/tree/main/orbit.
So, what’d I learn from this experience?
Rust has clearly had a lot more thought about developer experience than other languages (Haskell and C++ spring to mind). For example, if you pass a reference instead of a value, you get a handy message (compare this to C++ and getting a template parameter wrong, or Haskell’s foldable/traversable saga).
In a similar vein, the documentation and surrounding ecosystem is super friendly to use (at least for the limited third-party packages I used).
Rust has an auto-format (rustfmt) which proclaims the one-true way to lay code out. It’s a small thing, but it’s just another thing that improves the DX.
Within the language, the typing features play towards my biases. After writing lots of code (and reading more), I prefer code that I can reason about locally. Rust’s semantics support this well since you have to explicitly specific mutability. The strong-typing means less unknowns when looking at a local bit of code.
What didn’t I like (with the caveat that means “I have no clue what I’m doing but I didn’t like this in the few days I spent writing code so don’t take it too seriously)?
“clippy” sounds like it should be a great idea, but it gave me false positives out of the box. I should have probably invested some time in setting some sensible defaults.
I didn’t find a nice way of composing functions (pipelines), but it seems that this can be done fairly simpler with macros. More for me to learn here!
