Rust compiles really slow

Written 2025-09-01

My Introduction to Rust

A little while back, I had a bit of a golden opportunity- I needed one more programming language course in order to meet the requirements for my Bachelor's degree in Computer Science, and I had already taken plenty of courses in Python (which were no fun) and C (which was significantly more fun), and had really familiarized myself with both languages- to the point where in writing my very first interpreter for a programming language (in C, that is) I got to witness firsthand the memory management difficulties that languages like Rust seek to solve.

So, since my college had a system for creating "tutorials", essentially your own independent study courses that counted for actual course credits towards your degree, I decided to (with the help of one of my professors) create an online course titled "Rust Programming for Intermediate Developers".

I spent the semester learning Rust, building some neat projects- including a Markdown to HTML converter, an interpreter for a Scheme dialect, etc. (although these projects have been somewhat lost to time)- and by the end of the course, I felt very familiar with the principles and core aspects of Rust programming- or, I at least felt about as comfortable in Rust as I felt in C.

Writing "whatdo"

The semester had ended, and I went home for about 3 weeks to spend Christmas and New Year's with my family, and in my free time, I continued to toy with Rust. One day, I wanted a tiny, minimal-scope project that I could finish in about a day- or a weekend if I let myself get distracted. So, I went about creating a to-do list CLI program with some simple features in mind.

I wanted a way to add each of the hobby projects I was working on to a list, and be able to essentially mix them around in a hat and "draw" them to decide what I would work on that day. The tasks would be shuffled in such a way to where I wouldn't draw the same task twice in a row without already having drawn all of the other tasks, with the option to "reshuffle" this task list if I wanted to.

So, in a few short hours (spread over the course of a weekend) I implemented whatdo.

The code was incredibly simple- just 2 Rust files, one handling the "to-do" list data structure (essentially a shuffle-able queue of tasks, which would be serialized as a TOML file using Rust's Serde library), and the other (main.rs) file providing a nice and clean CLI interface/argument parsing using Clap.

I put it on GitHub, and started using it myself- and was pretty happy with it, and moved on with my life for a little while.

About a year later...

A year went by, and I had set up a "zen machine"- basically a really old Lenovo IdeaPad S10 running Debian, with a 32-bit CPU and only 2 GiB of RAM- essentially to use as a fancy typewriter or "writer deck". I wrote little programs on it, would use it to edit my blog (back when I first got onto neocities), and having a program like whatdo on that laptop made perfect sense, so, I cloned the repository, and ran cargo build --release while sitting in one of my lectures.

...it took about 50 minutes to compile.

Now, you might be thinking- "hey, that's a pretty underpowered machine, of course it's gonna take a while!", and, well, yes, you're correct- but look at the compile times on my main laptop, with its 4 cores, 3.9 GHz clock, and 32 GiB of RAM:

Not necessarily outrageous, until you consider the fact that

• the dependencies were already downloaded to the machine (Serde, TOML, etc.), so I didn't have to wait for those libraries to install (unlike on the "zen machine")
• this is two Rust files, that simply read a string from a very small file

Not to mention the final executable file size- roughly 75 MiB.

Sure, I can understand where these egregious compile times are coming from- Rust does a lot of compile-time checks in order to achieve the goals of memory safety that it desires, not to mention its complex type inferrence system, and the fact that the program outputs a statically linked binary resulting in a larger final file size and slightly longer compile times (as it has to compile each of the dependencies, and the depedencies of the dependencies, in order to compile my program).

My argument here is not that Rust is doing something wrong by having all of these additional things that increase the compile time, my argument is that something this simple should NEVER take this long to compile.

The Rust community

Rust has long been described as having a cult-like community, both as an insult as well as a compliment. While the Rust community in my experience is very kind and generally very helpful, there's this constant "everything can (or sometimes should) be rewritten in Rust" mentality that I'm not sure I could ever agree with, and it's with surprisingly simple examples of software written in Rust (in my case, whatdo) that this is justified.

Rust's low-level control capabilities and compile-time memory-safety assertions can be especially useful for software that absolutely requires these things- the classic examples being device drivers, cryptographic libraries, and some components of OS Kernel programming.

However, for a lot of tasks- such as those that require rapid testing, prototyping, and iteration (game programming, UI/UX design, and higher-level web development in general), or just tasks that don't necessarily require any sort of these low-level memory management techniques at all (stuff like whatdo, the type of thing that could've just been written in a garbage-collected language), these features of Rust, and the compile time overheads that they result in, can at best be unnecessary, and at worst, infuriating.

This doesn't even mention the rather large learning curve of Rust, or the fact that the language still has many nightly-only features- maybe I'll write another article on that someday...

Conclusion

I can see the dream that Rust developers have- Rust has a pretty nice ecosystem, and provides some pretty great safety features without sacrificing speed or control, so the dream of everything being written with Rust is an understandable one.

I just don't think it's very realistic- or, for that matter, necessary; and this is fairly evident just by looking at compilation times.