4 ms·

But the advantage of avoiding C specific bugs is shallow, because the Rust code contains lots of unsafe blocks. Bugfixes made to the original source are not aut

But the advantage of avoiding C specific bugs is shallow, because the Rust code contains lots of unsafe blocks. Bugfixes made to the original source are not automatically ported to the Rust code base. From my point of view the chosen porting "strategy" doesn't make much sense. It is more of a toy project to see what's possible. What would really make sense would be starting with an extensive test suite and trying to build a properly architected Rust implementation according to it.

selfhoster11 6y ago
The unsafe blocks can be removed one by one as time goes on. It's no different to any other legacy refactoring project: get the old code on a new platform, instrument/add unit tests, refactor piece by piece until the end result is acceptable.
- DougBTX 6y ago
  > It's no different to any other legacy refactoring project There are two approaches to a project like that, as you say, take something which works and iteratively make it better, or derive a specification from the project which works and create a new from-scratch implementation to meet that specification. My experience with the "from-scratch" approach is that it is very easy to miss details in the specification that will only be found out later, so it is very easy to underestimate the amount of work required. Ironically, that contributes towards making it easier to kick off the project, as it looks like it will be easier and cheaper. Especially if there is a view to drop features in the new version, which is fine until the actual users find out about the plan. Another issue is that the old system which is being improved is often actually still in use, and the users still want new features even while the new system is being developed. Either those requests can be rejected, or implemented twice (once in the new system, once in the old). When incrementally improving the current system instead, those new features may end up touching areas of the code that have already been improved, making them cheaper to implement, not more expensive. Basically, I think you're right. Keep the current system working, and improve it without breaking it.
  - selfhoster11 6y ago
    The more I read about legacy (and actively maintained) project refactoring, the more firmly I find myself agreeing that the gradual replacement is the right way to go about things in nearly every case. Whether we like it or not, the old system is a source of truth about how things are done, so the only way to preserve this knowledge fully is to copy the whole thing as-is and then "restate" parts of that knowledge in a more organised/modern way by refactoring, leaving the rest in place.
    - steveklabnik 6y ago
      If you’re interested in this topic, you should read “How to work effectively with legacy code” by Michael Feathers.
      - selfhoster11 6y ago
        It's been on my reading list for a while, I'll take this as a reminder to read it :)
      - grey-area 6y ago
        That looks really interesting, thanks for recommending it here.
grey-area 6y ago
Your suggestion would be the start of a clean-room or fresh rewrite - so option 3 above, but those are often surprisingly long and unrewarding endeavours, particularly in old software like this with lots of users used to its quirks and bugs and who disagree about what the spec should be. Automated translation is obviously not an end goal in itself and doesn't improve code quality, but it could be the start of a successful rewrite as it does at least let them replicate exactly what the old program does, which is very important for end users. A good example of this strategy being used successfully is the use of the tool c2go to convert the Go runtime and compiler from C to go. That involved quite a specific tool tailored to the codebase in question, and a lot of manual cleanup afterwards. https://docs.google.com/document/d/1P3BLR31VA8cvLJLfMibSuTdwTuF7WWLux71CYD0eeD8/edit https://docs.google.com/document/d/1P3BLR31VA8cvLJLfMibSuTdw...
renewiltord 6y ago
Everyone has a different way of handling this but if I had to, I would also take the approach described in this project: a variant of the strangle pattern of refactoring. However, I don't know of a single one of these c to rust translation projects that has succeeded. I don't know of any large c to rust rewrite project that has succeeded so that doesn't help judge between rewrite patterns. It may just be that rewrites don't yield results at all.

selfhoster11 6y ago

The unsafe blocks can be removed one by one as time goes on. It's no different to any other legacy refactoring project: get the old code on a new platform, instrument/add unit tests, refactor piece by piece until the end result is acceptable.

DougBTX 6y ago
> It's no different to any other legacy refactoring project There are two approaches to a project like that, as you say, take something which works and iteratively make it better, or derive a specification from the project which works and create a new from-scratch implementation to meet that specification. My experience with the "from-scratch" approach is that it is very easy to miss details in the specification that will only be found out later, so it is very easy to underestimate the amount of work required. Ironically, that contributes towards making it easier to kick off the project, as it looks like it will be easier and cheaper. Especially if there is a view to drop features in the new version, which is fine until the actual users find out about the plan. Another issue is that the old system which is being improved is often actually still in use, and the users still want new features even while the new system is being developed. Either those requests can be rejected, or implemented twice (once in the new system, once in the old). When incrementally improving the current system instead, those new features may end up touching areas of the code that have already been improved, making them cheaper to implement, not more expensive. Basically, I think you're right. Keep the current system working, and improve it without breaking it.
- selfhoster11 6y ago
  The more I read about legacy (and actively maintained) project refactoring, the more firmly I find myself agreeing that the gradual replacement is the right way to go about things in nearly every case. Whether we like it or not, the old system is a source of truth about how things are done, so the only way to preserve this knowledge fully is to copy the whole thing as-is and then "restate" parts of that knowledge in a more organised/modern way by refactoring, leaving the rest in place.
  - steveklabnik 6y ago
    If you’re interested in this topic, you should read “How to work effectively with legacy code” by Michael Feathers.
    - selfhoster11 6y ago
      It's been on my reading list for a while, I'll take this as a reminder to read it :)
    - grey-area 6y ago
      That looks really interesting, thanks for recommending it here.

grey-area 6y ago

Your suggestion would be the start of a clean-room or fresh rewrite - so option 3 above, but those are often surprisingly long and unrewarding endeavours, particularly in old software like this with lots of users used to its quirks and bugs and who disagree about what the spec should be. Automated translation is obviously not an end goal in itself and doesn't improve code quality, but it could be the start of a successful rewrite as it does at least let them replicate exactly what the old program does, which is very important for end users. A good example of this strategy being used successfully is the use of the tool c2go to convert the Go runtime and compiler from C to go. That involved quite a specific tool tailored to the codebase in question, and a lot of manual cleanup afterwards. https://docs.google.com/document/d/1P3BLR31VA8cvLJLfMibSuTdwTuF7WWLux71CYD0eeD8/edit https://docs.google.com/document/d/1P3BLR31VA8cvLJLfMibSuTdw...

renewiltord 6y ago

Everyone has a different way of handling this but if I had to, I would also take the approach described in this project: a variant of the strangle pattern of refactoring. However, I don't know of a single one of these c to rust translation projects that has succeeded. I don't know of any large c to rust rewrite project that has succeeded so that doesn't help judge between rewrite patterns. It may just be that rewrites don't yield results at all.