Comment by lynndotpy
3 days 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/ ), the reasons are pretty convincing. The major reasons are, unsurprisingly, all around memory safety.
> 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.
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.
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.
> 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.
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.
To be fair, you haven't explained why it's an issue to see projects being rewritten in Rust, other than it is a bit annoying to you?
For me, I had a very good experience rewriting a project in Rust (from Python). It was just an improvement in every regard (the project was easier to build and distribute, it was a good opportunity to rearchitect it, and the code ended up 20k times faster.) So, I have the opposite feeling when I see titles like these.
I also feel the opposite about the tooling. For me, cmake, npm, pip, maven, etc. all live in this realm where any invocation could become a time purgatory. The big thing that makes me like Rust is that I've never had that experience with cargo. (In fact, pip was the primary motivation to move away from Python to Rust. Everything else was just nice.)
I'm not saying this to convince you to feel otherwise, I just wanted to offer how I felt about the same topics. I grew up with C and Java, but Rust clicked after I read SICP and followed along in Racket. I could probably fill a page of small grievances about Rust's syntax if I had to.
Rewriting stuff is largly a waste of time unless the underlying design/product is flawed. You are going to have to solve the same challenges as before but this time in Rust.
Anyone that been on a "rewrite" knows that often the end result will look like the previous implementation but in <new thing>.
So what I see is a lot of development effort to re-solve problems that have already been solved. I think Ubuntu did this with the core-utils recently (I don't keep up with the Linux dramas as there is a new one every week and tbh it isn't interesting a lot of the time). They ended up causing bunch of issues that I believe were already fixed years ago.
There are issues with things in Linux land that have been issues for years and haven't been resolved and I feel that development effort would have probably been better spent there. I don't pay canonical employees though, so I guess I don't get to decide.
> 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 guess you and me live different lives because I have spent far more time messing with ancient C/C++/CMake/Automake/Autoconf/configure/just have this particular .so file in this particular spot/copy some guys entire machine because this project only builds there/learn and entirely different language just to write build files (CMake sucks and 5 other alternatives are just lipstick on a pig) etc. etc.
I am of the opinion that half of Rusts success is based on that fact that C/C++'s tooling is annoying and ancient. People want to write code not mess with build envs.
The issue you are describing isn't an problem with C/C++ tooling. It is to do with how the developer dealt with dependencies i.e. poorly. BTW this happens in any language if they do that. I've had to deal with some awful C# code bases that would only compile on one guys machine.
I am a hobbyist C/C++ developer and have a intermediate size code base that builds on Linux, Windows (MinGW and MSVC) and MacOS and I didn't do anything particularly special. What I did do is setup CI early on in my project. So I had to fix any issues as I went along.
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.
> 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.
RE: memory, any self-respecting CI/CD system will allow you to compile any Rust project without out-of-memory halts.
RE: NPM, you have a right to a preference of course. I certainly don't miss the times 20 years ago when pulling in a library into a C++ project was a two-week project in itself. make and CMake work perfect right up until they don't and the last 2% cost you 98% of the time. Strategically speaking, using make/CMake is simply unjustified risk. But this is of course always written off as "skill issue!" which I gave up arguing against because the arguers apparently have never hit the dark corners. I have. I am better with Just and Cargo. And Elixir's mix / hex.
What you like as a language (or syntax) and what you roll your eyes at are obviously not technological or merit-based arguments. "Weird" I can't quite place as an argument either.
Use what you like. We all do the same. The original article lists good arguments in favor of Rust. Seems like a good case of "use the right tool for the job" to me.
> RE: NPM, you have a right to a preference of course. I certainly don't miss the times 20 years ago when pulling in a library into a C++ project was a two-week project in itself. make and CMake work perfect right up until they don't and the last 2% cost you 98% of the time. Strategically speaking, using make/CMake is simply unjustified risk. But this is of course always written off as "skill issue!" which I gave up arguing against because the arguers apparently have never hit the dark corners. I have. I am better with Just and Cargo. And Elixir's mix / hex.
I've lost countless hours having to get the rube goldberg machine of npm, jest, typescript, ts-jest and other things to work together. In contrast when I was learning OpenGL/Vulkan and general 3d programming, I decided to bite the bullet and just do C++ from the start as that was what all the books/examples were in. I had been told by countless people how hard it all was and how terrible the build systems were. I don't agree, I think the JS ecosystem is far worse than make and CMake. Now I am already an experienced programmer that already knew C# and Java, maybe that helped as they have many of the same concepts as C++.
Now I did buy and read a book on CMake and I did read the C++ 11 book by Bjarne Stroustrup (I found it second hand on ebay I think).
> What you like as a language (or syntax) and what you roll your eyes at are obviously not technological or merit-based arguments.
They aren't. What I am trying to convey is that it feels like a lot of things are done because it is the new shiny thing and it is good for resume/CV padding.
> "Weird" I can't quite place as an argument either.
The return keyword is optional IIRC in some circumstances. I think that is weird. I think I stopped there because I just wasn't enjoying learning it and there are zero jobs in my area of it.
> Use what you like. We all do the same.
The issue is that I think it (Rust) is going to worm it way everywhere and I will be forced to deal with it.
4 replies →