
Why Not Rewrite It in Rust? (2016) - bishala
https://transitiontech.ca/random/RIIR
======
seren
Writing a few lines of "why not rewriting it in XXX" is more a sign of
inexperience or immaturity in my humble opinion.

Maybe it is a good idea, but if you are going to propose to a dev team a
massive rewrite that will take months or years, you should at least have the
decency to analyze the code base, do a small POC, profile some part and point
out where the improvement could happen. (And if you've discovered something
that could be improved, you are more likely to convince people to rewrite only
this part than everything)

Otherwise, it seems a bit cheap, and more something that someone repeats
without necessarily understanding deeply because it is in the zeitgeist. It is
probably also a bit of magical thinking, if we rewrite all our current problem
will go away.

~~~
_bxg1
Programmers, especially naive ones, tend to think asymptotically. We focus on
what would be the most theoretically ideal and write off pithy concerns like
"time" and "effort" as implementation details. I'm guilty of this myself.

Rust is this unusual situation where a new language is in many ways a strict
improvement over a very widely-used preexisting language. That is extremely
rare. So I think that's where the religious fervor comes from.

Would the world be a better place if Tor and the Linux Kernel and every C++
project out there had originally been written in Rust (setting aside the fact
that this was obviously impossible)? Sure, maybe. But those projects also
benefit from decades of refinement and bug fixes. Rewriting them means losing
all of that. As an idealistic programmer it's tempting to write factors like
legacy refinement off into the margins, but they're actually very significant.
A piece of software's value doesn't solely reside in its preconceived design.

~~~
lmm
> those projects also benefit from decades of refinement and bug fixes.
> Rewriting them means losing all of that.

Not my experience at all, having spent a significant chunk of my career doing
rewrites for scalability. Having the existing codebase makes it very easy to
benefit from the accumulated knowledge, while at the same time doing a pass
through that can catch a lot of outright errors. If you can rewrite a project
incrementally while keeping it working (and for C->Rust, you can), then the
arguments against rewriting your code don't apply, and I'd actually consider
full rewrites a useful exercise even if you weren't rewriting to a better
language.

~~~
AnimalMuppet
Maybe. But even with the old code base for reference, it's easy to not see
that those weird lines right there are written the way they are to handle two
different corner cases (and of course there's no helpful comments to explain
it). This is especially true if you're rewriting from $MORE_OPAQUE_LANGUAGE to
$CLEARER_LANGUAGE. There can be a lot of not obvious things going on in the
opaque stuff, and you can drop things you need in the rewrite unless you are
_very_ careful.

As carlmr points out, tests can help a lot... if you've got tests for those
corner cases. They can be new tests, created as part of the rewrite - if
anyone remembers that they are needed, or if anyone can see the corner cases
either in the problem space or in the code. (This argues for doing the rewrite
while the original authors are still around, preferably with them as part of
the rewrite team.)

~~~
_bxg1
Right. Put differently: any sufficiently long-lived codebase contains
institutional knowledge. Knowledge that goes deeper than just the explicit
interface boundaries that you're planning to re-implement. That doesn't mean
rewrites are a _bad_ idea, just a disruptive one. They'll introduce new
fragility for a while before they start being a net gain. Code has to be
broken-in, like a new pair of shoes.

------
maeln
There will always be inexperienced people who just learned about "cool
language X" and go on a crusade everywhere they go about why Y is not written
in X with obvious disregard on how difficult (and often useless?) rewriting a
whole project is.

I remember seeing a post on a Qt mailing list asking if there were plan to
rewrite Qt in Erlang.

At least it usually come from a good place and they tend to be polite about
it. Better than a lot of open-source freeloader getting angry because B is
still not implemented in A ...

~~~
dmix
Qt in Erlang is a good one.

------
keldaris
I feel like all the language comparisons are largely missing the point, at
least for me. I don't write (mostly orthodox) C++ because it's a great
language. In fact, I think it's a terrible language, hampered by a myriad of
systemic issues that will never be addressed and seem to be getting worse over
time.

However, I also don't write code in a vacuum and other things matter more to
me than language features. First-class GPGPU support, a mature ecosystem
(including some of the highest quality, most efficient code that exists),
vastly superior tooling, multiple established compilers, good C compatibility,
the list goes on. The purported advantages of Rust, such as the trait system
(which is legitimately great), the static safety guarantees (which I
personally don't care about at all) and others pale in comparison.

If you really like Rust, you don't address these things by obnoxiously
evangelizing language features. You address them by building up the ecosystem,
improving the tooling, making the language more pleasant to use and eventually
advocating for important vendors to include first class support for Rust in
their products. Then, and only then, might this kind of in your face
evangelism make some sense, if we ever get there - and the way towards it is
paved with patience and lots of hard work, not opening GitHub issues.

~~~
mrkeen
If you had a code base in Rust would you consider rewriting it in a language
with First-class GPGPU support, a mature ecosystem (including some of the
highest quality, most efficient code that exists), vastly superior tooling and
multiple established compilers?

~~~
keldaris
Depends on the codebase. If one of those things could qualitatively improve my
codebase - for instance, by introducing GPGPU support and speeding everything
up by an order of magnitude - I very well might. Ultimately, it's a cost-
benefit calculation that has to be done for every individual case, it's not
something you can answer in the abstract. None of the language features of
Rust can offer a similar level of advantage, except perhaps in cases where
(limited) static guarantees of certain kinds of memory safety are of critical
importance.

------
jasonhansel
My humble opinion: it is almost never worth rewriting a large codebase in a
new language. The only exceptions are if (a) the old language is so old that
it lacks an active community and is no longer being improved, or if (b) the
old system needs so many changes that you might as well rewrite it anyway.

~~~
erik_seaberg
The old system needs a big change; it's flaky and riddled with security flaws
because the old language encourages undefined behavior. C was a big
improvement on assembly, but it's also the leading reason everything we rely
on fails frequently.

~~~
jasonhansel
I agree! But the cost of such a move across the industry would be _incredibly_
high, probably taking decades of highly expensive investment. Is it really
worth the cost for all projects?

------
hu3
"rewrite in X" request is a comon sign of immaturity. I'm guilty of it but
eventually I learned that A) rewrites are rarely worth it B) it's
disrespectful to ask others to scrap their code and rewrite it in my favorite
language

~~~
phkahler
One of my favorite apps at the moment seems like it could benefit from a
rewrite, in part because core pieces have long standing bugs that may only be
solved by someone doing the very deep dive a rewrite would entail. I thought
long term it might be nice if it were written in Rust. But rather than suggest
RIIR I considered writing a component of it in Rust myself. That would be
educational for me and would bring something new to the "Rust ecosystem".
Having written similar code before (in C++) I realized just how huge a task
rewriting just a core component would be. It could take a decade or more to
rewrite an entire program in any language even with all devs working on it.

Look at Servo. Hey, they started building a browser in Rust! And some of those
components are useful in Firefox. But Servo itself might never become a fully
functional browser. And that's a project from the folks that created Rust and
Firefox. So maybe a response to RIIR could be "Yeah, when is Servo going to be
done?"

------
asdkhadsj
I know RIIR appears to offend a lot of C/C++ devs, and I understand why. I do
however, think RIISSL (Rewrite It In Some Safe Language) is a real meaningful
thing.

The reason Rust is the figure head for this is because I've not seen other
languages with any amount of popularity take "safety" to the degree Rust has.
I imagine there are others, I recently saw bounded array types in Ada and
thought it was cool, but Rust definitely has the momentum.

This isn't to say that I'm justifying RIIR. I'm justifying RIISSL. To which
currently, there aren't many.

In the future I hope to see _many_ safe languages. I love Rust, but I'm super
excited for the next language that blows Rust out of the water on safety and
usability. I hope RIISSL is a thing in the future, and I hope there are more
options so that Rust doesn't get so much unneeded hate over RIIR :)

I really do love Rust though.

 _edit_ : I should amend, RIISSL is only applicable where safety matters. I
could definitely see arguments where all common unix tooling matters, as even
find could have security implications. Yet, `find` compared to SSL
implementations are vastly different for RIISSL.

~~~
geodel
> I know RIIR appears to offend a lot of C/C++ devs, and I understand why. I
> do however, think RIISSL (Rewrite It In Some Safe Language) is a real
> meaningful thing.

It is not meaningful for open source projects where RIIR or even RIISSL types
jump in and start offering unsolicited advice to contributors. These folks can
fork and/or make some POC etc if they seriously believe it is a net win.

~~~
ncmncm
In fact, the amount of successful penetration of RIIR is a direct measure of
the wisdom of doing it.

I.e., if it were a good idea, there would be no need for an advocacy. People
would just do it. If the ecosystem is ever mature enough, we will know by the
counting the number of projects that switch.

But every day, there is the choice: should I improve the product for users, or
potter with the build system? Because language choice is really a build system
detail, to users.

------
tlackemann
I really enjoy articles like these. There is something special and provocative
about a highly sarcastic article about programming, like a comedian that can
make light of a serious topic. Maybe it doesn't solve anything but it does
bring to light another view you might have not seen.

Unrelated but reading this reminded me of the classic article [Programming
Sucks]([https://www.stilldrinking.org/programming-
sucks](https://www.stilldrinking.org/programming-sucks))

------
mrkeen
I have some toy search technology (indexer and query processor). I started in
C and did a series of rewrites, learning and changing something significant
each time.

On version 6 I switched to Rust (having only just started learning the
language) and it feels pretty unlikely I'd switch back.

The rookie mistake isn't to want a rewrite. It's to ridicule something you
haven't tried in earnest.

~~~
nerdponx
Nobody is ridiculing Rust. They are ridiculing flippant requests by non-
contributors to rewrite non-trivial software in another language.

------
skocznymroczny
As a D user, I am looking at Rust with curiosity, but haven't yet seen any
reasons that would make me switch.

~~~
Raveen87
I think Rust is such a well designed language. But as someone coming from more
high-level languages I sometimes feel a bit lost due to not getting as much
help from the IDE as I'm used to for C# in Visual Studio and Java in IntelliJ.
For Rust I've only tried IntelliJ with the Rust plugin, which seems like the
best choice for what I'm after.

~~~
Leace
Rust may hopefully get better autocompletions if they work on their Language
Server implementation. C# compiler was explicitly rewritten so that it is IDE
friendly and I fully agree with this decision. That said even good, old Java
has excellent tooling support that I do miss from all these hip languages
(such as Rust).

~~~
steveklabnik
The compiler team is planning on following in C#’s footsteps with the rust-
analyzer project.

~~~
carlmr
I can only recommend trying it out. It works comparatively well. The problem
with RLS is that it always needs working code to compile in between and it
always loses state. I think it's a design issue at the core of RLS. rust-
analyzer does this a lot better and faster, but is still in an early stage.

------
cp9
a reminder that "rewrite it in rust" is not usually a ground up rewrite, it's
an effort to translate the c into a safer language as you go, it doesn't just
burn it down, salt the earth and start over. Have a look at remacs [1] to see
how this works in practice.

1: [https://github.com/remacs/remacs](https://github.com/remacs/remacs)

~~~
geodel
And it will all be well taken if RIIR folks show things they have done
themselves instead of telling others what they need to do.

~~~
jsymolon
Exactly, stop evangelizing and start doing.

------
Covzire
I've dabbled with Rust a few times for hobby projects, but what always turns
me off is how frustrating it is to work with strings.

~~~
thsowers
If you haven't already, check out the Rust By Example section on this:

[https://doc.rust-lang.org/rust-by-example/std/str.html](https://doc.rust-
lang.org/rust-by-example/std/str.html)

~~~
Covzire
The frustrating part was concatenation, it was surprisingly annoying to
combine a few strings and an int into a single string.

~~~
steveklabnik
The fastest and easiest way is to use format!.

    
    
      let cat = format!("{}{}{}", s1, s2, n);

~~~
Covzire
That doesn't seem too bad (Though it's still no C# with the + operator), I'll
check that out next time I'm in the Rust neighborhood. Thanks.

~~~
steveklabnik
No problem!

I personally only tend to use + when there's two or maybe three things at
most, in any language, and then switch to an API like this if it exists for
more complex things, no matter the language. I find it much easier to read.
YMMV.

(And you can use + in Rust, but you'd have to call .to_string() on the integer
first)

------
dejaime
When thinking of rewriting anything, the first thing we should ask is "why
rewrite?", definitely not "why 'not' rewrite?", despite using the same
language it is already implemented or using another one.

------
thom
This is somewhat reminiscent of people who complain endlessly when a piece of
software is still 32-bit, for purely nebulous reasons. People want things to
feel clean and new, or they get an icky feeling that never seems to go away.

------
maggit
(2016)

~~~
gridlockd
...yet timeless.

------
linuxlizard
I was tinkering with crosscompiling Rust to arm/aarch64 just yesterday. Rust
has a ways to go before it can catch up to C/C++ for cross compiling.

Edit: I should explain a bit. C has had the concept of cross compiling baked
into it for decades. It's a well established, easy path. By dint of C, C++
comes along for the ride. Lots of linker is magic required for bare metal C
programming. Weird flags required for arch-linux-gnueabi cross compiling. Rust
is very new and just doesn't have that history yet. It's an opportunity for
someone who has a lot more spare time than myself. :-)

~~~
woodrowbarlow
> It's a well established, easy path.

i do kernelspace development in C for embedded devices.

i would take exception at "easy". i assume you're saying that because you're
able to use linaro's arm toolchains out of the box, straight from your
distro's repositories. and you're right, that is mostly easy.

but as soon as you need more than simply compiling an executable to run on top
of an incumbent kernel, since gcc toolchains are tied to kernel version,
things get _hard_. unnecessarily hard. recompiling the compiler shouldn't be
necessary. llvm-based compilers like clang address this in a more sane way,
but aren't as mature as gcc.

and build systems for C don't support cross-compiling very well either.
project based on cmake and autotools will usually work with a little tweaking,
but if a project just uses makefiles you'll end up re-writing the build system
90% of the time.

rust's cross-compiling isn't quite there yet, i agree, but the language's (and
the compiler's) design choices set the stage for a _much_ better cross-
compiling process than you get from gcc.

------
drev
We should send emails to linus and ask him to rewrite linux in rust

~~~
steveklabnik
I made a comment about this a year ago that still applies:
[https://news.ycombinator.com/item?id=16547890](https://news.ycombinator.com/item?id=16547890)

~~~
woodrowbarlow
... that was a much more calm and complimentary response than i've grown to
expect from linus.

------
forty
Everyone seems to act like the only option is to rewrite everything or
nothing. Isn't possible to have rust and C talk to each other, and
progressively rewrite the most relevant parts of the code in rust?

~~~
erik_seaberg
You could make a case for sharing a wasm-style byte array with a C subprocess,
but Rust objects won't be safe if C can address them.

------
microcolonel
Now now, let's be nice. We were all obnoxious at one point or another in our
lives.

------
AzzieElbab
TLDR - there is too much code to rewrite despite the daily horrors of life-
threatening and altering software bugs. Not that I think Rust will solve
everything

