6 ms·

Rewriting stable software in Rust is a very bad idea. Especially in open source, where we don't have enough maintainers, it ends up hurting the ecosystem. A cer

• bluejekyll 7y ago
  > Please don't be like these people! As the maintainers of the software shouldn't they have the prerogative to maintain the software in the best way they see fit? Bugs happen while refactoring, regardless of how the refactoring is done.
  • matthewbauer 7y ago
    They do, but that doesn't mean the decision is wise. The point is you are creating more bugs than you could ever possible fix in this kind of refactor.
    • arcticbull 7y ago
      I also err on the side of never re-writing things, and pros and cons must always be weighed on a case by case basis. It's not possible to say in general that re-writing software in a language not prone to many important classes of bugs would "create more bugs than you could ever possibly fix." We won't know the decision is wise or unwise until it's attempted and studied maybe even a few times over.
    • pcwalton 7y ago
      And those bugs get fixed, and the software ends up better. I've contributed to two successful "rewrite it in Rust" projects now: Stylo and WebRender. Both of them ended up fixing long-standing bugs in the previous implementation that were difficult to address in the old codebase, but a new clean approach offered a nice opportunity to fix them.
    • xedrac 7y ago
      If you're rewriting into a language like C++, this may very well be true. However rewriting in Rust in my experience yields far fewer bugs, and the ones that do surface are usually simple to fix. If a project truly is "stable" - there's very little effort involved in maintaining it, then yeah, it doesn't make sense to rewrite it. But if it's plagued by bugs and is painful to maintain, you'd be much better off rewriting it in Rust, assuming you're familiar with the existing project's limitations.
• wyldfire 7y ago
  Your argument is not compelling: you've described the drawback without considering the benefits. What if that prominent maintainer hadn't made the mistake (a mistake attributable to poorly captured design or requirements, but not the implementation). Is there something intrinsic to Rust that would lead them to this error? (no, I think not). > Please don't be like these people! Keep the stable software we have, and maybe write new software in Rust. I say: spend your time how you see fit. I love Open Source software, I love GNU/linux and GNOME. But IMO it's always been about scratching an itch first and commitment to a cause second.
  • matthewbauer 7y ago
    It's certainly up to them if they want to rewrite everything in Rust. I'm just saying the net benefit just does not exist for stable software like librsvg or bzip2. > Is there something intrinsic to Rust that would lead them to this error? (no, I think not). There is nothing intrinsic to Rust that creates this kind of problem, besides it being a different language than the project was originally written in. I'm sure Go, Swift, Haskell, Java, or any other language (with the possible exception of C++) would have similar issues. No other language community is quite as arrogant as the Rust community though.
    • pjmlp 7y ago
      To be faire, that is not everywhere. The design team always has nice conversations with me, in spite of my schizophrenic view of C++ vs Rust (like both languages, see some negative issues in both), and there are places with joint community events between C++ and Rust.
    • bsder 7y ago
      > I'm just saying the net benefit just does not exist for stable software like librsvg or bzip2. Are you sure? Both of those libraries are, in fact, poster children to be rewritten in Rust as they have to eat untrusted input. If I offered $20 on "I can find a use-after-free or undefined behavior bug somewhere in those libraries" I'm pretty sure nobody would take that bet.
• pcwalton 7y ago
  Rewriting stable, network-facing, C or C++ software in Rust is a very good idea, because that way that software will require less ongoing maintenance to avoid security problems in the future.
  • Const-me 7y ago
    We don’t know yet how much Rust software will cost in ongoing maintenance to avoid security problems. Unsafe keyword disables many safety features. It already caused security issues: https://medium.com/@shnatsel/how-rusts-standard-library-was-vulnerable-for-years-and-nobody-noticed-aebf0503c3d6 https://medium.com/@shnatsel/how-rusts-standard-library-was-... That particular one was fixed long ago, but unsafe is used a lot in libraries, both in standard and third-party crates. The reasons include native interop e.g. OS kernel calls, language limitations e.g. in collections and other data structures, also sometimes they’re performance optimizations.
    • pcwalton 7y ago
      Yes, we do. Empirically, there have been far fewer memory safety problems in the Rust components of, for example, Firefox than there have been in the C++ components. That particular memory safety issue was not a security issue, because it did not cause any problems in actual software. Rust is very conservative about issuing CVEs for any issue which could conceivably be a security problem. (The equivalent would be if C++ the language issued a CVE because the language lets you clear an array while you're iterating over it. The CVEs for exploitable problems that this kind of thing enables are for the vulnerable software, letting C++ off the hook.) In my opinion, Rust is too conservative and shouldn't even call those things security issues until they affect real products, because it leads to misunderstandings like this.
      • Const-me 7y ago
        It’s safer than C++, sure, but half of other languages are safer. Java doesn’t have unsafe code at all, not even in standard library, and it’s very hard to interop with. Same with JS & TS. When people move from C++ to another language for more safety, Rust is not their only option. Couple decades ago everything was written in C or C++. Desktop apps, mobile apps, web servers (cgi-bin, then COM objects for asp.classic). People wanted higher level, easier to use, faster to compile, and safer languages. Java was the first popular one, then C#, then the rest of them followed. C++ is continuing to lose the market it once had. 15 years ago, people generally stopped using C++ for web servers. Some still do for unusual requirements, but most people don’t. 10 years ago, most people stopped programmed mobile apps in C++ (I did before that time, for WinCE and PalmOS), now it’s mostly managed languages there. Recently the same happened for desktop apps, no one likes Electron but it does the job, and people do use the software. Embedded and videogames have already started the transition, IMO. Moving from C++ to better languages is a long trend, the industry is doing it for decades now. I don’t think Rust is a universally good option for that. Has issues with usability, labor market, libraries, platform support, and community. Good one for niche stuff, like some components of a web browser, or a bare metal hypervisor, but that’s it.
• bsder 7y ago
  Far from seeing this as a downside, I see it as an upside. Gtk support on OS X has been absymal, forever. If this helps that, I'm all for it, thanks.
• 0815test 7y ago
  Rewriting stable software is a bad idea, but not because we have too few maintainers. Indeed, the way of dealing with the "too few maintainers" problem is to bite the bullet and start aggressively paying down technical debt so that the ecosystem can (1) become more sustainable going forward, given the same amount of maintainers, and (2) attract more people to the job of being a maintainer, by easing some of the hardest parts of that job. Rewriting stuff in Rust is one way - though a highly risky, perhaps even extreme way - of paying down technical debt.
  • blub 7y ago
    Rewriting is not like paying down technical debt, it's declaring bankruptcy and trying to start anew from the ashes. Or depending how it's done, like abandoning the debt and starting a new life on a tropical island under an alias.