Hacker News Reader

Comment by adrianmonk | Hacker News Reader

> at best, the temptation to RiiR is unproductive

I think there are probably three cases here:

(1) You have perfectly good software and your only motivation to rewrite is infatuation with how great Rust seems. In this case, yes, that's unproductive. (Infatuation-driven design is poor engineering and is a fairly widespread problem in the software industry.)

(2) You already have other reasons to want to rewrite (design could be improved, code is in a poor state, etc.), and you're deciding between languages. In that case, a rewrite could be productive even if you didn't use Rust.

(3) You have mature software that appears relatively free of obvious, known bugs, but it's written in an unsafe language, and it would be valuable to have the additional confidence that a safe language could provide. Security-sensitive or other critical applications are where this is most likely to make sense.

View on HN

(4) You want to develop new components in rust, but it has to integrate with your existing components somehow.

Why not use ffi for this case? Many languages have robust support for linking to Rust code.

yeah sometimes that makes sense. if the lib in question in small enough it might be more valuable to port, so avoid having a multi language project, and avoid the effort of the ffi.

at least Rust -> C ffi is zero cost (usually)

Having everything available in Rust code also means you don't have to do lots of extra work for cross-compilation.

How does Rust help you if you have to cross-compile?

I'm not positive, but I think GP intended to refer to idea that you would need to multiple compilers to compile the project rather than cross-compiling to another platform.

You can compile rust in one go. If you rely on native libraries, you need to be able to link them during cargo build and that's painful to set up. Not impossible... just really annoying to manage.

How about (5) you're trying to learn Rust and you need a project to work on? Irresponsible for production code, but perfectly valid for a weekend project. And in my experience can be a great way to learn the quirks of a particular language!

> (2) You already have other reasons to want to rewrite (design could be improved, code is in a poor state, etc.), and you're deciding between languages.

It would be wise to ignore the language distraction and remember that most urges to rewrite are just flat out wrong. The standard and well respected advice about rewrites doesn't go out the window just because of a fad language, if anything they apply more strongly.

Much of what people perceive as cruft is most of the actual value-- the stored knowledge from years of experience using the software in practice. Few "clean" programs are actually complete.

Andrew Tridgell once said "you never need an excuse to rewrite something".

But I usually append that quote with "but then again, you're not Tridge" :)

Kernighan and Plauger said "don't patch bad code: rewrite it". That is definitely true. And there's a lot of bad code.

Or all of the above.

Mature software can have a bunch of hard to fix bugs that you can't motivate anyone to work on any longer. If you want to continue making progress you have to route around the damage somehow.

Reply on news.ycombinator.com