Integrate Rust

[0xchase]

Rizin has already made amazing progress towards it's goals of

usability, working features and code cleanliness

Over the long term, however, rizin would be greatly benefitted by integrating a modern language that can provide safety guarantees and cost-free abstractions. In this regard, Rust has emerged as the clear successor to C/C++ for performance-critical projects. The advantages of Rust over its predecessors, which I'm sure the rizin devs are familiar with, have already caused projects as large as the Linux kernel to begin integrating Rust into their existing codebase.

Some benefits for rustified rizin would include:

• Stricter compiler => fewer bugs => more usability => fewer git issues => less maintenance
• Automatic dropping instead of rz_*_free(). Fewer problems like this from 2 days ago.
• Use Rust iterators instead of rz_list_*. Cleaner code with iter(), map(), fold(), etc.
• librz could eventually be refactored into a cargo workspace, allowing people to import individual parts as crates
• Make use of the data structures in the rust standard library (Vec, HashMap, etc) (or use #[no_std] if you don't want it)
• And all the standard benefits of Rust, from crates.io to fearless concurrency
• Have a better type system backing rzil (the C type system imposed some limitations on the rzil implementation, as described here. Using Rust could improve this situation).

As far as the practical bits -- there seem to be two ways to approach this. Since most of the rizin is in pure C, it may be possible to use a tool like c2rust to mostly-automatically translate the C codebase into unsafe Rust, which can be ported to safe and elegant Rust manually over time. Alternatively, rizin could support a mixed codebase, using bindgen to generate an interface between the C and Rust bits. I'm guessing the latter solution would be smoother, and would be made easier by the fact that meson supports Rust integration and cargo can integrate with most C build systems.

Depending on the approach taken, it could create a lot of work in the short term, but I'm sure that in a year or two everyone would be glad about the migration/integration. A successful migration would surely generate a lot of interest in rizin.

I acknowledge that this suggestion is a bit audacious -- but regardless of if the core team is interested in undertaking this effort, I'd be interested to hear their thoughts on it, including reasons this is a bad idea or infeasible.

[wargio]

to be honest i would love to, but i think for now our priority is to reach 1.0 and cleanup.
@XVilka

[0xchase]

Would waiting for this until after 1.0 create extra work? i.e. refactoring code in C for 1.0 then re-refractoring code into Rust?

If not then perhaps this could be for rizin 2.0

[wargio]

there is a reason: most of us are not that comfortable with rust plus there is a lot of code that needs a lot of love

[XVilka]

My opinion is simple - I do write and love Rust but Rizin code is huge (more than 2M+ lines of code if you count all projects under rizinorg), rewriting it would be immense effort that with our limited resources could span for decades. If I write something like that from scratch, I would certainly use Rust.

For creating Rust plugins providing the C API - sure, you can do it right now.

Another thing about Rust - it's not as portable as C just yet - some of the targets where Rizin can work right now wouldn't be possible if we rewrite it, think, for example, MacOS PPC, or HPPA. Rizin is a special case due to being debugger as well, supporting old platforms like Debian Wheezy, which we even test on our CI.

[0xchase]

Is there a viable middle ground where some core code and most new code use Rust, while the rest stays as C? For example, maybe the IL and analysis code use Rust?

I definitely agree it can't all be ported manually. I'm more wondering if there would be benefits to a hybrid codebase. Or if I took the time to translate most of it using something like c2rust (if such a thing didn't introduce bugs), whether the dev team would be interested.

[wingdeans]

A hybrid approach would still hinder portability, although I'm not sure how large of an issue this is (being able to build anywhere with c + ninja + meson is very nice though). More importantly, it would change the contributor skill requirements, and there's no guarantee that new contributor interest would exceed lost contributions from switching.

I think another way the rust vision could start is with a remacs-style fork where rust is substituted in piece-by-piece. Not only would this provide a direct comparison of code quality and architecture, it also gauges community interest. This is work that needs to be done for a hybrid rizin anyways, so it isn't necessarily wasted effort. I think a rust fork of rizin would also have to demonstrate an ability to port over the harder bits for the benefits of rust to meaningfully apply.

Admittedly, remacs interest did fizzle out, partly due to being unable to merge upstream changes, which is definitely a drawback of a hard fork. I'm also hesitant to suggest further fragmentation of open source reversing environments. However, I think such a fork is the best way to explore rust in rizin, even if it ends up like remacs and doesn't get upstreamed.

[karliss]

Wasn't there one rust rewrite from scratch attempt before done by one of rizin or r2 devs? Can't remember who tried that and the name of repository.

[0xchase]

You're probably thinking of rair. To be clear, I'm suggesting a hybrid codebase rather than a rewrite, unless the latter can be automated.