One of the biggest pain points with Rust is long compilation times, as far as I've seen in countless blog posts, threads, etc.
Why is it such a big deal for so many people? What do you consider "long"? How fast would you expect your code to compile?
I'm no expert and in no way have I tried all the languages out there. I'm just wondering if other languages are that much faster that they make Rust feel like a sloth. I also guess that the development workflows of everybody are different - for example I don't think I spend a lot of time compiling code.
It is typically not a big deal for me, however there are some crates with very long compile times. For example, I remember that some graphical crates had very long compile times compared to many other Rust projects.
For me its actually more important that the rls is fast. I noticed that I tend to compile my rust programs less often than my c programs, as most error are catches by the rls already.
(As far as I know the rls also compiles the code once, but in debug mode and incremental build, so that's of no concern for me)
As a side note: obviously faster compile times are better than slower compile times, but for me this is not something I would consider whyle choosing a language.
Compile times have not been a show stopper for me.
However things are more comfortable when riffing on code if you use "cargo check" to quickly shake out syntax errors. Redirecting...
I guess RLS should be doing that from me in VS Code but I have never managed to get it running reliably. Crashes out all the time.
I seem to have spent half my life waiting for builds. Back in 1983 a full build of our embedded system assembler code would take a lot of a working day. Running on 3 Intel dev machines with 8 inch floppy disks.
Rust compares favorably to synthesizing logic for FPGA designs in Verilog.
Completely agree. The difference is that RLS / analyzer directly affects the way I write code and how fast I do it. Compilation may be a problem if you're using the compiler to help you find bugs or fix errors, etc, but that's not something I do often.
It's also not a big deal for me. The initial compilation after adding a new crate as a dependency is somewhat annoying, but that's infrequent, and otherwise compilation is incremental, so usually, it doesn't take more than a couple of seconds.
For me, compilation time is a huge deal. I feel my flow crash when I wait for the test to compile, or when I go to make a tea while I am rebuilding in release mode. This is the most painful during bug fixing/optimization/cleanup work, where you do small changes and compile often to test hypotheses. When writing new code, it’s better as you don’t have to recompile that often.
I am also satisfied with CI times: if you cache deps properly, it’s not that bad.
Totally not a big deal for me.
I also don't have the feeling it takes 'that' long. I prefer a safe, fast, optimized running program which is slowly compiled, over a fast compiled but shitty optimized program all day.
Runtime speed > Compile speed.
Of course, if it's possible to make Rust compile faster, it should be done. But don't sacrifice other things for it IMHO.
I've found incremental compile times to be really good in Rust. 90% of the time I can have cargo watch running on a background terminal, and after hitting save it'll have compiled my crate by the time I move my focus from the editor to the terminal.
Initial compile times are a killer though. Doing a clean build for the project at work might take 2 or 3 minutes on my personal laptop, while my work PC or the CI server may take 10+ minutes to do a full build.
Waiting 10s of minutes to get the green light from CI to merge a branch is a killer for my flow... I'd hate to be a rustc developer where their CI probably takes 10x longer.
Coming from interpreted languages, my expectation is about 2-3 seconds, as this is what it usually takes to reload an app after change. Anything above that is annoying.
I remember working with Delphi, which simply held everything in memory, so recompiling was also in that time range.
Today 5 min compile time means 5 min locally + several times that on CI, so you can wait for half an hour to deploy your changes. Again several times that that if you change compiler version.
A page of ALGOL used to take all night to get compiled in 1976. After you have punched your cards put them in a pigeon hole in the CS department. If you are lucky the operators would compile and run it over night. If you were lucky you did not run out of CRUs (Computer Resource Units). In the morning you could collect your printout. Often failed with syntax errors or bugs. Plenty of time to fix it though, you can't get another run turned around before the next day.
The good thing about all that was that it taught you to have a good think about your program and check it very carefully for errors before turning it in. Which is a useful habit.
Ok, @zicog, I'll go you one better. In 1968, I was working at the radio astronomy observatory in Green Bank, W. Va. Our computer was in Charlottesville, Va, a 3-hour drive away. Every morning at 9 AM, a station wagon would leave Green Bank filled with boxes of punch cards. At the same time, a station wagon with output from running the cards from the previous day left Charlottesville. (The cars met in the middle, and switched drivers so they would both end up at home.) That meant it took 27 hours to find out you'd forgotten a parenthesis in your Fortran program.
All that being said, it takes almost 30 seconds to compile and link my 8,000 line simulator. (No, it doesn't have any macros.) That's enough time for me to lose focus on what I'm doing. The visualizer I wrote for the simulator is in JavaScript, and I can try a change in just a couple of seconds, which keeps my head in the game.
So, yes, compile + link time is a big deal because of my lost productivity. It's still a win for me, because debugging is so much simpler.
I currently have a project with ~12200 LOC, with 198 dependencies.
cargo clean; cargo build gives:
Finished dev [unoptimized + debuginfo] target(s) in 7m 53s touch src/bin/main.rs; cargo build gives:
Finished dev [unoptimized + debuginfo] target(s) in 9.83s
I don't really notice this 10s build time. It's practically instant for me, but if I were doing full builds, it might be unbearable. I'm probably ok with anything under a minute here, and 10 mins for a full build.
Incidentally, I think macros are one of the biggest red flags when it comes to compile times. Unless your macros are generating a lot of code (which can happen but is fairly atypical), the thing that takes the longest is LLVM doing its magic (even in debug mode, when it's not optimizing a lot). The second longest step is probably type checking, as constraint satisfaction solvers are nasty beasts complexity-wise. Generally, lexing, parsing, and macro expansion are rarely the real culprit.
I've found that cargo check improves edit-compile-debug iteration times by a fairly large margin, and I only invoke cargo build once I'm at the point where I actually want to run what I wrote.
I'm using IntelliJ, which shows me most compile errors as I type. The delay that annoys me comes when compiling the program to run it to check for logic errors.
"It's estimated that developers create 70 bugs per 1,000 lines of code and that fixing a bug takes 30 times longer than writing a line of code,..."
Which is kind of inline with other estimates.
Let's stick a finger in the air and assume only half of those bugs are sloppy use of memory that using Rust would prevent. After all you have tests in place for logic errors, right? So that is 15 time longer to fix than write.
I conclude that if the limit to your rate your production is the compile time, then a compiler cam be 15 times slower than what you are used to and you are still breaking even in productivity overall.
On a slightly different tack, perhaps ones productivity should not be limited by compile time. If one understood ones problem (and solution) well and if one understood ones programming language well then waiting for a compiler should only be a small percentage of your time.
Consider a mathematician creating a 100 page proof of some theorem he has come up with. Typically he cannot compile that to check for correctness. He has to understand what he is writing and check it very carefully before publishing.
Perhaps we should all practice more of the discipline of the mathematician and practice less of the "hack it and see" style of the Javascript programmer.
These have been a bunch of conversations on the compiler team about "how fast is fast enough".
Personally, the biggest thing is that writing rust is often error-message-driven, so to me the core thing I need to be fast-enough is that "you missed a comma", "you forgot a mut", "that's the wrong type", etc loop needs to be fast enough that I don't go check my phone while it's running. From the research I've seen, that's about 10 seconds, though of course I'd rather a "conversational" response time (~2 seconds -- imagine asking a friend a somewhat-complicated question and how fast they could reasonably respond that doesn't make it seem like they ignored what you said).
I think that once it's past check-type things, I'm ok if it takes somewhat longer.
I would love though if my LaTeX equations were checked for correctness automatically. Put it differently, I believe that for mathematics, the way forward is automatic formal verification. Not just that of programs, but that of other, different constructs as well.
