Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Not Rewrite It in Rust? (2016)

transitiontech.ca

Post reply on HN
Print view View original

61–70 of 79 posts

Re: Why Not Rewrite It in Rust? (2016)

#61

Post by ncmncm »

geodel wrote: post #20
asdkhadsj wrote: post #7

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…

> 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.

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.

Re: Why Not Rewrite It in Rust? (2016)

#62

Post by TheCoelacanth »

vbezhenar wrote: post #59
steveklabnik wrote: post #48

Earlier quoted context omitted.

Procedural macros take a list of tokens, and you give a list of tokens back, and they're then compiled. 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)

Thanks, that's similar, also I would argue that for inexperienced developer just producing desired text would be a simpler solution (but dangerous).

If you use the `quote` crate[1], it's pretty much identical in terms of developer experience.

[1] https://github.com/dtolnay/quote

Re: Why Not Rewrite It in Rust? (2016)

#63

Post by woodrowbarlow »

linuxlizard wrote: post #38

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-li…

> 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.

Re: Why Not Rewrite It in Rust? (2016)

#64

Post by steveklabnik »

forty wrote: post #58

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?

Yes, and was part of the core design of the language; that's how it's worked with Firefox.

Re: Why Not Rewrite It in Rust? (2016)

#65

Post by asdkhadsj »

geodel wrote: post #20
asdkhadsj wrote: post #7

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…

> 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.

Depends, would you not jump in and advocate a project fix fundamental flaws if it affected your production security?

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.

Re: Why Not Rewrite It in Rust? (2016)

#66

Post by woodrowbarlow »

steveklabnik wrote: post #15
drev wrote: post #9

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

I made a comment about this a year ago that still applies: https://news.ycombinator.com/item?id=16547890

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

Re: Why Not Rewrite It in Rust? (2016)

#67

Post by AnimalMuppet »

lmm wrote: post #35
_bxg1 wrote: post #19

Earlier quoted context omitted.

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 reli…

> 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 projec…

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.)

Re: Why Not Rewrite It in Rust? (2016)

#69

Post by erik_seaberg »

jasonhansel wrote: post #31

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.

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.

Re: Why Not Rewrite It in Rust? (2016)

#70

Post by _bxg1 »

AnimalMuppet wrote: post #67
lmm wrote: post #35

Earlier quoted context omitted.

> 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 projec…

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 thin…

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.
Post reply on HN