Posted by giuliomagnifico 12/12/2025
[snaps fingers]
N. Young
I suppose soon we'll get nsa-leftpad from cargo as a dependency among 347 other packages.
I see people complaining about Rust's lack of portability, and it is always some obsolete platform that has been dead for 20 years. Let's be serious, nobody is gonna run Tor on an old SGI workstation or Itanium server.
dont temp me with a good time and awesome weekend project!
https://github.com/llvm/llvm-project/tree/main/llvm/lib/Targ...
Also, the more heterogeneous it's a CPU architecture support, the least exploitable a service will be.
i686 should have died a long, long time ago.
In all seriousness, I guess you can make this argument if you only care about Windows/macOS, but the moment you run anything else I have to ask why, say, Linux deserves support but not other less-common platforms.
1) Development resources are finite.
2) Linux runs all of the world supercomputers, most of the internet infrastructure (server, routers, etc), most of the cellphones (Android), and lots of other things. Its global marketshare is way bigger than macOS and all the BSD put together.
With that said, remainder of this comment continues with the position that GNU/Linux, which I am writing this comment on, is obviously not worth supporting for the same reasons as i.e. MIPS and RISC-V.
> 1) Development resources are finite.
That is an argument in favor of cutting niche platforms like GNU/Linux.
> 2) Linux runs all of the world supercomputers,
You can't defend a niche OS by pointing out that it's used in a tiny niche market. How many supercomputers exist on earth? I'd bet you there are more working MIPS installations than supercomputers.
> most of the internet infrastructure (server, routers, etc),
I'll grant you headless machines used by IT folks, but that's still a specific subset of the market and it has little bearing on whether, say, Tor should support it as a desktop OS.
> most of the cellphones (Android),
Android/Linux is quite different from GNU/Linux; effectively nobody developing for Android is targeting Linux in any meaningful sense.
> and lots of other things. Its global marketshare is way bigger than macOS and all the BSD put together.
Only if we include embedded systems and servers. If you intend to target servers, then yes obviously Linux matters. Otherwise, not so much.
I'd imagine the biggest cultural reason is that many Rust developers were C developers who had a reason to find something better, but still scoff at garbage collection, large runtimes, etc. They probably have a lot more Rust expertise in their circle.
Another technical reason is that they were trying to replace their C code with Rust in bits and pieces before they went with a full rewrite. I don't know about Go, but this is something ergonomically doable in Rust.
I like loose type systems for some quick scripting, but I started to adopt Rust for many of my personal projects because I find it's so much easier to get back into a project after a year when there are good type system guard rails.
I've never had to do anything unusual with building, but I thought the "almost-ststically-compiled" thing was somewhere Go and Rust were almost identical.
Your parent is saying that, while what you say is true for Rust and Go code themselves, in practice, it is less true for Rust, because Rust code tends to call into C code more than Go code does, and Rust doesn't always statically link to that C code by default.
Also Rust has a lot more inherent safety features than go.
(I think Go is great and its my primary language)
That said, since they use Firefox this bridge has already been burned.
[0] https://rust-lang.github.io/rustup/overrides.html#the-toolch...
Advantage of Rust (or original C implementation) is for users that do not have runtime and want to import Tor libraries (like arti-client) in their code. Go could work but those unmanaged languages are better here. So in the end Rust (or C, C++ etc.) can serve more user-cases.
- better data race handling;
- no garbage collection, more predictable performance;
- stricter type system that can enforce constraints better;
- closer to metal and better FFI support.
Which seems to matter more for Tor project than support for some barely used platform.
and better funded.
and easier to find devs.
Also, just because it's part of Google doesn't make go better funded. Theyd probably be fine killing go.
Definitely easier to learn though :P
I'm willing to be Rust suck a ton more to hire devs. Since, as we both agree, Go is easy to learn. Any C#, PHP or Java dev can get going with Go in not time.
But it's never going to surpass Go which is owned by a 4 trillion dollar conglomerate.
There are others like Go.
I think they made the choice based on ecosystem, performance and prior experience with C.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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: 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.
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.
I don't _hate_ them or anything. They are super solid tools and I have derived a lot of value out of them in a previous life. But they leave a lot of room for overly clever humans to abuse them and make life hard for the next guy. Which is exactly how I was exposed to them, dozens of times.
The downfall of all flexible tools or PLs is that people start using them in those obscure and terrible ways. Not the fault of the tools or the PLs.
If you can control 100% of the surface where you are exposed to make/CMake then that puts you in a fairly rare position and you are right to make full use of it! Go for it. Deep work and deep skills are sorely needed in our area. I am rooting for you. :)
> The issue is that I think it (Rust) is going to worm it way everywhere and I will be forced to deal with it.
Help me understand the actual technical criticism buried in the "worm its way everywhere", please. And in the "it's good for CV/Resume padding" statement as well.
It's a strange thing to say and it smells like a personal vendetta which is weirdly common on HN about Rust and to this day I have no idea why even though I have asked many people directly.
Rust has objective technical merits and many smart devs have documented those in their blogs -- journeys on rewrites or green-field projects, databases, network tools (like OP), and even others. Big companies do studies and prove less memory safety bugs over the course of months or years of tests. The Linux kernel devs (not unanimously) have agreed that Rust should no longer have experimental status there recently -- and people are starting to write Linux drivers in Rust and they work.
I am honestly not sure what would satisfy the people who seem to hate Rust so passionately. I guess it announcing full disband and a public apology that it ever existed? Yes this is a bit of a sarcastic question but really, I can't seem to find a place on the internet where people peacefully discuss this particular topic. (I have seen civil exchanges here on HN of course, and I love them. But most of the civil detractors ultimately simply admit they don't have a use for Rust. Again, that is very fair and valid but it is not an actual criticism towards any tech.)
I don't understand why many people on here say "humans", instead of people. It sounds like you are talking as if you are a grey alien on a space ship somewhere.
What you are complaining about is abuse of tools/language features. This can happen in any language and/or tools.
That doesn't mean the tool itself is bad.
> Help me understand the actual technical criticism buried in the "worm its way everywhere", please. And in the "it's good for CV/Resume padding" statement as well.
They are self explanatory. I don't like it when someone does this stupid game of not understanding common idioms.
> It's a strange thing to say and it smells like a personal vendetta which is weirdly common on HN about Rust and to this day I have no idea why even though I have asked many people directly.
It isn't. What typically happens is that a tool lets call it "Y" get used everywhere to the point where you cannot use "X" without "Y".
Ruby used to get used for CV padding. I used to work in a Windows/.NET shop and someone wrote a whole service using Ruby on Rails in a Suse Linux. That person left and got a job doing Rails shortly after.
> Rust has objective technical merits and many smart devs have documented those in their blogs -- journeys on rewrites or green-field projects, databases, network tools (like OP), and even others. Big companies do studies and prove less memory safety bugs over the course of months or years of tests.
Just because <large company> does something and says something is true doesn't mean it is or is suitable for everyone or it is actually true.
I have worked at many <large corps> as a contractor and found that the reality presented to the outside world is very different to what is actually happening in the building.
e.g.
I was working at a large org that rewrote significant portions of their code-base in new language instead of simply migrating their existing code-base to a new runtime.
I made plenty of money as a contractor, but it was a waste resources and the org lost money for 3 years as a result.
BTW they never fully transitioned over to the new code-base.
Company blogs and press releases will say it was a success. I know for a fact it wasn't.
> The Linux kernel devs (not unanimously) have agreed that Rust should no longer have experimental status there recently -- and people are starting to write Linux drivers in Rust and they work.
So I will need any additional toolchain to build Linux drivers. This is what is meant by "worming its way in". I have done a LFS build and it takes a long time to get everything built as it is.
> I am honestly not sure what would satisfy the people who seem to hate Rust so passionately. I guess it announcing full disband and a public apology that it ever existed? Yes this is a bit of a sarcastic question but really, I can't seem to find a place on the internet where people peacefully discuss this particular topic.
You are making assumptions that I hate Rust. I don't. I just don't care for it.
What I do hate is hype and this constant cycle of the IT industry deciding that everything has to be rewritten again in <new thing> because it is trendy. I have personally been through it many times now, both as an end user and as a developer making the transition to the <new thing>.
I am not pretending to not understanding anything as well by the way, I was trying to find objective technical disagreements and still can't find any in your reply. I am seeing a bit of curmudgeon-ing on several places though, so I am bowing out.
I didn't misrepresent anything you said. You misunderstood what I said. I said companies will claim all sorts of things and the reality behind the scenes is very different. Having a study is one form of making claims. What works at one company may not work at another.
> I am not pretending to not understanding anything as well by the way,
Yes you were. What I said was plainly obvious.
CV driven development is a well known and understood phenomenon.
Technology stacks being subverted is a well known and understood phenomenon.
It is very annoying when people pretend not to understand basic idioms. It is a dishonest tactic employed by people online, I've been online now since the late 90s and have seen it done many times. You are not the first and won't be the last.
> I was trying to find objective technical disagreements and still can't find any in your reply.
I gave you them. Several in fact.
Part of engineering is understanding that resources aren't infinite and you have to make trade offs. So how resources (money, time, man power, compute) is used is technical. I make calls all the time on whether something is worth doing based on the amount of time I have.
This is often discussed on many blogs, podcast and books about software engineering.
What you want to do is narrow discussion down to the sort of discussion "well they found they found X more bugs using Y technique". Ignoring the fact that they may had to spend a huge amount of man power to rebuild everything and created many more bugs in the process.
> I am seeing a bit of curmudgeon-ing on several places though, so I am bowing out.
Yes I am disillusioned with the industry after working in it for 20 years. That doesn't invalidate what I say.
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.
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.
It's simply a way to be able to move at a reasonable speed is how I see it.
A complete rewrite made sense.
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.
Machines will generate all the code, test that it works according to spec, you only need a vague notion of what is succint (do you just implement some existing trait?), what is typical (do you use index based data structures? do you simply use a Box, do you need Rc? Where should you use Optional?, do you want to use RefCell to make it mutable and so on), what is concise (just macro expand?), what is the correct type to use so you can warn the machine to re-adjust itself.
Personally I don't use Rust, I don't want to learn everything about Rust. It is the new enterprise Java boilerplate BS of our time.
So instead of running people through that ordeal, let them write the specs and machines should write the verbose boilerplate so the code is so called "safe" and concise without giving up too much.