So I’m working on this project that includes warp, serde, tokio, mongodb and bson. It’s a REST server with a database at the back. This kind of problem is generally more suited to Node.js, but if I get it done with Rust, it should at least be way faster, plus, why not?
Now, Rust is known for its long compile times when you include a lot of crates. Especially when these crates provide a whole range of code that is not directly used, as well as many macro invocations. The compiler needs to verify correctness for all of this (it’s Rust), as well as generate LLVM intermediate code (which is not yet that optimal), and then hand over to LLVM to optimize.
My project currently serves about 5 REST API calls in a very basic way, and already requires about 1.5 minutes to compile.
On a 28-core i9 @ 3.3GHz.
1.5 minutes.
That’s like having to watch all 9 unskippable 10-second advertisement videos.
Those kind of times remind me of making video games with Turbo Pascal in the early 90s. And in those days, especially with C/C++, a similar effect was happening with header files and macros in header files. An explosion of expanded code bogged down the lexical analyzer and preprocessor. Compiler builders attempted to fix this with precompiled headers, but that didn’t work too well in the early days.
And no, having to wait 90 seconds doesn’t actually warrant much complaining. Video game developers know much longer compile times, and 90 seconds isn’t really that bad. You can get up, walk around, get coffee, live a little, etc. This is much more about the principle. Making these libraries huge for the sake of completeness isn’t beneficial. Adding macros everywhere to provide all sorts of freedom isn’t beneficial. Showing off a new combinatory explosion of macros that might seem an easy and clean solution to a perceived coding problem, isn’t beneficial.
Also, they’re going to introduce incremental compilation for Rust at some point, so why not just wait? But hmm.. Doing things that way is not very samurai (I didn’t say lean or kanban, but kinda meant it). Kids in Japanese schools learn how to cook and how to clean the kitchen simultaneously. They learn how to make a mess and how to restore order simultaneously.
Maybe we can make a similar effort in Rust development. Keep the crates as lean and to-the-point as possible. Expose one simple functionality per crate. Don’t introduce crates just for one macro. Standardize some of the low-level stuff. Maybe remix the crates to serve more specific goals.
There must be more options. Let me know what you think. Am I simplifying this too much, or are we ready for more practical, long-term and lean design of the shared software?