Perfect is the enemy of good, and Rust's compile times are good enough.
When choosing between languages, compile times should be a tie-breaker at most.
If Rust had focused on super fast compilation from the start, it probably would have slowed developing the features that actually made it successful.
Its like a startup that spends forever building the perfect scalable backend instead of just solving customer problems. The hacky solution usually wins.
> Is there anyone out there who has tried to fork the rust ecosystem ... I have a feeling that such an effort ... would actually take off and be able to replace the current ecosystem relatively quickly
Forking the entire Rust ecosystem seems pretty unlikely to work, but everything's open source so anyone can give it a shot.
I use rust for work, and yeah, the compiler is slow, and that reduces the number of change / compile / test cycles I can do. But rust isn't the only slow part of my work, and some days, it's not even the slowest part of my work.
I've used other languages and environments with faster cycles, and I feel more productive and happy, but working isn't usually about maximizing my feelings of productivity and happiness, so there you go.
I've also worked with plenty of mainstream languages and environments that were about as bad or worse. You just adapt and post on HN while the compile / deploy is running, rather than getting things done quickly. I suspect compile times will improve at some point, perhaps when I get twice the number of cores; a lot of times software expands to fill the growing hardware, but my work project is well scoped and not likely to expand that much.
I think the problem lies within Rust itself. It requires devs to think in a very different way, and write explicit code with borrows.
When writing an application, the ideal would be to write all the wrapper and high level code in a language like Python, while having the performance low level code that shares memory in Rust. Right now this requires a lot of setup.
I believe the Rust compiler does whole program analysis or, at least, something very similar in spirit. Hence, unless you completely change how the language works it can't be as fast as a simpler compiler. You can work around it by having a daemon that incrementally compiles only changed parts, but then you need to have that daemon running and it's never as smooth as one command that compiles quickly. In other words, yes, I think you are right. Slow compile times reduce adoption.
Well, I wrote "in spirit". The point is that Rust, on average, needs to recompile much more code per change than a language that relies on small and self-contained compilation units.
Perfect is the enemy of good, and Rust's compile times are good enough.
When choosing between languages, compile times should be a tie-breaker at most. If Rust had focused on super fast compilation from the start, it probably would have slowed developing the features that actually made it successful.
Its like a startup that spends forever building the perfect scalable backend instead of just solving customer problems. The hacky solution usually wins.
> Is there anyone out there who has tried to fork the rust ecosystem ... I have a feeling that such an effort ... would actually take off and be able to replace the current ecosystem relatively quickly
Forking the entire Rust ecosystem seems pretty unlikely to work, but everything's open source so anyone can give it a shot.
I use rust for work, and yeah, the compiler is slow, and that reduces the number of change / compile / test cycles I can do. But rust isn't the only slow part of my work, and some days, it's not even the slowest part of my work.
I've used other languages and environments with faster cycles, and I feel more productive and happy, but working isn't usually about maximizing my feelings of productivity and happiness, so there you go.
I've also worked with plenty of mainstream languages and environments that were about as bad or worse. You just adapt and post on HN while the compile / deploy is running, rather than getting things done quickly. I suspect compile times will improve at some point, perhaps when I get twice the number of cores; a lot of times software expands to fill the growing hardware, but my work project is well scoped and not likely to expand that much.
I think the problem lies within Rust itself. It requires devs to think in a very different way, and write explicit code with borrows.
When writing an application, the ideal would be to write all the wrapper and high level code in a language like Python, while having the performance low level code that shares memory in Rust. Right now this requires a lot of setup.
You can absolutely leak memory in rust. There’s even an API for doing it easily. (Box::leak)
Ya it's a mistake. But there's a trade off for everything. You can't have every positive attribute as some are mutually exclusive.
You could remove generics and speed up the compiler a ton. Then people will be asking if lack of generics was a language design mistake.
I believe the Rust compiler does whole program analysis or, at least, something very similar in spirit. Hence, unless you completely change how the language works it can't be as fast as a simpler compiler. You can work around it by having a daemon that incrementally compiles only changed parts, but then you need to have that daemon running and it's never as smooth as one command that compiles quickly. In other words, yes, I think you are right. Slow compile times reduce adoption.
None of the passes rustc does are whole-program. LLVM does some whole-program passes, but that's also true for C++.
Well, I wrote "in spirit". The point is that Rust, on average, needs to recompile much more code per change than a language that relies on small and self-contained compilation units.
Rust specifically avoids doing whole program analysis.
Is a breaking change really needed? Can there be ABI compatibility and just less (slow) optimization?