The Tor Project Is Switching to Rust
Key topics
The Tor Project's decision to switch to Rust has sparked a lively debate about the trade-offs between memory safety, performance, and complexity. While some commenters, like epolanski, think it's a sensible move if Rust addresses their pain points, others, like uecker, worry about introducing new logic bugs and supply chain issues. The discussion reveals a nuanced consensus: Rust can offer better performance and efficiency if used correctly, but it's not a silver bullet, and project-specific nuances play a crucial role. As commenters like gldrk and Yoric point out, the real challenge lies in leveraging Rust's strengths, such as monomorphization, to outdo C's performance.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
19m
Peak period
145
0-12h
Avg / period
22.9
Based on 160 loaded comments
Key moments
- 01Story posted
Dec 12, 2025 at 7:35 AM EST
22 days ago
Step 01 - 02First comment
Dec 12, 2025 at 7:55 AM EST
19m after posting
Step 02 - 03Peak activity
145 comments in 0-12h
Hottest window of the conversation
Step 03 - 04Latest activity
Dec 20, 2025 at 3:31 AM EST
14 days ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
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" arguments, then all the nuance of choosing the right tool for the job is lost.
Or, you could look at other projects who have been using Rust for many years, and consider these factors there too. The folks who have have generally concluded the opposite.
EDIT: And now that I've scrolled down, I see you've left this comment many times as random replies. I'm sure those will get flagged, but for spam reasons, not due to some grand conspiracy.
Debian forky has Rust in the kernel on by default.
In addition, you could more easily inadvertently introduce security problems.
Is Rust the right choice for Tor? Sure. Is Tor the right choice for security? If they moved to Rust, they increased security risks to make it easier to manage and find help from younger less-experienced developers, so no.
I believe that depends on the sophistication of algorithms. High-level algorithms (especially if they involve concurrency or parallelism) are much easier to write in Rust (or in C++) than in C, which gives them a pretty good chance to be at least as fast as any reasonably safe C implementation.
For low-level algorithms, of course, it's really hard to beat polished C code.
> Out-of-the-box, I’m guessing people will use too many cargo packages, each that are over-engineered or written by less-experienced developers, so it will be less efficient and less performant.
I don't think that this is going to be a problem. The Tor Project developers I've interacted with sounded quite serious about security. Forbidding non-blessed cargo packages is pretty trivial.
> In addition, you could more easily inadvertently introduce security problems.
What do you mean?
The parent poster's point is seemingly to reject "this is simply the better thing" (ie: "small code is better") and instead to focus on "for what we are doing it is the better thing". Why would "basic" profiler use be better than "niche" or "advanced" profiler use if for that context basic would actually have been inferior (for whatever value of basic we choose to go with)?
It seems to me that the reality we're often confronted with is that "better" is contextual, and I would say that "basic" or "smaller" are contextual too.
This sort of gamification of discourse is poison if you actually care about good faith or reasonable discussions. HN is not a good place for either.
The Rust specialty is memory safety and performance in an relatively unconstrained environment (usually a PC), with multithreading. Unsurprisingly, because that's how it started, that's what a web browser is.
But Tor is also this. Security is extremely important as Tor will be under attack by the most resourceful hackers (state actors, ...), and the typical platform for Tor is a linux multicore PC, not some tiny embedded system or some weird platform, and because it may involve a lot of data and it is latency-sensitive, performance matters.
I don't know enough of these projects but I think it could also take another approach and use Zig in the same way Tigerbeetle uses it. But Zig may lack maturity, and it would be a big change. I think it is relevant because Tigerbeetle is all about determinism: do the same thing twice and the memory image should be exactly the same. I think it has value when it comes to security but also fingerprinting resistance, plus, it could open the way for dedicated Tor machines, maybe running some RTOS for even more determinism.
What makes you say that?
Steve Klabnik has lied about that in the past, as he is wont to do.
I would still stand by that statement generally. Implementation issues on specific platforms are generally not considered to be what's being discussed when talking about things like this. It's similar to how cvs-rs doesn't make this a lie; a bug isn't in scope to what we're talking about 99% of the time.
In context, I'd have no reason to deny that this is something you'd want to watch out for.
This is true, no_std has no Rust runtime so it doesn't provide stack protection. I am aware of efforts to address this for embedded, but they're not available at the moment.
> Steve Klabnik has lied about that in the past, as he is wont to do.
1) I don't know what Steve has to do with anything I asked so it is bizarre to bring up and 2) I find this is to be a ridiculous statement.
The big thing is memory allocation, sometimes, on tiny systems, you can't malloc() at all, you also have to be careful about your stack, which is often no more than a few kB. Rust, like modern C++ tend to abstract away these things, which is perfectly fine on Linux and a good thing when you have a lot of dynamic structures, but one a tiny system, you usually want full control. Rust can do that, I think, like C++, it is just not what it does best. C works well because it does nothing unless you explicitly ask for it, and Zig took that philosophy and ran away with it, making memory allocation even more explicit.
On the other hand, most developers have no need of writing `unsafe` Rust. The same tools used for static and dynamic analysis of C codebases are available to Rust (ASAN and friends) and it is a good idea to use them when writing `unsafe` (plus miri).
The reason I'm replying is that "the impact of Rust on memory safety" is always a conversation that gets outsized amounts of ink that it drains focus away from other things. I would argue that sum types and exhaustive pattern matching are way more important to minimize logic bugs, even if they aren't enough. You can still have a directory traversal bug letting a remote service write outside of the directory your local service meant to allow. You can still have TOCTOU bugs. You can still have DoS attacks if your codebase doesn't handle all cases carefully. Race conditions can still happen. Specific libraries might be able to protect from some of these, and library reuse increases the likelihood of of these being handled sanely (but doesn't ensure it). Rust doesn't protect against every potential logic error. It never claimed to, and arguing against it is arguing against a strawman. What safe-Rust does claim is no memory safety bugs, no data races, and to provide language and tooling features to model your business logic and deal with complexity.
Admittedly I stopped after going through a bunch of useless stuff related to CVE-2017-8823 (which was initially reported as remotely exploitable with no proof at all).
I went through the tor repository (not vidalia though) and read a bunch of conversations about some of the memory related bugs but none of those were exploitable either (exploitable as in remote execution, not a DoS) and most of the (not so many) bugs were actually logical bugs.
I really don't care what they decide to do with their project and honestly anything that can potentially improve the security of such a system is fine by me but I really think they're doing themselves and the language a disservice by communicating the way they do.
Also, as a side note, even with a C codebase there is SO MUCH you could (and should) do to minimize the impact of a vulnerability that the fact that some choose to present just rewriting code in a different language is not even funny.
Every change you make could be violating a some assumption made elsewhere, maybe even 20 years ago, and subtly break code at distance. C's type system doesn't carry much information, and is hostile to static analysis, which makes changes in large codebases difficult, laborious, and risky.
Rust is a linter and static analyzer cranked up to maximum. The whole language has been designed around having necessary information for static analysis easily available and reliable. Rust is built around disallowing or containing coding patterns that create dead-ends for static analysis. C never had this focus, so even trivial checks devolve into whole-program analysis and quickly hit undecidability (e.g. in Rust whenever you have &mut reference, you know for sure that it's valid, non-null, initialized, and that no other code anywhere can mutate it at the same time, and no other thread will even look at it. In C when you have a pointer to an object, eh, good luck!)
1. Programmer skill and talent are not enough to achieve similar security properties with memory-unsafe languages as with memory-safe languages.
2. Therefore, "memory-safe languages are technically superior, period, for applications processing untrusted data where security is an important goal", is not an un-nuanced argument nor a Rust fanboy argument, but self-evident.
That still leaves a lot of room for other languages (Rust is not my favorite language), but it pushes back against the developer equivalent of doctors and pilots resisting the adoption of checklists for decades because "I wouldn't make those kinds of mistakes so stop messing with my work".
Another aspect to consider is that all garbage collected languages are memory safe. A language like Python actually has a far greater degree of memory safety than a language like Rust because it offers no ability to break memory safety (without calling into foreign code), while Rust lets you do it within unsafe blocks using raw pointers. That being said, anybody who would suggest using Python over Rust in a security-focused context is completely out of their mind.
In serious places where security is critical and margin for error is low, formal verification has existed for decades and is the standard. Any operation - specifically in the context where security is critical - which is not formally verifying its software is a mickey mouse operation, because they're fundamentally compromising on security to an unacceptable degree. I think it would be nice to have a formal verification toolchain and language extension for Rust to allow for full logical safety, but last I checked this area was still a work in progress for the language.
This isn't a gotcha. I know anytime Rust is brought up, someone brings up logical safety. Rust obviously has a lot of tricks up its sleeve to automatically detect issues that a language like C++ cannot. Naive Rust is preferable over naive usage of a memory unsafe language. The problem is that in a serious security critical context, "naive" is completely unacceptable. If security is a core goal, there can be no replacement for fully blown logical safety enforcing strict behavioral and structural guarantees in every single facet of the codebase. I know the line, that logical safety is excruciatingly labor intensive and so the tradeoff with using Rust is that it affords some of the safety of formally spec'd and proven code. The problem is that the amount it affords you is completely marginal. The safety gap between C and Rust is much smaller than the safety gap between Rust and formally proven correct SPARK. It's just the reality. I'm loathe to see a future where marketing hype sees a degeneration of tools because it was presented as a serious alternative.
In almost (?) all garbage collected languages you can get data races in a multi threaded context. You will not get those memory errors in Rust.
1. Programmer skill and talent are not enough to achieve similar security properties with memory-unsafe languages as with memory-safe languages.
2. Therefore, "memory-safe languages are technically superior, period, for applications processing untrusted data where security is an important goal"
but the problem entirely boils down to what comes next:
3a. Therefore everything should use rust.
3b. Therefore everything processing untrusted data where security is an important goal should use rust. (Some folks like to stretch what could possibly process untrusted data to turn this into 3a, but there is a difference.)
3c. Therefore most programs really should be written with a garbage-collector, or if they really need to be low-level or high performance they should use an appropriate stack to avoid gc while remaining safe (whether that's Rust, Ada+SPARK, formally-verified assembly, or whatever).
You've probably heard that "It is difficult to get a man to understand something, when his salary depends on his not understanding it" and so of course we shouldn't expect such people to say "Don't write this in C++" when they can instead get paid to teach "How to write this in C++" for 2-3 days and feel like they made the world a better place on top.
It so happens Rust is my favourite language, or at least, my favourite general purpose language, but it's also true that I am currently mostly paid to write C# and I see absolutely no reason why I'd say "No, this should be Rust" for most work I do in C#
> Diagnosing a Double-Free Concurrency Bug in Rust's Unbounded Channels
https://materialize.com/blog/rust-concurrency-bug-unbounded-...
https://gitlab.torproject.org/tpo/core/arti
> (So far, it's a not-very-complete client. But watch this space!)
Is that comment outdated? The blog post gave me a different impression. If Arti is not ready yet, shouldn't that have been made clear in the blog post and in the various posts here? Not directing it at you, amelius.
So unless they provide some Tor specific nuance, it's more or less applicable to wide range of applications.
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.
As someone that gave up learning Rust (the weird return stuff annoyed me) and prefers C++ (I am a novice C++ programmer, but experienced programmer in other languages such as C#, TS, Go), I just do an eyeroll whenever I see that yet another thing is being rewritten in Rust.
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.
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, Windows and MacOS 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".
> 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 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.
What you are complaining about is abuse of tools/language features. This can happen in any language.
> 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". This happened to JavaScript. I used to be able to download a script and put it in say /lib in a project and not need a dependency manager at all. Now many libraries are difficult to install and download standalone because they assume you are using something like npm, pnpm, yarn or similar.
> 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. I have worked at some <large companies> as a contractor and often many of the people in that building do not agree with the studies.
I was working at a large company that rewrote all significant portions of their codebase in another language. There was almost no benefit and it cost millions. I was quite happy to take their money as a contractor, but it was a waste of money. BTW they never fully transitioned over to the new codebase.
> 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 don't like 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 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. 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.
> I was trying to find objective technical disagreements and still can't find any in your reply.
I gave you them. Part of engineering is understanding that resources aren't infinite. So how resources (money, time, man power) is used is partially technical. There have been whole books written about this in the field of software engineering. 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 "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.
> 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.
I guess you and me live different lives because I have spent far more time messing with ancient C/C++/CMake/Automake/Autoconf/just have this particular so file in this particular spot/copy some guys entire machine because this project only builds there etc/learn and entirely different language just to write build files 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.
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 shiny new thing.
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.
It's simply a way to be able to move at a reasonable speed is how I see it.
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.
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.
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.
I suppose soon we'll get nsa-leftpad from cargo as a dependency among 347 other packages.
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.
No one is claiming the new version is faster, only that it is safer.
Of course, technically, this problem is related to the quantity of high quality nodes :)
Also, using this kind of software without understanding how its works even just a little doesn't protect much of your privacy.
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...
3 relays is the goldilocks number for speed vs privacy. Using less is not a tradeoff the usual user of Tor should make.
2 = risk of collusion between relays
3 = goldilocks default
4 = ... actually, you have more attack surface and you are more susceptible to fingerprinting because everybody else is using 3, so you're timings etc help identify you
So the default is 3 and nobody ought change it! Use 3 like everybody else.
The exception is .onion sites. TOR actually deliberately defaults to 6 hops when accessing .oninon sites - 3 to protect you and 3 to project the site.
But I wouldn't recommend it of course.
If you're starting a brand new VPN company with ironclad ideals about privacy - are you going to be able to compete with state-run enterprises that can subsidize their own competing "businesses", on top of whatever coercive authority they possess to intervene in local small businesses?
I am not sure this isn't a joke, or real.
Tor is slow because traffic is routed through multiple layers. The design priority is anonymity, not speed.
5 proxies does it even slower but would make attacks much more difficult.
Client: "Hi, some.web.site.example please, I want to talk HTTP and I assume you know how AES works and I've randomly picked these numbers to agree the AES key"
Server: "Hi, I do know AES and I've picked these other numbers so now we're good."
Included in the very same packet as that response from the server is the (now AES encrypted) first things the TLS server wants to say e.g. to prove who it is, and agree that it knows HTTP as well.
0RT is a (very dangerous, do not use unless you understand exactly what you're doing) extension for some niche applications where we can safely skip even this roundtrip, also included in TLS 1.3
This TLS handshake can only happen after the TCP handshake, right? So 1 rtt for TCP, + 1 rtt for TLS. 2 rtt total. (2.5 rtt for the server to start receiving actual data. 3 rtt for the client to receive the actual response.)
QUIC really wants to do discovery to figure out a better way to move the data and of course Tor doesn't want discovery that's the whole point, so these features are in tension, but that's not hard to resolve in Tor's favour from what I can see.
Reddit over their onion website is very snappy, and compared to accessing reddit over VPN it shows fewer issues with loading images/videos and less likely to be blocked off.
It would be nice if more websites were available as onion addresses (and I2P as well).
edit: also if the Tor browser (desktop and mobile) would ship with ublock origin bundled, that would further improve the experience (Brave browser Tor window compared to the Tor browser is a night and day difference)
Tails ships Tor browser with ublock but the Tor browser team doesn't want to for simple reason: fingerprinting. I use ublock too but I feel like majority still don't and disabling javascript alltogether is still the most secure way.
I don't understand this given reason. If they package in uBlock origin across their desktop and android browser. Then everybody will have uBlock origin so the same fingerprint. If the reasons are different subscriptions lists that users might enable/disable, sure that's fingerprintable, just make a disclaimer about that if users want to modify the default lists.
https://voodootomato.medium.com/managed-attribution-the-key-...
https://www.authentic8.com/blog/non-attribution-misattributi...
For most people seeking anonymity via Tor network (whistleblowers, journalists, activists, etc.), paying a company who can then subsequently be compelled to hand over your information is a bad choice.
And in most other scenarios, Authentic8 is probably still a bad choice. If you require a FedRAMP-authorized service, then sure, look at Authentic8.
It’s not supposed to be a primary browsing outlet nor a replacement for a VPN. It’s for specific use cases that need high protection. The tradeoff between speed and privacy for someone whistleblowing to a journalist, as an example, is completely reasonable.
Having too much bandwidth available to each participant would incentivize too much abuse. In my past experience, a Tor associated IP was already highly correlated with abuse (users trying to evade bans, create alternate accounts to break rules, and then of course the actual attacks on security).
Tor wants people to use the network for primary browsing because it helps masks the people that need the protection.
The more people using the network, the better for everyone's anonymity.
Well it's certainly not worse than c, and it's hard to argue it's as bad, so...
Except in regards to having a proper standard (the standard from Ferrocene has significant issues), and to the size of the language and how easy it is to implement a compiler for.
There are a lot of differences and trade-offs.
That parts of the Rust community has in the past been actively hostile against gccrs, is then mind-boggling. But Steve Klabnik will lie about that, as he has lied many times in the past and is his wont.
https://reddit.com/r/rust/comments/12y85ww/gcc_13_and_the_st...
> I know, please don't be discouraged. It's just an (unfortunately) prominent, loud subsection. It's not just gaslighting, it's basically concern trolling. The negative top OP plays concerned, but has been trolling GCC-RS posts for many months now. Especially on this subreddit, it's a small number of people that know how to play to a reddit audience and get people riled up. I also know that it's spread to sites like HN.
Ahh here you are speaking nonsense again
> For instance, building a large project in a language with only one major compiler, can introduce risk.
Ok let's introduce an alternative to gcc then
> But Steve Klabnik will lie about that
You seem fine to both tarnish the reputation of, erm, c defenders with your own actions and to slander the reputation of Klabnik, who both speaks more coherently and with his own name. Why do this in the name of open source if you have nothing to contribute, knowing that you're setting your own project back?
I have been a fan of the project the entire time.
Do you like pattern matching in Rust? It is one of the features that Rust does decently well at.
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.
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.
Does Rust have better portability than C?
Could you elaborate on that? macOS Sierra (released on 2016) on Intel macs is supported[1][2], which should allow for Macs from late 2009 onward to work. The Intel Mac build is no longer Tier 1 because the project no longer has access to CI machines for them, and 32-bit cross building is hampered by Xcode 14 not shipping the corresponding SDK[3].
1: https://github.com/rust-lang/compiler-team/issues/556
2: https://doc.rust-lang.org/nightly/rustc/platform-support/app...
3: https://github.com/rust-lang/rust/pull/118083
For comparison… I have zero problems bootstrapping a recent gcc with all bells and whistles on my setup. I probably even could bootstrap it still on my even older G4 Mac with 10.6.
But so called "modern" language compilers like Rust of Go… no luck. There's a slight hope for the gcc rust support someday, I guess.
You can make this point without showing contempt for people who are trying their best to support their users. It’s very hard to support Apple platforms if the OS isn’t supported or if XCode drops support for it. There are no workarounds if no one offers CI hardware running that OS/arch.
Nor is there much incentive to try. Only a tiny minority are on the same OS as you, and with good reason. It was released 9 years ago and marked End-of-Life 6 years ago.
It costs time and money to support users like you, and open source volunteer driven projects sometimes don’t have that. Rust and other projects have added support for smaller platforms if passionate volunteers drive it forward. You’re welcome to do that, but it sounds like you’re happy with GCC.
It's the big "open source" projects with company backing (or other larger organisational structures) behind them which supposedly have a lot of "volunteers" (probably some paid folks, and IMHO lots of people that just slave away for free for someone else's gain) that often have trouble keeping 3 or 4 code lines for backwards compatibility.
I wrote hundreds of GitHub issues, send in patches too, etc., and most discrimination you get is from the bigger projects (not saying this is the case for Rust here; I simply haven't managed to get Rust going at all, so I couldn't even report an issue or send in a patch to fix something.) I do not use the term "discrimination" lightly either. Not everyone can afford to buy new hardware when Apple decides to abandon specific machines, often w/o true technical need (see OpenCore which proves this point). So this is essentially a discrimination of a poor minority.
For "infrastructure" projects like Rust and Go where a lot of other projects depend upon I generally would prefer a more conservative approach here, which doesn't seem to happen for some reason or another… "for the sake of 'progress'", I guess.
> Portability has been far easier than C, though sometimes we're forced to deal with differences between operating systems. (For example, when we've had to get into the fine details of filesystem permissions, we've found that most everything we do takes different handling on Windows.)
Remember, we’re not talking about the language. We’re talking about the stdlib and the surrounding ecosystem. The Rust stdlib and third party libraries generally handle windows well, so the Tor developers don’t need to special case windows.
The extra safety in the code base is nice, but this seems like a bigger deal.
N. Young
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.
105 more comments available on Hacker News