3 ms·

Complete rewrites are always a bad idea ... [mutters of agreement] ... except in Rust! [cheering]

by jjgreen 11mo ago

dodomodo 11mo ago
Comelete rewrite are not always bad, they are _just_ very costly. You just need to do cost benefit analsys and compare it with the cost and benefit of other actions.
lynndotpy 11mo ago
Complete rewrites have been done before. They're not impossible tasks. C to C++ (like with fish), C++ to Rust (fish again, Tor, etc), Java to C# (something I've seen), C# to C++ (evernote), Blender Game Engine to Godot (many small cases), Godot to Lumberyard (something I've seen), Unity to Godot (many small cases), etc. And there are all the myriad rewrites within the same language, or across major breaking changes (like Python 2 to Python 3). I think "you should never do a full rewrite" is something of a reactionary response to the juvenile idea new devs and interns get every now and then. But sometimes, a rewrite really is a good idea. But in this case, per the announcement ( https://blog.torproject.org/announcing-arti/ https://blog.torproject.org/announcing-arti/ ), the reasons are pretty convincing. The major reasons are, unsurprisingly, all around memory safety.
- FieryMechanic 11mo ago
  The issue is that every other week there is a rewrite of something in Rust. I just do an eyeroll whenever I see that yet another thing is being rewritten in Rust. I've tried compiling large projects in Rust in a VM (8GB) and I've run out of memory whereas I am sure a C/C++ large project of a similar size wouldn't run out of memory. A lot of this tooling I had to compile myself because it wasn't available for my Linux distro (Debian 12 at the time). A lot of the tooling reminds me of NPM, and after spending a huge amount of my time fighting with NPM, I actually prefer the way C/C++/CMake handles stuff. I also don't like the language. I do personal stuff in C++ and I found Rust really irritating when learning the language (the return rules are weird) and just gave up with it.
  - hypeatei 11mo ago
    > whereas I am sure a C/C++ large project of a similar size wouldn't run out of memory This is a common issue on large C++ projects for users with limited resources. You typically have to tinker with build settings and use a different linker etc.. to get the project building without OOMing. > A lot of the tooling reminds me of NPM My feeling is that you'd have the same criticism about a lot of other modern ecosystems because they allow you to pull dependencies easily. With things like vcpkg, that's also possible in C++ but even without it: nothing stops the same behavior of importing "random" code from the internet.
    - FieryMechanic 11mo ago
      A lot of the modern tooling feels like a rube goldberg machine when it goes wrong. If you are forced (like I am) because of byzantine corporate rules to use older version of said tools, it is extremely painful. Don't get me started on stuff like babel, jest, ts-jest and all that gubbings. AI been a godsend because I can ask Claude what I want to do. I use vendor directory in my C++ project and and git submodules and I've got a build that works cross platform. The biggest issue I ran into was MinGW and GCC implement the FileSystem library differently (I don't know why). It wasn't too difficult to fix.
  - g947o 11mo ago
    Sure. That doesn't matter. Of course you can keep writing your C/C++ or using CMake, nobody is going to stop that. But other people's project are not going to stop adopt new tech stack because how you feel about it.
    - FieryMechanic 11mo ago
      > That doesn't matter. Of course you can keep writing your C/C++ or using CMake, nobody is going to stop that. What it is going to cause is having to learn a bunch of new tooling which I have to somehow to get behaving on my Debian box, because a particular tool that I will need to compile from source will have a bunch of Rust dependencies. I've already run into this BTW, where I wanted to compile something in Rust and it needed a third party task runner called "just". So I then needed to work out how to install/compile "just" to follow the build instructions. Why they needed yet another task runner, when I am pretty sure make would have been fine, is beyond me. > But other people's project are not going to stop adopt new tech stack because how you feel about it. I don't expect them to. That doesn't mean I can't comment on the matter.
- mynameajeff 11mo ago
  > Godot to Lumberyard Do you remember what project(s) this was? I'd be super curious on the motivations of the developers. I guess I could see it when it first went open source and Godot wasn't all it was today.
  - lynndotpy 11mo ago
    It was a project I worked on as an intern at Electric Boat. I can only speak to specifics I was explicitly given the okay to share though (i.e. this is all on my LinkedIn). The project was a virtual training simulation for a submarine cockpit, first in Blender Game Engine. With support for BGE being deprecated, I was tasked to find an alternative engine and to port the work. (I'm very proud my research pointed to Godot- this was during the Godot 2 era). There was a lot of interest in the project, but my internship was coming to an end and they decided to port it to Amazon Lumberyard for fear of Godot's longevity and support. They didn't want to be left "waiting for Godot". The final task I took on was to document the project, to make that transition easier for whoever came next.
littlestymaar 11mo ago
Opinions with “always” in them are always a bad idea.
norman784 11mo ago
Well, an underrated aspect of the Rust rewrites, is that it's easy to publish and share official libraries from the projects that the community can use, something that is too hard in C land.
- _zagj 11mo ago
  If anything, from a security standpoint, this is one of the bigger issues with a rewrite in Rust. Besides the "MIT EVERYTHING" mindset, Rust people are also similar to JS devs in having projects with huge supply chain attack surfaces, from their eagerness to rely on so many crates.
  - pdimitar 11mo ago
    I agree this is problematic, sure, and is not unique to Rust or JS. Feel free to propose and work on something better, I'd be your enthusiastic supporter. It's simply a way to be able to move at a reasonable speed is how I see it.
  - tempest_ 11mo ago
    On the flip side C/C++ devs like to let ancient libs hang around because updating them can be such a pain in the ass. You can choose to write Rust with fewer external crates or vendor them like you would with c++ that is a dev choice. Having more choices is better.
billy99k 11mo ago
I worked at a startup where the original code base was outsourced to cheap developers and was riddled with security vulnerabilities. A complete rewrite made sense.
robin_reala 11mo ago
Fish did a complete rewrite in Rust, but they did it in the right way. 1. Rewrite each C file in Rust as a 1:1 mapping. 2. Rewrite the Rust to make it idiomatic. 3. Start making structural changes.
g947o 11mo ago
Nobody ever said rewrites are always a bad idea. You just made that up. It has been done successfully many times, with many more happening (e.g. TypeScript compiler rewrite). What matters is how the project is planned and implemented. Typically, complete rewrites that halt all feature development and fail to achieve feature parity is a recipe for disaster. On the other hand, balancing the work for feature/regular maintenance and rewrite and gradually achieving feature parity before rolling things out has worked well.

Complete rewrites are always a bad idea ... [mutters of agreement] ... except in Rust! [cheering]

by jjgreen 11mo ago

Complete rewrites are always a bad idea ... [mutters of agreement] ... except in Rust! [cheering]

Comelete rewrite are not always bad, they are _just_ very costly. You just need to do cost benefit analsys and compare it with the cost and benefit of other actions.

lynndotpy 11mo ago

Complete rewrites have been done before. They're not impossible tasks. C to C++ (like with fish), C++ to Rust (fish again, Tor, etc), Java to C# (something I've seen), C# to C++ (evernote), Blender Game Engine to Godot (many small cases), Godot to Lumberyard (something I've seen), Unity to Godot (many small cases), etc. And there are all the myriad rewrites within the same language, or across major breaking changes (like Python 2 to Python 3). I think "you should never do a full rewrite" is something of a reactionary response to the juvenile idea new devs and interns get every now and then. But sometimes, a rewrite really is a good idea. But in this case, per the announcement ( https://blog.torproject.org/announcing-arti/ https://blog.torproject.org/announcing-arti/ ), the reasons are pretty convincing. The major reasons are, unsurprisingly, all around memory safety.

FieryMechanic 11mo ago
The issue is that every other week there is a rewrite of something in Rust. I just do an eyeroll whenever I see that yet another thing is being rewritten in Rust. I've tried compiling large projects in Rust in a VM (8GB) and I've run out of memory whereas I am sure a C/C++ large project of a similar size wouldn't run out of memory. A lot of this tooling I had to compile myself because it wasn't available for my Linux distro (Debian 12 at the time). A lot of the tooling reminds me of NPM, and after spending a huge amount of my time fighting with NPM, I actually prefer the way C/C++/CMake handles stuff. I also don't like the language. I do personal stuff in C++ and I found Rust really irritating when learning the language (the return rules are weird) and just gave up with it.
- hypeatei 11mo ago
  > whereas I am sure a C/C++ large project of a similar size wouldn't run out of memory This is a common issue on large C++ projects for users with limited resources. You typically have to tinker with build settings and use a different linker etc.. to get the project building without OOMing. > A lot of the tooling reminds me of NPM My feeling is that you'd have the same criticism about a lot of other modern ecosystems because they allow you to pull dependencies easily. With things like vcpkg, that's also possible in C++ but even without it: nothing stops the same behavior of importing "random" code from the internet.
  - FieryMechanic 11mo ago
    A lot of the modern tooling feels like a rube goldberg machine when it goes wrong. If you are forced (like I am) because of byzantine corporate rules to use older version of said tools, it is extremely painful. Don't get me started on stuff like babel, jest, ts-jest and all that gubbings. AI been a godsend because I can ask Claude what I want to do. I use vendor directory in my C++ project and and git submodules and I've got a build that works cross platform. The biggest issue I ran into was MinGW and GCC implement the FileSystem library differently (I don't know why). It wasn't too difficult to fix.
- g947o 11mo ago
  Sure. That doesn't matter. Of course you can keep writing your C/C++ or using CMake, nobody is going to stop that. But other people's project are not going to stop adopt new tech stack because how you feel about it.
  - FieryMechanic 11mo ago
    > That doesn't matter. Of course you can keep writing your C/C++ or using CMake, nobody is going to stop that. What it is going to cause is having to learn a bunch of new tooling which I have to somehow to get behaving on my Debian box, because a particular tool that I will need to compile from source will have a bunch of Rust dependencies. I've already run into this BTW, where I wanted to compile something in Rust and it needed a third party task runner called "just". So I then needed to work out how to install/compile "just" to follow the build instructions. Why they needed yet another task runner, when I am pretty sure make would have been fine, is beyond me. > But other people's project are not going to stop adopt new tech stack because how you feel about it. I don't expect them to. That doesn't mean I can't comment on the matter.
mynameajeff 11mo ago
> Godot to Lumberyard Do you remember what project(s) this was? I'd be super curious on the motivations of the developers. I guess I could see it when it first went open source and Godot wasn't all it was today.
- lynndotpy 11mo ago
  It was a project I worked on as an intern at Electric Boat. I can only speak to specifics I was explicitly given the okay to share though (i.e. this is all on my LinkedIn). The project was a virtual training simulation for a submarine cockpit, first in Blender Game Engine. With support for BGE being deprecated, I was tasked to find an alternative engine and to port the work. (I'm very proud my research pointed to Godot- this was during the Godot 2 era). There was a lot of interest in the project, but my internship was coming to an end and they decided to port it to Amazon Lumberyard for fear of Godot's longevity and support. They didn't want to be left "waiting for Godot". The final task I took on was to document the project, to make that transition easier for whoever came next.

littlestymaar 11mo ago

Opinions with “always” in them are always a bad idea.

norman784 11mo ago

Well, an underrated aspect of the Rust rewrites, is that it's easy to publish and share official libraries from the projects that the community can use, something that is too hard in C land.

_zagj 11mo ago
If anything, from a security standpoint, this is one of the bigger issues with a rewrite in Rust. Besides the "MIT EVERYTHING" mindset, Rust people are also similar to JS devs in having projects with huge supply chain attack surfaces, from their eagerness to rely on so many crates.
- pdimitar 11mo ago
  I agree this is problematic, sure, and is not unique to Rust or JS. Feel free to propose and work on something better, I'd be your enthusiastic supporter. It's simply a way to be able to move at a reasonable speed is how I see it.
- tempest_ 11mo ago
  On the flip side C/C++ devs like to let ancient libs hang around because updating them can be such a pain in the ass. You can choose to write Rust with fewer external crates or vendor them like you would with c++ that is a dev choice. Having more choices is better.

billy99k 11mo ago

I worked at a startup where the original code base was outsourced to cheap developers and was riddled with security vulnerabilities. A complete rewrite made sense.

robin_reala 11mo ago

Fish did a complete rewrite in Rust, but they did it in the right way. 1. Rewrite each C file in Rust as a 1:1 mapping. 2. Rewrite the Rust to make it idiomatic. 3. Start making structural changes.

g947o 11mo ago

Nobody ever said rewrites are always a bad idea. You just made that up. It has been done successfully many times, with many more happening (e.g. TypeScript compiler rewrite). What matters is how the project is planned and implemented. Typically, complete rewrites that halt all feature development and fail to achieve feature parity is a recipe for disaster. On the other hand, balancing the work for feature/regular maintenance and rewrite and gradually achieving feature parity before rolling things out has worked well.