Comment by Mawr
20 hours ago
You can have your house built fast, cheap, or well. Pick two; or a bit of all three that adds up to the same effort required. You can't have all three.
You can't have a language with 100% of the possible runtime perf, 100% of the possible compile speed and 100% of the possible programmer ease-of-use.
At best you can abuse the law of diminishing returns aka the 80-20 rule, but that's not easy to balance and you run the risk of creating a language that's okay at everything, but without any strong selling points, like the stellar runtime performance Rust is known for.
So a better way to think about it is: Given Rust's numerous benefits, is having subpar compilation time really that big of a deal?
I think this qualitative argument is made but is very unsatisfying for something as quantitative as compilation or runtime speeds.
It leads to blithe things about how there's no such things as zero-cost abstractions. But at one point the cost is so low and amortized that you're looking at something that's basically free.
What is the compilation cost of the `?` syntax shorthand? Probably quite low!
What about the compilation cost of underscores in number literals? Again, quite low?
To this point a bit, I think a lot of people talk about the borrow checker, but my understanding is it's fairly low cost, and I don't worry about it.
Monomorphisation costs though? That feels like something that could generate a lot of work.
> Given Rust's numerous benefits, is having subpar compilation time really that big of a deal?
As someone who uses Rust as a daily driver at work at zed.dev (about 600K LoC of Rust), and Zig outside of work on roc-lang.org (which was about 300K LoC of Rust before we decided to rewrite it in Zig, in significant part because of Rust's compilation speed), yes - it is an absolutely huge deal.
I like a lot of things about Rust, but its build times are my biggest pain point.