Relax: JIT compiler for Rust to reduce build times
makepad.github.io
makepad.github.io
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.
I think it also only does the backend? I.e. you still need rustc to compiler to do everything but the codegen whereas this seems to be the whole compiler portion of the toolchain "Relax isn't a wrapper around rustc or a plugin for LLVM: it replaces both, and the parts of Cargo and the linker in between."
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/
If we stopped treating the compiler as a one-shot program, we could theoretically shorten this edit-build-test loop by 99%.
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 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
└── rand v0.10.3
├── chacha20 v0.10.2
│ ├── cfg-if v1.0.5
│ └── rand_core v0.10.1
├── getrandom v0.4.3
│ ├── cfg-if v1.0.5
│ ├── libc v0.2.191
│ └── rand_core v0.10.1
└── rand_core v0.10.1That said, I missed the borrow checker.
For all of Python's warts, it at least makes everyday structures and operations you might want to use fairly painless, and it keeps expression fairly standardized. Leave external libraries to build things that are actually interesting, rather than scaffolding and infrastructure that the language vendor is better off providing.
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).
It is a matter of priorities.
Besides your examples, Eiffel, Oberon, Java, .NET, C++ (yep even for it), Cedar, Standard ML, OCaml, Haskell, Prolog, BASIC, Forth
Can build and iterate on Rust in the browser!
It is pretty noticeable if you have agents working in subtrees too, a fresh build in a worktree can be like 20min with bevy
It's great to have zero deps, but that's a lot of code to maintain.
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.
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.
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.