RIIR
RIIR copied to clipboard
ansuz
Personal experiences of Rust rewrites
ayzim, a conversion of the emscripten asm.js optimizer (C++) to Rust.
~7.5k lines of fairly dense code, it was a pretty harrowing experience at times as the rewrite also involved some data structures redesign for efficiency. rustc also strongly disagreed with g++ at times about what 'valid code' means. Completed it successfully (submitting fixes for some bugs I found along the way), I now use it for all of my emscripten work and it's a serious QoL improvement. Probably would have given up if it was in C and used pointers instead of references.
machroot, a rewrite and re-purposing of bubblewrap (basically docker minus the daemon) to just deal with mounts (so a chroot on steroids).
I was going to leave it as C, stripping out the parts I didn't need and adding new bits, but didn't really like how part of it was quite weakly typed so I rewrote half of it in Rust, finding some bugs on the way (submitted fixes to the original project). I then stopped because the other half seems to work fine as C and it's easy to call from Rust. Completed successfully, I use it every day as a better chroot for a dev environment.
A rewrite of the owntracks recorder. Started as a project to learn Rust (after grokking some of the source and finding some segfaults, would never expose the C version as-is). Unfinished and stalled while I do other things.
In summary, would RIIR again if itch-scratching, and apparently rewriting in Rust helps find bugs (unsure if this is unique to Rust). Would not recommend porting
- >2k dense lines at a time
- pointer heavy code
- if I didn't know Rust
- code that interacts heavily with libc and syscalls and uses pointers a lot
If C and C++ came with language-level ADTs (very useful for ayzim and machroot) and a decent package manager, none of the rewrites above would have started.
Rewrote pam_setquota in Rust, after attempting to clean up the original C version. It turned out that the rewrite took me less time (and resulted in more readable/maintainable code) than I spent fixing the original C version; moreover, despite the time I spent on cleaning up the C version, I would still be uncomfortable deploying it to production.
Currently working on a bunch of new PAM modules, and I might perhaps also RIIR pam_namespaces as I ran into bugs there that would likely require large refactors to fix in a clean way.
Great article! While I have nothing against or for rust and totally believe that people should feel free to rewrite things in Rust. I think your article rightfully elucidates that you shouldn't expect others to follow your choices.
I also like your strategy on comments.
While I've had to put the project on hold for the moment, I'm in the process of rewriting the backend portion of this experiment in Rust as I refactor it to something maintainable before working to complete it any further.
The partially-complete rewrite of the frontend portion uses PyQt+rust-cpython... though, technically, it's more that it's a single PyQt project where Rust is replacing Python function-by-function, to ensure it remains functional at every step along the way.
(The end goal being a backend that can have bindings written for use by projects like Lutris and GNOME Games and a Qt frontend I can use to experiment with UI/UX improvements I haven't seen others trying.)
I've started another one - taking small parts of bup (written mostly in Python) and implementing them in Rust to reduce memory usage (4x) and increase speed (2x). I use these bits in combination with the rest of bup as part of my overall backup strategy.
I've submitted patches for a few bugs I found during my rewrite (supporting my "rewriting in Rust helps find bugs" discovery from the original post). I've started exploring upstreaming my work at https://groups.google.com/d/msg/bup-list/DhCakXUkHjI/tNaazL30BwAJ