7 ms·

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

by seren 7y ago

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 7y ago
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.
- steveklabnik 7y ago
  Incidentally, Tor has some Rust in it these days. I haven't heard from them for a while, so I don't know how the project is going...
  - _bxg1 7y ago
    Tor is probably one of the better cases because of its stringent security requirements, but there remains an oft-ignored tradeoff of losing all that refinement work (and the fact that you can't just flip a switch to make it happen). It's a cost/benefit decision.
    - steveklabnik 7y ago
      Totally; that's why it's not a wholesale re-write, it's slowly replacing old code bit by bit, or writing new code. Which is the only real way to migrate any codebase of significant size to a new language.
      - deleted 7y ago
        [deleted]
- lmm 7y ago
  > 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.
  - carlmr 7y ago
    My experience as well. The key point here is the incremental part. This works especially well if you're adding regression tests incrementally as well. This necessitates a certain modularity & testability in the legacy project though, which often isn't the case. There's a certain threshold in technical debt (depending on the size of the project), at which point a complete rewrite may be better. 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.
  - mamcx 7y ago
    I agree. I made rewrites all the time (and from lang to lang, to architecture to another). Rewrites are a net plus for me. 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...
bluGill 7y ago
If you are not an important member of the dev team you shouldn't propose it at all. Even if you have a magical process that could transform a known maintainable mess into maintainable rust you don't get to talk about it to the dev team.

by seren 7y ago

_bxg1 7y ago

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.

steveklabnik 7y ago
Incidentally, Tor has some Rust in it these days. I haven't heard from them for a while, so I don't know how the project is going...
- _bxg1 7y ago
  Tor is probably one of the better cases because of its stringent security requirements, but there remains an oft-ignored tradeoff of losing all that refinement work (and the fact that you can't just flip a switch to make it happen). It's a cost/benefit decision.
  - steveklabnik 7y ago
    Totally; that's why it's not a wholesale re-write, it's slowly replacing old code bit by bit, or writing new code. Which is the only real way to migrate any codebase of significant size to a new language.
    - deleted 7y ago
      [deleted]
lmm 7y ago
> 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.
- carlmr 7y ago
  My experience as well. The key point here is the incremental part. This works especially well if you're adding regression tests incrementally as well. This necessitates a certain modularity & testability in the legacy project though, which often isn't the case. There's a certain threshold in technical debt (depending on the size of the project), at which point a complete rewrite may be better. 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.
- mamcx 7y ago
  I agree. I made rewrites all the time (and from lang to lang, to architecture to another). Rewrites are a net plus for me. 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...

bluGill 7y ago

If you are not an important member of the dev team you shouldn't propose it at all. Even if you have a magical process that could transform a known maintainable mess into maintainable rust you don't get to talk about it to the dev team.