XRPL Rewrite From A Developers Perspective...
Lots of talk about re-writing rippled in Rust. Thanks @sentosumosaba for promoting the conversation. For those interested in the perspective of a dev, here it is…
Rewriting rippled in Rust sounds like a smart move at first glance. Rust is safe, modern, and quickly becoming the language of choice for blockchain infra. It has advantages such as memory safety and generally accepted better tooling so the advantages feel compelling. I can understand the excitement.
But here’s the problem: rippled is a deeply complex, performance-critical system. The codebase has been battle-tested for over a decade, with optimisations that only come from years of iteration. Rewriting that in a new language, no matter how good that language is, isn’t just about porting code. Trust me, I’ve done this on smaller scale projects and believe me, it will become a re-write, it’s just the nature of refactoring as you go, the opportunity to rebuild it better will be too much; it’ll take twice as long as anyone thinks and cost three times as much, plus the reputational risk alone for potentially a trillion dollar chain by the time this is complete is staggering.
Best-case, this is a multi-year, multi-million-dollar effort. And worse, during that time, progress on actual XRPL features, the stuff users care about, slows to a crawl because people know we’re counting down time until the inevitable switch.
There’s also the people factor which in my view is massive. The devs who know the internals of rippled are mostly C++ veterans. Asking them to drop what they know and switch to Rust en masse isn’t trivial. You either lose them or spend time retraining which removes forward progress of the current codebase. Either way you lose progress or people, neither of which is good.
A better approach might be to selectively bring Rust into the ecosystem, which in my view is likely what @JoelKatz is thinking… start with tooling, test infrastructure, or isolated modules. Use it where it makes sense, bring in a new breed of developer and if Rust proves itself inside the XRPL stack, maybe a Rust-based node emerges organically and if not it probably shouldn’t.
What I do agree with though, that I read into from what David said is that there is recognition of work to be done, such as architectural documentation and evaluation and this doesn’t require moving to rust. Replacing C or Rust outright, right now would be like rebuilding the engine of a race car while you’re in the middle of a Grand Prix season, where you’re in a leading position, the risk isn’t worth it for the potential gains.
Whatever way you shape this, it will cost millions so what I’d rather see that money invested into a properly funded core dev team and slowly iterate to the same place; this is safer and smarter for all the reasons I’ve outlined.
Above all though, I’m supportive of the underlying reasons for the conversation and whatever route we end up going, it will have my support. I’d very much love the opportunity to flesh this out with other devs on a space and hear both sides. @angell_denis up for it?
https://x.com/krisdangerfield/status/1951659656037937480