Learning Rust & Project Ideas

Recently I finished taking CS237, a class all about writing in C and x86 assembly, so I thought it would be a natural try to work on Rustlings at the same time to see if the hype around Rust really lived up to what everyone else was saying about it. After finishing Rustlings, I can confidently say that Rust is an extremely useful language that I’m glad I spent the time to learn and working on it has given me the confidence to approach some ideas I probably wouldn’t have ever considered otherwise.

Strengths of Rust

• I like strong types, sum types, and how you can get type-level safety on a lot of things for free (they go away at compile time). In particular, learning about PhantomData really got me thinking…
• Lifetimes and the only-one-mut-pointer rule are a very cool double-edged sword that helps just as often as it hurts. I am very grateful that std ships most of the data structures I need, because implementing them myself sounds really painful.
• It’s similar to other languages I already like (Swift). The presence if let, compiler-enforced complete match, the _notused underscore, and Result<T> all made Rust a lot easier to pick up because what works in Swift usually works here, too.
• cargo is really great. One tool for pinned & reproducible builds, benchmarking, testing, and cross-compilation is fantastic. It’s really easy to build anyone else’s Rust crates & really easy to share ones you make. I wish every build tool was as good as cargo is.
• The high-level style, speed, and manual memory management is a wonderful combo that exists almost nowhere else, except maybe in Zig and C++.
• clippy is really helpful. I turned it on after finishing Rustlings and redid some of the harder exercises I’d forgotten by that point, and it’s incredible how it often just solves the problems for you. The compiler might make Rust easy to write, but this is what makes Rust fun and easy to write excellently.

Weaknesses of Rust

• The syntax can get really ugly (especially when you start involving lifetimes, smart pointers, too many generic types, and complex trait bounds)
• I understand why Rust renamed things (types => traits, packages => crates, string => &str and String depending on context, Box<T> => C++ style smart pointers) but it would have been helpful if The Book¹ had notes for programmers of other languages when they did this. It would have made it a bit faster to understand what a chapter was going to be about & find what I am looking for, even if they aren’t exactly the same.
• Errors with the functional part of the language are often substantially less helpful than for every other part of the language, and the functional parts are hard to use right (especially when you start chaining them).
• Dropping to unsafe a lot is required in order to do FFI, which is both good (forces you to stop and think) and bad (because sometimes, figuring out how to say what you want in a safe abstraction with the smallest possible unsafe surface is a very hard problem).
• Trying to build for some OSes/hardware outside of the big three (Linux, macOS, Windows on x86_64 and aarch64) is a real pain, and often requires bootstrapping your own Tier 3 toolchain. This is a real shame because if you want to run Rust somewhere small (like, say, a router running OpenBSD, or x86_32 hardware) where bootstrapping is not an option, it makes the build process a lot more annoying.

Project Ideas

I really like Rust and will definitely be coming back to it in the future. It isn’t my favorite programming language but it’s better than many of the other languages I’ve had to use and it’s so much better than C. There are a few things I’ve been thinking about writing at some point:

• Rust is not a great GPU kernel language (almost all languages aren’t) but Fortran is a really good GPU language when you compile it with GPU offloading. Someday (probably in the spring semester when I take computer graphics), I want to try having Rust drive Fortran programs: Rust lives on the CPU and calls out to Fortran on the GPU. I think this could make lots of low-level graphics issues in that class become much simpler. PhantomData is cool for precisely this kind of workflow: lifetimes in APIs could make it much simpler for people to safely work with data over the FFI bridge!
• On a similar note, it would be cool to have Rust driving HPC workloads since it’s reliable and much faster than Python. I may implement something like this for CICE later on in my thesis, if I discover that calling it from Python and f2py is a massive source of overhead (it definitely could be, it’s happened to me before).
• I’m sure I’ll probably want to write some small Unix tool here or there for my own needs. If I do, Rust is probably the language I’ll be reaching for going forward.

I’ve never really been a big fan of the Julia programming language but now I think I finally understand why: it’s trying to do what Rust did but for scientific compute and it’s failing horribly. Julia tries to be as fast as Fortran but as simple as Python, yet fails as doing both (its GC is horribly slow and its ecosystem is too small, so you end up doing more work than Python for worse results!).

Rust avoided both of these fates by actually thinking about what it needed to give the programmer (lifetimes, affine types, smart pointers, easy-to-use opt out: .copy()) to make memory management safe and simple, and made abstractions relatively cheap by simplifying them at compile time, whereas Julia didn’t do that work for its problem domain, and ended up with a language that satisfies nobody. Modern Fortran² is closer to Julia’s vision than Julia is!