The Tor Project is switching to Rust
29 comments
·December 12, 2025epolanski
dingdingdang
Sensible take, thank you. When HN get these "our project: from x to y language" frontpage stories I am always thinking that it would be far more exciting with "our project: 38.2% smaller code base by optimizing our dependency use", "our project: performance optimized by 16.4% by basic profiler use" or similar!
shevy-java
Hmmmm.
My biggest gripe with the Tor project is that it is so slow.
I don't think merely moving to Rust makes Tor faster either. And I am also not entirely convinced that Rust is really better than C.
ericpauley
There’s a fundamental trade-off between performance and privacy for onion routing. Much of the slowness you’re experiencing is likely network latency, and no software optimization will improve that.
dodomodo
I believe that the slowness is a matter of the amount nodes in the tor network, not something that can be fixed solely by code changes.
No one is claiming the new version is faster, only that it is safer.
rpigab
I had that problem too, very slow on network requests, just change the setting "num_relays_proxied" from 3 to 1 to make it blazingly fast.
willvarfar
Then the single relay knows both who you are (your IP) and where you are going. This offers no anonymity against the relay itself.
3 relays is the goldilocks number for speed vs privacy. Using less is not a tradeoff the usual user of Tor should make.
1313ed01
How is 3 so much better than 2, but 4 not so much better than 3?
deafpolygon
You should preface this with some important information about what that does.
There are some trade-offs!
Changing that setting to 1 gives you weaker anonymity guarantees. Using multiple guards spreads your traffic across different IP addresses, making it harder for an adversary who controls a subset of the network to correlate your activity.
Reducing to a single guard concentrates all traffic through one point, increasing the chance that a hostile relay could observe a larger fraction of your streams...
kaoD
If this is sarcastic you should probably add /s or someone might actually follow your "advice".
jjgreen
Complete rewrites are always a bad idea ... [mutters of agreement] ... except in Rust! [cheering]
lynndotpy
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.
norman784
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.
dodomodo
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.
littlestymaar
Opinions with “always” in them are always a bad idea.
N_Lens
Rust - "I am inevitable"
testdelacc1
This isn’t a recent decision, which the title implies. This rewrite started in 2020, and they released Arti 1.0 in 2022. Check out the release post (https://blog.torproject.org/arti_100_released/) where they explain their rationale for the rewrite. They were unhappy with the state of the C codebase and couldn’t see a way to slowly refactor it. Their experience with Rust was positive for all the commonly cited reasons - if it compiles it works, good ecosystem leading to development velocity, better portability across operating systems, and attracting more contributors. They did say they weren’t happy at the time with binary sizes.
The change log in the arti repo (https://gitlab.torproject.org/tpo/core/arti/-/blob/main/CHAN...) shows a lot of recent development too- versions 1.6, 1.7 and 1.8 were released in the last 3 months and they talk about setting the foundations for larger features to come. All in all it seems like the decision worked out for the team.
pityJuke
Yes, this is a complete exaggeration of a headline and should be flagged for that alone.
This has been a long running project, and the Tor team clearly took their time to make it, as opposed to being a spur-of-the-moment change.
anthk
Why not Go? It's more portable.
lynndotpy
Don't Rust and Go build to mostly-statically-compiled binaries? (With the exception of a link to libc.) (This isn't a rhetorical question, this is something I don't know a lot about
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.
hu3
and easier to learn.
and better funded.
and easier to find devs.
ramon156
They both suck getting new devs for
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
preisschild
What do you mean? Rust supports far more platforms.
Also Rust has a lot more inherent safety features than go.
(I think Go is great and its my primary language)
superkuh
In terms of compilation of programs Go is far, far easier than Rust. For Rust to compile a random Rust program on the internet one almost always has to have the absolutely latest out of repo compiler toolchain from curl rustup.whatever | sh. The normal 4 year release cycle is incompatible with rust development. For commercial use cases this doesn't matter. But for open source like the tor project it does.
That said, since they use Firefox this bridge has already been burned.
norman784
AFAIK if the project has a rust-toolchain.toml[0] file, cargo will download the correct compiler for the project.
[0] https://rust-lang.github.io/rustup/overrides.html#the-toolch...
bbcismyfriend
[flagged]
tw1901375
It did look like that ever since an NSA critical Tor developer got canceled using the same methods as against Assange.
I suppose soon we'll get nsa-leftpad from cargo as a dependency among 347 other packages.
nurettin
I think we will see more Rust adoption as code generation gets better.
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.
If Rust helps with their pains and they like Rust this seems very sensible.
That's exactly why we have different languages and tools, because they adapt differently to different projects, teams and problems.
But as soon as you get into the silly "tool X is better period" arguments, then all the nuance of choosing the right tool for the job is lost.