Lars Wirzenius generously offered to teach Rust basics in a few free trainings for programmers who already contribute to free and open source projects via code. I got a lot out of an intro-to-Python workshop many years ago (curriculum), and I've been meaning to get going learning Rust, so I decided to sign up, and I participated in one today. Lars asked that participants "tell others what you thought of the course" even if it was highly critical, so here's my report.

Structure

Wirzenius offers a one- or two-day course in Rust basics as a paid, commercial offering, and the free offering for FOSS programmers is (as I understand it) a shortened version of that. A previous version of this free course was structured as three separate two-hour sessions, and included hands-on exercises. To make things easier to schedule, the version I attended today was a single session that came in at about 3 hours and 15 minutes. The description of the revised version mentioned regretfully that "most of the hands-on parts of the course" would be cut for time; I hadn't realized before signing up that, actually, there would be no hands-on exercises at all. (Please correct me if I am wrong and there was a hands-on exercise I missed!)

Therefore the course I attended today was a lecture with questions and answers throughout (sometimes orally and sometimes in the text chat), following this topic outline. Wirzenius spoke accompanied by slides which included code samples, and sometimes referred to specific code line numbers; he did not live-code.

Audience

Lars says,

This course is aimed at people who already know how to program. This is not a course for learning to program for the first time. Experience in a compiled, low-level language such as C or C++ is helpful, but not required. Experience in any language will do. Being comfortable on the command line is needed.

I do know how to program, but I don't have strong or recent experience in a compiled language. I hang out a lot with such people, and I've spent decades overhearing complaints and gossip about C, C++, and recently Rust, and working in a software engineering culture that has taught me a lot of important principles along the way. And last year I'd installed Rust and played with it a tiny bit.

So I understood the initial overview of Rust's strengths and weaknesses and how its ecosystem works, and the material on project setup and workflow and strings and modules. But I struggled to follow much of the other material, because it assumed I knew terms including macro, struct, generic, enum, and trait. During a memory management section I went to another browser screen to read the Rust book's explanation of the stack, the heap, and why you'd need to know the difference. No one else was asking for clarification on these kinds of points so I decided not to slow down the group by asking for definitions, most of the time; I was also a bit self-conscious as (I believe) the only woman in the session.

Pearls of wisdom

I appreciated Wirzenius's wry sense of humor, and the assessments he shared based on his decades of programming experience and years of Rust experience. Examples:

• cargo is not the compiler but instead invokes it. You will pretty much always invoke cargo and never need to run the compiler directly.
• Each project's target directory may will grow to multiple megabytes, since binaries are statically linked and large; you may want to store those someplace that you don't back up, to avoid needless storage consumption.
• Rust is better than Python for refactoring. But writing Rust requires careful thought -- you have to think in tiny steps -- and building and compilation is pretty slow. (For comparison: Lars's Python programs start in <100ms, and Rust programs start in the minutes. But Rust's compiler contributors are working on this, and compilation benefits from concurrency, so there's reason for hope.) So Rust is thus less amenable to rapid prototyping. But, as a bonus, if you write actual production code in Rust, then you no longer run into the problem where, 9 months into its production run, it suddenly fails because of a mistyped variable name.
• Rust is changing fast enough that idiomatic code you write today may not be idiomatic in a year. But it'll still work pretty well. In fact, every six weeks (before releasing the next version of the language), Rust's team collects all publicly available Rust code anyone has published, and builds it using the new compiler, to check for backwards compatibility. (!!!)
• The official book is great, but Steve Donovan's "A Gentle Introduction to Rust" is shorter and (to Lars) felt more approachable.
• Right now, Rust has no good way to check whether memory allocation succeeded. This will change because Linux kernel folks want Rust in the kernel, and they very much need to be able to check for memory allocation failure.
• For historical reasons, Rust has different syntaxes for slices of different string types.
• Serde "is a framework for serializing and deserializing Rust data structures efficiently and generically." It's really powerful and if you need to deal with YAML, JSON, etc. the experience is nearly comparable to Python.

Appreciation

I did learn more about how to work with Rust, what's going to be easy and what'll be tedious, and what fundamental CS concepts I will need to brush up on to get unstuck. And I'm sure that the longer versions of this course, with hands-on exercises, are pretty valuable (I'm biased in matters of instructional design and consider hands-on exercises and frequent diagnostic checks essential, as I learned from the Carpentries curriculum development handbook and Teaching Tech Together). Right now I feel motivated to get back to Rustlings, an exercise-by-exercise approach to learning Rust by fixing code that doesn't work -- I started it last year and then stopped.

Much thanks to Lars Wirzenius for his generosity and his openness to (even critical) participant response!