←back to thread

217 points varbhat | 1 comments | | HN request time: 0.201s | source
Show context
jkelleyrtp ◴[] No.44371543[source]
Creator here - haven't had a chance to write up a blog post yet! Stay tuned.

The gist of it is that we intercept the Rust linking phase and then drive `rustc` manually. There's some diffing logic that compares assembly between compiles and then a linking phase where we patch symbols against the running process. Works across macOS, Windows, Linux, iOS, Android, and WASM. On my m4 I can get 130ms compile-patch times, quite wicked stuff.

We handle the hard parts that the traditional dylib-reloading doesn't including TLS, statics, constructors, etc.

I've been posting demos of it to our twitter page (yes twitter, sorry...)

- With bevy: https://x.com/dioxuslabs/status/1924762773734511035

- On iOS: https://x.com/dioxuslabs/status/1920184030173278608

- Frontend + backend (axum): https://x.com/dioxuslabs/status/1913353712552251860

- Ratatui (tui apps): https://x.com/dioxuslabs/status/1899539430173786505

Our unfinished release notes are here:

https://github.com/DioxusLabs/dioxus/releases/tag/v0.7.0-alp...

More details to come!

replies(5): >>44372393 #>>44373080 #>>44374315 #>>44374673 #>>44374679 #
1. bjackman ◴[] No.44374673[source]
[How] do you track when it's safe to delete the old version of a patched piece of code?

Edit: or, I guess since this doesn't seem to be something intended for use in prod, maybe that's not necessary. You can just bloat the runtime process more or less indefinitely.

I was curious because IIUC Linux kernel livepatches handle this via something related to RCU, which I guess is not possible in this context.