"Viable" in scare quotes, as it should be. Note that the third one you listed is forked from the second one with licensing credit stripped. None of them are actually used by anybody programming anything real. Calling this commoditization is ridiculous. Commodization of being able to post superficially impressive claims that get upvoted to the front of HN while drowning out content that has >0 value to anyone on the planet, I suppose.
Somehow always, someone somewhere rediscovers that cutting down the time between coding and code execution makes our lives easier and to a degree be able to write better programs.
Perhaps the earliest and best attempt was Lisp's computational model. Since then, the idea manifested itself again[1], again[2], and again[3] in different forms.
This implies that Rust build times haven't been a topic of discussion for the last 10 years. They don't have long build times just for funsies, Rust is completely different from Lisp.
But there's not really a great reason for the long build times. There are plenty of languages that compile very fast. The Rust borrowchecker isn't the source of the bulk of the slowness. It seems to be a combination of language design (e.g. they didn't design it for fast compile times from the start), and implementation decisions. It does seem like there's room for a Rust-like language with Go-like tooling, standard lib, and a focus on development speed.
It remains to be seen whether you can have a useful borrow checker on top of a simpler type system (at least, a type system that's significantly simpler so as to meaningfully reduce compile times). I have my doubts, personally.
Relax runs the borrow checker 'lazily' so it already starts your app whilst the borrow checker runs asynchronous. It's jokingly called 'gandalf' because I think It halts the JIT if it finds a problem.
The borrowchecker is not the source of the bulk of the language's slowness. It takes a fairly small fraction of the total time, I think I remember the number was 5%-15% depending on the project.
The majority of time is spent between the trait solver and LLVM optimization passes. There is work being done to improve the trait solver and to produce more efficient LLIR code from the get-go (so LLVM has less to optimize).
The Rust compiler, while not extremely fast, is not extremely slow either. As an example, my toy compiler is 130K LoC of Rust and compiles in under 7 seconds on a cold build on my M5 Max. An incremental build is nearly instant. So then why is it that so many projects have a minute compile time with far fewer LoC?
The answer: dependencies (My compiler has virtually none, intentionally)
Rust has a very small stdlib, so you are forced to bring in dependency crates, and not just a few. Many programs have 50-100 or more, and they all have dependencies, and so on. Contrast with Go where it has a culture of few dependencies, and those project have few dependencies. Your Rust compiler is doing a lot more work for what appears to be the same program as in other langs, but ultimately is a lot more code (typically).
To make matters worse, cargo does a decent job of parallelizing the builds, but it can only do so a) at the crate level b) only as much as the dependency graph allows.
I love the language, but I'm still not convinced by Rust's skinny stdlib approach. I appreciate not wanting to end up like python where they're having to remove stuff from the stdlib because it has too many batteries and bitrot is a problem, but there's surely a happy-medium somewhere along the line.
I don't write much Go but it seems like it has a good balance when I do.
It may be a bad example, but even in rust generating a random number involves pulling in 6ish crates
I beg to differ. It's not that Rust is completely different from Lisp. PL writers get so caught up with their 'killer feature' which in the case of Rust is the borrow checker, that they completely abandon the other 50% which is the environment.
If we stopped treating the compiler as a one-shot program, we could theoretically shorten this edit-build-test loop by 99%.
The borrow checker is an example of a certain kind of reasoning that Rust benefits from. There's a reason a Lisp can be inspected and rewritten as the process runs, and it's the same thing that makes Rust difficult to rewrite in the same way. Not sure the exact term for it, but it's very easy to have profound nonlocal effects, for example with TAIT (type alias impl trait).
The borrow checker doesn't rely on interprocedural analysis. The function prototype provides all the information needed to maintain lifetime invariants across functions, so given static typing already then interprocedural borrow checking is effectively zero cost at compile time. (Cf. Intraprocedural, non-lexical borrow checking.) So borrow checking is no impediment to dynamically replacing function definitions. And it would be less of a headache for intraprocedural REPL but-for non-lexical semantics. But in a REPL you could always use an interpreter for running a function currently being edited, then compile it down once complete. REPLs are a headache for languages like Rust because of static typing generally, generics, trait semantics, etc.
I built something similar - tbd on maintaining it - but I got Rust Analyzer emitting code and as well as running in the web. This new concept of rust compile daemon is pretty sick.
Rust is a nice language but it’s so heavy. Since our company switched from Go I’ve had to become used to my laptop being burning hot and stuttering whilst trying to do anything during compilation.
AI maintains it, and its developer tooling really. The main use case is hotloading for LLM's to reduce wait-for-result time and to allow applications other be hot-debugged. Pause on panic is one of its main features I use all the time.
Yeah, this is pretty much a textbook example of what AI agents make possible these days: things that are ridiculously ambitious, but aren't conceptually very difficult (or, at least, are conceptually well-trodden ground). Things like emulators, language runtimes, platform reimplementations like Darling, etc.
JITting Rust isn't conceptually very hard: you just take rustc and make everything dynamic instead of static. The only thing that was stopping it before was the sheer amount of effort. Well, now we have a way to reduce that effort.
Its only prompt is 'make a flashy website for this project'. I think it's fine who reads websites anymore anyway. Readme.md for GitHub is the main thing.
Perhaps a cynical take, but I feel sloppy content advertised seriously is enabling a transparent form of cross-domain self-selection which can be interesting to observe from the outside.
For quick iterations it's perfectly fine. Change something, see if it works. If it doesn't keep changing until it works.
In runtimes that provide quick dev loops some developers have continiously running unit testing sessions. They just fire off every few seconds and give intimidate feedback.
Pretty wild to me that AI has enabled the commoditization of one of the gnarliest engineering problems. Over the course of just a month, we now have three "viable" AI-driven iteration-focused Rust compilers: - https://github.com/makepad/relax - https://github.com/DioxusLabs/rustd/ - https://github.com/indexable-inc/blaze
I'd like to throw my low-token-budget hat in the ring:
https://github.com/haydenflinner/rust/blob/main/PLIRON.md
iteration-focus is slightly there, i.e. fast hotpatching. But been focused on beating LLVM's compiled runtime performance as of late.
"Viable" in scare quotes, as it should be. Note that the third one you listed is forked from the second one with licensing credit stripped. None of them are actually used by anybody programming anything real. Calling this commoditization is ridiculous. Commodization of being able to post superficially impressive claims that get upvoted to the front of HN while drowning out content that has >0 value to anyone on the planet, I suppose.
Somehow always, someone somewhere rediscovers that cutting down the time between coding and code execution makes our lives easier and to a degree be able to write better programs.
Perhaps the earliest and best attempt was Lisp's computational model. Since then, the idea manifested itself again[1], again[2], and again[3] in different forms.
[1]: Inventing on Principle, Bret Victor: https://www.youtube.com/watch?v=PUv66718DII
[2]: REPL-Driven Development, Stuart Halloway: https://vimeo.com/223309989
[3]: LIVE, Live Programming workshop: https://liveprog.org/
Spot on, hence why having a mix of JIT/AOT tooling is such a great experience.
Besides your examples, Eiffel, Oberon, Java, .NET, C++ (yep even for it), Cedar, Standard ML, OCaml, Haskell, Prolog, BASIC, Forth
This implies that Rust build times haven't been a topic of discussion for the last 10 years. They don't have long build times just for funsies, Rust is completely different from Lisp.
Haskell, Standard ML and OCaml have the tools for faster development workflows, or going for lunch while producing an optimised build.
It is a matter of priorities.
But there's not really a great reason for the long build times. There are plenty of languages that compile very fast. The Rust borrowchecker isn't the source of the bulk of the slowness. It seems to be a combination of language design (e.g. they didn't design it for fast compile times from the start), and implementation decisions. It does seem like there's room for a Rust-like language with Go-like tooling, standard lib, and a focus on development speed.
It remains to be seen whether you can have a useful borrow checker on top of a simpler type system (at least, a type system that's significantly simpler so as to meaningfully reduce compile times). I have my doubts, personally.
Relax runs the borrow checker 'lazily' so it already starts your app whilst the borrow checker runs asynchronous. It's jokingly called 'gandalf' because I think It halts the JIT if it finds a problem.
The borrowchecker is not the source of the bulk of the language's slowness. It takes a fairly small fraction of the total time, I think I remember the number was 5%-15% depending on the project.
The majority of time is spent between the trait solver and LLVM optimization passes. There is work being done to improve the trait solver and to produce more efficient LLIR code from the get-go (so LLVM has less to optimize).
The Rust compiler, while not extremely fast, is not extremely slow either. As an example, my toy compiler is 130K LoC of Rust and compiles in under 7 seconds on a cold build on my M5 Max. An incremental build is nearly instant. So then why is it that so many projects have a minute compile time with far fewer LoC?
The answer: dependencies (My compiler has virtually none, intentionally)
Rust has a very small stdlib, so you are forced to bring in dependency crates, and not just a few. Many programs have 50-100 or more, and they all have dependencies, and so on. Contrast with Go where it has a culture of few dependencies, and those project have few dependencies. Your Rust compiler is doing a lot more work for what appears to be the same program as in other langs, but ultimately is a lot more code (typically).
To make matters worse, cargo does a decent job of parallelizing the builds, but it can only do so a) at the crate level b) only as much as the dependency graph allows.
I love the language, but I'm still not convinced by Rust's skinny stdlib approach. I appreciate not wanting to end up like python where they're having to remove stuff from the stdlib because it has too many batteries and bitrot is a problem, but there's surely a happy-medium somewhere along the line.
I don't write much Go but it seems like it has a good balance when I do.
It may be a bad example, but even in rust generating a random number involves pulling in 6ish crates
I beg to differ. It's not that Rust is completely different from Lisp. PL writers get so caught up with their 'killer feature' which in the case of Rust is the borrow checker, that they completely abandon the other 50% which is the environment.
If we stopped treating the compiler as a one-shot program, we could theoretically shorten this edit-build-test loop by 99%.
rustc is not really a one-shot program! Incremental computation is a big part of rustc !
The borrow checker is an example of a certain kind of reasoning that Rust benefits from. There's a reason a Lisp can be inspected and rewritten as the process runs, and it's the same thing that makes Rust difficult to rewrite in the same way. Not sure the exact term for it, but it's very easy to have profound nonlocal effects, for example with TAIT (type alias impl trait).
The borrow checker doesn't rely on interprocedural analysis. The function prototype provides all the information needed to maintain lifetime invariants across functions, so given static typing already then interprocedural borrow checking is effectively zero cost at compile time. (Cf. Intraprocedural, non-lexical borrow checking.) So borrow checking is no impediment to dynamically replacing function definitions. And it would be less of a headache for intraprocedural REPL but-for non-lexical semantics. But in a REPL you could always use an interpreter for running a function currently being edited, then compile it down once complete. REPLs are a headache for languages like Rust because of static typing generally, generics, trait semantics, etc.
I built something similar - tbd on maintaining it - but I got Rust Analyzer emitting code and as well as running in the web. This new concept of rust compile daemon is pretty sick.
Can build and iterate on Rust in the browser!
https://dioxuslabs.github.io/rustd/
Rust is a nice language but it’s so heavy. Since our company switched from Go I’ve had to become used to my laptop being burning hot and stuttering whilst trying to do anything during compilation.
I’d gladly accept that for the efficiency and speed gained in prod, knowing I need to have a beefier host to compile it.
We have had good experience with kache so far to speedup builds in CI and local
How does it compare to sccache ?
Kache caches more, and is path independent, so can be shared between worktrees.
Interesting. First time I hear about Kache, I'm definitely gonna give it a try.
Anyone know what effect it has on targets/ bloat and dev disk usage?
It should be lower, but I haven't optimized it too hard on disk size. It's about iteration latency for LLM's.
I've been using "mr boxington" (mbx) the past several weeks and it's been a big help. https://mr-boxington.jdx.dev/
> 0 crates.io dependencies, in 438k lines of Rust
It's great to have zero deps, but that's a lot of code to maintain.
AI maintains it, and its developer tooling really. The main use case is hotloading for LLM's to reduce wait-for-result time and to allow applications other be hot-debugged. Pause on panic is one of its main features I use all the time.
I knew that makepad devs were focused on build times, but didn't imagine this much!
Indeed but I could only do this in the age of AI. Before a project like this was just out of reach.
This is preposterously ambitious - a complete Rust re-implementation. Looks like it's mostly claude?
Yeah, this is pretty much a textbook example of what AI agents make possible these days: things that are ridiculously ambitious, but aren't conceptually very difficult (or, at least, are conceptually well-trodden ground). Things like emulators, language runtimes, platform reimplementations like Darling, etc.
JITting Rust isn't conceptually very hard: you just take rustc and make everything dynamic instead of static. The only thing that was stopping it before was the sheer amount of effort. Well, now we have a way to reduce that effort.
Yea it's claude+codex over the course of a month. It definitely isn't a one shot.
The world really needs something like this, but why such a slop UI website.
Just tell Opus 5.5 to "redesign the UI to not look like AI slop, design it like a human expert designer would" at bare minimum.
Its only prompt is 'make a flashy website for this project'. I think it's fine who reads websites anymore anyway. Readme.md for GitHub is the main thing.
The code is slop and the website too.
Perhaps a cynical take, but I feel sloppy content advertised seriously is enabling a transparent form of cross-domain self-selection which can be interesting to observe from the outside.
Common Lisp lurks in the shadows, watching its own reinvention comfortably, yet another time
moving errors from compile time to runtime is good?
For quick iterations it's perfectly fine. Change something, see if it works. If it doesn't keep changing until it works.
In runtimes that provide quick dev loops some developers have continiously running unit testing sessions. They just fire off every few seconds and give intimidate feedback.
For some use cases, like speeding up local development, it's an excellent trade off.
It's a technology to improve iteration time with agents, or humans for live coding but nobody really writes code anymore so.