Why Not Rewrite It in Rust? (2016)(transitiontech.ca) |
Why Not Rewrite It in Rust? (2016)(transitiontech.ca) |
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.
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.
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.
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 ...
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.
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?"
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.
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.
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.
Which don't get me wrong, this is likely not advocatable (is that a word?) to something like Find. I'm not defending that. However C bugs in SSL/Apache/etc are terrifying. A person jumping in and advocating RIISSL is similar (but obviously different) to jumping in and advocating for critical fixes, or perhaps even security audits.
Unrelated but reading this reminded me of the classic article [Programming Sucks](https://www.stilldrinking.org/programming-sucks)
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.
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. :-)
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.
In almost all cases though, the that fact that my codebase is working means the ecosystem, tooling and compilers are good enough as is and so I won't have a compelling reason to rewrite. I can get great programmers productive in Rust faster than the boss can figure out that neither I nor the new guy knew anything about rust on the first day.
Typically the only time the factors you mention come into consideration is a brand new project. I will generally know before I write the first line of code if I need GPGPU support or not. I ecosystem, tools, and existence of compilers are just a few of trade offs I will consider.
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.)
If the knowledge is so opaque as to be nonobvious from the code in front of you, then it's already an accident waiting to happen: someone making normal maintenance changes to that code (not a rewrite) would be equally likely to break those properties.
What is important is that $new_lang or $new_arch MUST help to cut in big ways problems and/or code.
To say something minimal, Rust eliminate (except when interfacing with $old) NULLs. Also, pattern matching make a lot of problems go away, FOREVER.
This mean, that is like have another developer also helping in cut work and at the same time increase quality.
This is not limited to compilers. For example, I work for business apps and use RDBMS a lot. Use a RDBMS well? It cut work and increase quality.
Rewriting queries, schemas and using indexes, views and ANY trick the RDBMS allow you (the idea "not use a DB at full because 'data independence' is poison if not VERY well justified) help by spades.
So:
- Naive rewriting = VERY BAD
- Move from $old to $new WITHOUT the help of a "improved" architecture, feature, tooling or concept = WASTED
- Move from $old to $new with better? TOTAL WIN.
P.D: I think move from too similar Langs probably will waste stuff. You see much more bang from your buck when move from imperative to functional, than from imperative to imperative. Not because functional is superior, but because it force to bring power (use of inmutable and algebraic types, for example) that before was dependent on discipline...
For most of the other projects Working Effectively With Legacy Code by Michael Feathers contains a good approach for slowly modularizing and testing the system, before exchanging parts.
Which is the only real way to migrate any codebase of significant size to a new language.
https://doc.rust-lang.org/stable/book/ch19-06-macros.html#ho... (starts with derive, then moves on to attributes. Function-like ones aren't stable yet)
let cat = format!("{}{}{}", s1, s2, n);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)
Best intro documentation of any language I have tried to learn recently.
EDIT for those who havent seen it: https://doc.rust-lang.org/book/