Is making the rust compiler slow a billion dollar mistake?

4 points by breatheoften 308 days ago | 10 comments

Just wondering if other folks feel growing dissatisfaction with the fact that the current leading modern system programming language does not include fast compilation as one of its fundamental design goals.

To me -- this seems like an obvious candidate for a future 'billion dollar' mistake retrospective essay.

How and why is it that 'support fast compilation' isn't a necessary pre-condition for any modern language hoping to achieve serious usage?

With rust in particular -- it seems like a whole lot of the slow compilation behaviors are not fundamental to any of the most important aspects of the language ...

Is there anyone out there who has tried to fork the rust ecosystem in a way which deliberately breaks compatibility in order to chart the simplest path to a fast, scaleable compilation strategy for the language and ecosystem?

I have a feeling that such an effort -- rust with some misfeatures removed, and with the package system simplified in order to speed up compilation would actually take off and be able to replace the current ecosystem relatively quickly ...

MeetingsBrowser 308 days ago |

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.

toast0 307 days ago |

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.

bjourne 308 days ago |

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.

afdbcreid 308 days ago | |

None of the passes rustc does are whole-program. LLVM does some whole-program passes, but that's also true for C++.

bjourne 307 days ago | | |

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.

steveklabnik 308 days ago | |

Rust specifically avoids doing whole program analysis.

ActorNightly 307 days ago |

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.

steveklabnik 307 days ago | |

You can absolutely leak memory in rust. There’s even an API for doing it easily. (Box::leak)

yogibear678142 307 days ago |

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.

dapperdrake 308 days ago |

Is a breaking change really needed? Can there be ABI compatibility and just less (slow) optimization?