A few years ago, I decided to hop on the FOSS development train and contribute to a
project which seemed pretty neat: the reference compiler for the Rust programming
language. Coming from a small amount of poking at C++ and Arduino from the safety of
garbage collected languages, Rust seemed to be full of good ideas. Even as a wee novice
programmer, I knew the danger of buffer overflows and use after free. I also appreciated
Java's type system checking my work for me, and Rust's familiar syntax and functional
programming idioms made it seem like *a cool thing* to try out - a programming language
which let me use all the power of my computer like C or C++, but with all the fancy
"modern" stuff that came from functional languages and strong type systems.
As most Rust programmers will warn you, I had a difficult time getting comfortable with
Rust. A lot of the language is very familiar - structs, objects, variable declaration,
and so on. But Rust's main selling point is its strictness about data ownership, and the
complexity of the ownership system required me to think hard about exactly where the data
was going, something I never really had to do before. Thankfully, the issue I latched
onto in the compiler's github repo was pretty simple - after getting my head around the
relevant parts of the vast code base, it mostly amounted to changing some of the classes
used and settling on good message text and behaviour.
Feeling validated (but a little exhausted) by my accepted pull request, I tried some more
complex projects. But my will was utterly broken by another aspect of the Rust language:
lifetimes. There comes a time in every nontrivial Rust program's life where the compiler
can't figure out data ownership on its own. More or less, it can't keep good enough
track of objects to be able to guarantee memory isn't used after the corresponding
objects have been destroyed. In these instances, the compiler whips the ball back into
the programmer's side of the court and requires some variables to have annotations
describing how long they are required to live for. Using these annotations, the compiler
can properly track the entire lifecycle of a block of memory and make sure it is not used
after it is freed or otherwise rendered unusable.
To me, this was a brick wall: the syntax was completely alien, I didn't understand how or
why the compiler decided where annotations were needed, and when tasked with actually
annotating a function it took me ages to figure out what my objects were actually doing
and how to describe them in the language of lifetimes. Trying to work through one
particular compiler error, I abandoned my fledgeling Tetris clone and moved on to gentler
pastures, never to return in earnest. I've kept up with new releases and some of the big
libraries, but I've never felt comfortable enough with Rust to start any projects with
it.
When I took it upon myself to try to get a solid grasp of C and modern C++, some of those
gears started turning again.
Working through some toy C and C++ programs, I was reminded of my struggles getting up to
speed with Rust. Some things were familiar: it turns out the syntax and semantics related
to pointers aren't just similar in Rust and C; they're basically identical. But the
heart of my problem was that while I understood what Rust was doing and what the problems
it tries to solve were, I didn't really understand those problems themselves. In my time
writing software in Python and Java, I never had to worry about when an object would be
freed or pointers hanging around in data structures far away from the original object.
While I understood that attempting to use memory that has already been freed, or files
which have already been closed, was quite a bad thing, I didn't understand how much those
issues interfered with the day-to-day software development process. The moment I
understood that you didn't have to be an idiot to put a use after free into your code was
when I finally understood what Rust was doing. References are just pointers; but when
you're designing software, a pointer should never just be a pointer. That's why Rust has
the totally separate & and &mut (and, not so coincidentally, why C++11 introduced
smart pointers).
I'm not entirely sure where I'm going with this, but my experience with learning Rust was
the first time that I recognized myself being blocked on a topic by a lack of
experiential understanding of its background. The novelty of that experience alone was
enough to warrant a closer inspection, and after a lot of thought I think it is the
programming equivalent of learning a simplified mathematical model before the more
accurate (but complex) one. There is only so much new information we can absorb before it
needs to be cemented.
In my case, I am an extreme "learn by doing" person, so upgrading from some toy Rust
programs to a medium-sized self guided one seemed like the logical way to get the basics
of Rust down. Unfortunately, Rust does not present a way to navigate a larger undertaking
like that without wading into its more advanced topics. This is a place where garbage
collected languages - and, for their credit, C and archaic C++ - shine. You can write a
naïve Python or Go program without worrying about what's happening with your memory or
the shape of your call graph, and it'll do something. You'll hit bugs big and small and
should never work on software being used by other people, but you'll feel good about the
foundations of how to actually get stuff done in those languages. Rust is insistent about
hitting you over the head with a sack of bricks until you understand all the things that
make Rust uniquely Rust. After that and only after that, can you get up off the ground
and do what you originally wanted. At least they have the courtesy to warn you up front –
"fighting with the borrow-checker" didn't become a meme for nothing.