Last Saturday, I attended a training course on Rust for FOSS developers, run by Lars Wirzenius, who I’ve known for many years. It was free for ‘people who already contribute to FOSS projects via code’, because this wasn’t an introduction to programming course (you already needed that knowledge from another language) and Lars is ‘biased towards FOSS’. Although I primary write PHP, I also use Go and C, and I wanted to learn about Rust (as well as support Lars in case no one else attended – although around 20 people turned up in the end).
I must admit to a bit of imposter syndrome here, as I was questioning whether I count as a FOSS contributor. I do make most of my projects available under an open source licence (usually MIT), but all of my paid work involves proprietary software (I’d love to change this, so please get in touch if you would like to pay me to work on open source). The imposter syndrome kicks in due to me not contributing much in the way of code to other projects, though I do work on documentation and organisation tasks, such as chairing some DebConf meetings. Most of my projects are only used by me – the main exception being dns-sync-zone, which has received contributions from another user. However, I don’t embed telemetry in any of my projects, so it’s hard to know if anyone is using them and not reporting issues, and some are ‘install once’ like Slim Skeleton.
Beforehand, I discovered that there is a Snap for rustup, which I slightly prefer to running curl | bash. Having said that, rustup downloads everything anyway, which is probably the only option possible for a toolchain that operates on a 6 week release cycle. If you’re coming from other languages – especially C – this may feel a bit fast, but on the other hand you aren’t waiting 5 years for a new version to drop and for it to be included in your Linux distro of choice.
In such a short course, there wasn’t time for any interactive programming, although we did have a few discussion points raised in the chat. We went through a lot of material, and the session wasn’t recorded so I can’t go back and double-check anything. So I’m just going to present some of the notes I took, which are a combination of what Lars said and how I interpreted / thought about them. If anything is factually incorrect – as opposed to an opinion you disagree with – then that’s probably my fault.
- Cargo is the Rust workflow tool – use it for everything.
- There’s always an implicit dependency on the Rust compiler and the standard library – though I think this is common across most build systems (it certainly is the case in PHP, C and Go).
- The biggest strength of Rust is memory safety, which is a change from C where memory-related issues (invalid pointers, forgetting to free memory, re-use after free etc.) are the cause of a lot of bugs.
- Rust is strongly typed but also has inferred types – similar to Go (both) but different to C (strong but not inferred in declarations) and PHP (weak by default, but inferred).
- Result and Option types can be very useful – no runtime exceptions, no NULL pointers.
- Zero cost abstractions – iterators for example compile to the same code as a for loop.
- Rust has narrower architecture support than C, but it works on all the ones you’re likely to use, unless you’re doing embedded or esoteric work.
- Rust isn’t as well-suited to rapid prototyping and iteration as some other languages.
- Editions let you specify which features are supported, e.g. async in 2018.
- Each Rust compiler knows about all previous editions, so it can compile code for them. You can also mix and match crates with different editions in most cases.
- There’s a cultural bias against very small libraries, e.g. leftpad would be discouraged. This is partly due to the crates.io namespace being flat.
- blessed.rs is a website for finding the ‘recommended’ crates for specific tasks.
- Rust is quite hard to read initially – feels more verbose than C and Go in places (C in particular has the advantage of having a very small core).
- ? is important and used a lot in idiomatic Rust. I struggled to get my head around this, but it feels like something you get used to over time – a bit like * and how you (de)reference pointers in C.
- All ‘variables’ are immutable by default.
- Any function that doesn’t take self as a parameter and returns Self is a constructor.
- Variables can be copied or cloned – these are subtly different.
- The borrow checker is the thing that confuses new programmers more than anything else. If you don’t care about inefficiency, you can use clone to get around its restrictions.
Overall, the training was well delivered and informative. If I was using Rust commercially, I would definitely hire Lars for a longer course, as two hours only barely scratches the surface, and Rust in particular has some new concepts to get to grips with that don’t really have an equivalent in other languages.