Relax: JIT compiler for Rust to reduce build times (makepad.github.io)

130 points by adamnemecek a day ago

_cart 6 hours ago

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

medler 3 hours ago

The Cranelift compiler is in the same space, has been around for over a decade, and is actively maintained: https://en.wikipedia.org/wiki/Cranelift

zamadatix 2 hours ago

I'm not sure the Rust JIT feature looks far enough along/well maintained enough to actually work with a typical rust program and when it does it sounds like it's probably slower than AOT anyways https://github.com/rust-lang/rustc_codegen_cranelift/blob/ma...

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."

392 4 hours ago

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.

anonymous908213 4 hours ago

"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. Commoditization 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.

faresahmed 9 hours ago

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/

pjmlp 7 hours ago

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

Capricorn2481 8 hours ago

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.

pjmlp 7 hours ago

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.

christophilus 8 hours ago

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.

pcwalton 7 hours ago

treyd 6 hours ago

nu11ptr 6 hours ago

faresahmed 8 hours ago

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%.

LoganDark 8 hours ago

Ar-Curunir 6 hours ago

jkelleyrtp 8 hours ago

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/

Sytten 9 hours ago

We have had good experience with kache so far to speedup builds in CI and local

n_u 9 hours ago

How does it compare to sccache ?

jtwaleson 8 hours ago

Kache caches more, and is path independent, so can be shared between worktrees.

aabhay 3 hours ago

TheMrZZ 6 hours ago

cedws 5 hours ago

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.

TakerofVita an hour ago

yeah, I've been doing some game dev with rust, and the cost of iteration is hugely higher (though it has been worth it so far). Often a build takes 10min+. Something like this project would help a lot if it supported windows.

It is pretty noticeable if you have agents working in subtrees too, a fresh build in a worktree can be like 20min with bevy

evulhotdog 4 hours ago

I’d gladly accept that for the efficiency and speed gained in prod, knowing I need to have a beefier host to compile it.

kennykartman a day ago

I knew that makepad devs were focused on build times, but didn't imagine this much!

rikarendsmp 5 hours ago

Indeed but I could only do this in the age of AI. Before a project like this was just out of reach.

scottmas 7 hours ago

Anyone know what effect it has on targets/ bloat and dev disk usage?

rikarendsmp 5 hours ago

It should be lower, but I haven't optimized it too hard on disk size. It's about iteration latency for LLM's.

jonstewart 8 hours ago

I've been using "mr boxington" (mbx) the past several weeks and it's been a big help. https://mr-boxington.jdx.dev/

ricardobeat 6 hours ago

> 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.

rikarendsmp 5 hours ago

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.

ridiculous_fish 8 hours ago

This is preposterously ambitious - a complete Rust re-implementation. Looks like it's mostly claude?

pcwalton 7 hours ago

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.

rikarendsmp 5 hours ago

Yea it's claude+codex over the course of a month. It definitely isn't a one shot.

baq 7 hours ago

Common Lisp lurks in the shadows, watching its own reinvention comfortably, yet another time

tontinton 9 hours ago

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.

rikarendsmp 5 hours ago

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.

hn_submit 6 hours ago

The code is slop and the website too.

poly2it 7 hours ago

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.

measurablefunc 2 hours ago

Nice project.

Surac 8 hours ago

moving errors from compile time to runtime is good?

andix 7 hours ago

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.

jtwaleson 8 hours ago

For some use cases, like speeding up local development, it's an excellent trade off.

rikarendsmp 5 hours ago

It's a technology to improve iteration time with agents, or humans for live coding but nobody really writes code anymore so.