[HN Gopher] The Tor Project is switching to Rust
___________________________________________________________________
The Tor Project is switching to Rust
Author : giuliomagnifico
Score : 314 points
Date : 2025-12-12 12:35 UTC (10 hours ago)
(HTM) web link (itsfoss.com)
(TXT) w3m dump (itsfoss.com)
| epolanski wrote:
| 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.
| dingdingdang wrote:
| 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!
| staticassertion wrote:
| Isn't this just the same value judgment mistake? You're just
| presupposing that things like "smaller code base" are better
| in virtue of themselves the same way that "rewritten in Rust"
| might be as well.
|
| 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.
| morkalork wrote:
| Is the trade off here having more secure code in exchange for
| added complexity/difficulty? This is a real question, has the
| Tor code itself been exploited by bad actors before? All the
| incedences I've seen in the news were some other software
| running over tor that would be exploited to phone home or
| give up user data.
| uecker wrote:
| It seems they worry about it, which I can understand. But
| now with Rust I worry about about new logic bugs, supply
| chain issues, and lack of proper security updates.
| steveklabnik wrote:
| Well, given that this has been going on for years, you
| can already start to empirically evaluate that question.
| yjdiquhf wrote:
| > (So far, it's a not-very-complete client. But watch
| this space!)
| steveklabnik wrote:
| Yes, it's a beginning not the end.
|
| 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.
| classicasp wrote:
| I think the chance that your Rust application is going to be
| more performant or efficient than C, is whether you are
| focused on writing performant and efficient 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.
|
| 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.
| gldrk wrote:
| Given how heavily most C programs lean on type erasure vs.
| monomorphization and how often they reimplement basic data
| structures, it's kind of a miracle they hold up against
| Rust/C++.
| uecker wrote:
| Why? Monomorphization often leads to great results in
| microbenchmarks due to super-specialized code but also to
| bloat.
| Yoric wrote:
| > I think the chance that your Rust application is going to
| be more performant or efficient than C, is whether you are
| focused on writing performant and efficient code.
|
| 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?
| bluGill wrote:
| Sometimes language is a limiting factor and so you need to
| change languages before getting better. However this is rare.
| YetAnotherNick wrote:
| What are the project specific nuance you are talking about?
| Anything in this and linked post could be applied to any
| performant application which values memory safety.
|
| So unless they provide some Tor specific nuance, it's more or
| less applicable to wide range of applications.
| letmetweakit wrote:
| Why do you even bring this up, the blog post does not contain
| this message, they rewrote it to eliminate a class of bugs.
| They don't bash C, so refrain yourself from mentioning what
| hypothetically could have been written...
| machomaster wrote:
| He wrote it because he has eyes and has seen how the typical
| conversations about switching to Rust often go.
| LexiMax wrote:
| Because Hacker News gamifies engagement, and they know that
| this kind of message tends to attract a lot of upvotes. The
| whole conversation tree is a carpet of land-mines, laid out
| in the hopes that someone steps on one so they can pounce.
|
| 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.
| GuB-42 wrote:
| I hate the "rewrite it in Rust" mentality, however, I think
| that in this particular case, Rust is the right tool for the
| job.
|
| 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.
| hgomersall wrote:
| FWIW, rust is great on a tiny embedded system.
| udhghhe wrote:
| But with no_std, Rust is not memory safe, even when not
| using unsafe. It does have pattern matching and modules,
| however.
| estebank wrote:
| > But with no_std, Rust is not memory safe, even when not
| using unsafe.
|
| What makes you say that?
| GuB-42 wrote:
| From the looks of it, Rust is usable un a tiny embedded
| system but it is not "great". I think that out of the
| recent, trendy languages, Zig is the best suited for this
| task, but in practice C is still king.
|
| 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.
| tialaramex wrote:
| It probably depends _how_ tiny you mean. If the reason
| you can 't allocate memory is because the only 1024 bytes
| of static RAM is all stack, then, yeah, Rust won't be
| very comfortable on that hardware. On the other hand C
| isn't exactly a barrel of laughs either. In my mind if I
| can sensibly chart what each byte of RAM is used for on a
| whiteboard then we should write machine code by hand and
| skip "high level" languages entirely.
| steveklabnik wrote:
| Rust has no malloc in the language whatsoever. In
| embedded, you don't even include the libraries for
| dynamic allocation in the first place, unless you want
| to. And it's very normal not to.
| hgomersall wrote:
| Tools like embassy really are great: https://embassy.dev/
| guywithahat wrote:
| I had that thought too; the author claims tor suffers from user
| free bugs but like, really? A 20 year old code base with a
| massive supportive following suffers from basic memory issues
| that can often be caught with linters or dynamic analysis?
| Surely there are development issues I'm not aware of but I
| wasn't really sold by the article
| zelphirkalt wrote:
| That can easily happen in C programs. Some edge case doesn't
| really happen, unless you specifically craft inputs for that,
| or even sequences of inputs, and simply no one was aware for
| those 20 years, or no one tried to exploit that specific part
| of the code. With C you are never safe, unless you somehow
| proved the code to be free of such bugs.
| uecker wrote:
| This is a bit of an exaggeration. Many types of bugs can
| also happen with Rust, and with you use unsafe or have some
| dependency that uses it, then also memory safety bugs. At
| the same time, it is possible to reduce the probability and
| impact of such bugs in C code in a reasonable way even
| without formal verification.
| estebank wrote:
| Does every discussion of Rust and C need this recurring
| subthread conversation? It is approaching Groundhog Day
| levels of repetition. Yes, `unsafe` code can have memory
| safety bugs. Yes, `unsafe` doesn't mean "unsafe". Yes, a
| sufficiently advanced C-developer can have a sufficiently
| advanced C-codebase with reduced probability of bugs that
| might be even better than an insufficiently advanced
| Rust-developer. Yes, regular safe-Rust isn't the same
| formal verification. Yes, Rust doesn't catch every bug.
|
| 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.
| uecker wrote:
| I might make such comments as long as other continue to
| make statements about Rust vs Cs. which I think are
| exaggerated. As long as people make such statements, it
| is obviously not a strawman.
| l-albertovich wrote:
| I felt the same way when I read the bold part that says
| "But that C codebase is an issue" so I quickly checked
| out the public databases and couldn't find a single
| serious vulnerability in the past 7 years.
|
| 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.
| pornel wrote:
| If a codebase is being maintained and extended, it's not all
| code with 20 years of testing.
|
| 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!)
| concinds wrote:
| We could move past all the unproductive, polarized online
| arguments if everyone accepted that:
|
| 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".
| udhghhe wrote:
| Thing is, Rust is not a memory safe programming language.
| It's not even close to being one.
|
| > Diagnosing a Double-Free Concurrency Bug in Rust's
| Unbounded Channels
|
| https://materialize.com/blog/rust-concurrency-bug-
| unbounded-...
| tialaramex wrote:
| C++ in particular has a thriving industry of people who'll
| come teach your team to write "proper" C++.
|
| 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#
| yjftsjthsd-h wrote:
| Almost? I'd fully support
|
| 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).
| ux266478 wrote:
| I want to preface this with "This isn't a gotcha".
|
| I think you make an important oversight with these claims,
| which is that you can enforce logical safety over a memory
| unsafe language and have a much higher degree of safety than
| memory safety. Formally verified C doesn't change the
| language, you can in principle take C code run through
| compcert and compile it elsewhere. It's still a memory unsafe
| language, but we can express a much higher degree of safety
| than simple memory safety.
|
| 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.
|
| I know anytime Rust is brought up, someone brings up logical
| safety, and patterns are annoying. 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.
| concinds wrote:
| That's a great comment and I agree.
| amelius wrote:
| In this case Rust makes sense. However for the majority of UI
| projects it doesn't make sense. For UI you want to iterate
| quickly because requirements change often, and you want garbage
| collection to be able to move fast. At the same time,
| performance does not matter (low level stuff like bit blitting
| can be done by lower level libraries perhaps written in Rust or
| even at the hardware level). A language designed for systems
| programming makes zero sense there. Unfortunately, we see a lot
| of "This UI project now in Rust!" on HN, and people get annoyed
| by that, and I think rightfully so. People don't want to
| maintain code that was written in the wrong language, and that
| __will__ happen if other people pick a language for the wrong
| reasons.
| yjdiquhf wrote:
| I am confused by this comment on the project page.
|
| 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.
| jjgreen wrote:
| Complete rewrites are always a bad idea ... [mutters of
| agreement] ... except in Rust! [cheering]
| dodomodo wrote:
| 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 wrote:
| 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.
| FieryMechanic wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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.
| pdimitar wrote:
| 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.
| FieryMechanic wrote:
| > 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.
| pdimitar wrote:
| RE: make/CMake, consider yourself in a somewhat
| privileged bubble and IMO let's leave it at that. Every
| single time I had to deal with make or CMake, I regretted
| it: every time when I used them in anger and to more of
| their capacity, with barely any exceptions. The only safe
| usages of make were like 50-line files max. And even
| there I had to manually eyeball the .PHONY targets to
| make sure I know which sub-commands I can invoke that
| don't depend on file timestamps because of course
| somebody decided it's a good idea to liberally mix those
| with the others. Sigh. Don't ask.
|
| 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.)
| tempest_ wrote:
| > 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.
| FieryMechanic wrote:
| 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.
| lynndotpy wrote:
| 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.
| FieryMechanic wrote:
| 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.
| mynameajeff wrote:
| > 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 wrote:
| 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 wrote:
| Opinions with "always" in them are always a bad idea.
| norman784 wrote:
| 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.
| anonnon wrote:
| 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 wrote:
| 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_ wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| shevy-java wrote:
| 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 wrote:
| 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 wrote:
| 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.
| agumonkey wrote:
| completely agree but it could be added that a new language
| can sometimes help explore new ideas faster, in which case
| maybe the routing layer and protocol can see new
| optimizations
| wat10000 wrote:
| It's important to remember that safety is the whole purpose
| of the thing. If Tor is slow, it's annoying. If Tor is
| compromised, people get imprisoned or killed.
| monerozcash wrote:
| This is not correct. Tor is generally not bottlenecked by the
| quantity of available nodes, the usual bottleneck is the
| quality of nodes picked by your client rather than the
| quantity of nodes available.
|
| Of course, technically, this problem is related to the
| quantity of high quality nodes :)
| rpigab wrote:
| 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_.
| kaoD wrote:
| If this is sarcastic you should probably add /s or someone
| might actually follow your "advice".
| fragmede wrote:
| Or people should not be idiots and think for themselves
| just a smidge, and not use /s.
| rpigab wrote:
| They should be fine since I made up the setting name, and
| even though I am not familiar with Tor client's
| configuration, I don't believe this is possible without
| altering its source code.
|
| Also, using this kind of software without understanding how
| its works even just a little doesn't protect much of your
| privacy.
| adastra22 wrote:
| Yeah I was confused! Pretty sure this is not
| configurable.
| deafpolygon wrote:
| 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...
| adastra22 wrote:
| The setting doesn't exist.
| willvarfar wrote:
| 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 wrote:
| How is 3 so much better than 2, but 4 not so much better
| than 3?
| willvarfar wrote:
| 1 = no privacy from relay
|
| 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.
| Surac wrote:
| That reminds me of the holy Handgranate of the Monty
| pythons
| flipped wrote:
| There's no exit nodes for onions because there's nothing
| to exit to. Nothing beats anonymity of onions and it's
| design is well created.
| mapt wrote:
| The right number for you to use is the default. But the
| right default is not necessarily 3.
| nostrademons wrote:
| Knowing not so much about Tor but some about math: the
| number of nodes you need to compromise in order to de-
| anonymize a Tor user is exponential in the number of
| hops. Google says there are roughly 7000 Tor nodes,
| including 2000 guards (entry) and 1000 exit nodes. If you
| have a single hop, there's roughly a 1/1000 chance that
| you will connect to a single malicious node that can de-
| anonymize you, going up linearly with the number of nodes
| an attacker controls. If you have 3 hops, you have a 1 in
| 1000 * 7000 * 2000 = roughly 14 billion chance. 2 hops
| would give you 1 in 2 million, 4 hops would give you 1 in
| 1000 * 7000 * 7000 * 2000 = 98 trillion. In practical
| terms 1:14B is about the same as 1:98T (i.e. both are
| effectively zero), but 1:2M is a lot higher.
| flipped wrote:
| There are currently ~9000 relays if you look at
| https://metrics.torproject.org/networksize.html. The
| current problem is the fact that majority of relays are
| in Germany and if you rotate your circuits enough, you'll
| also notice the same path. German govt has been very
| hostile towards Tor for a long time, they were also
| behind KAX17. We need more relays obviously but also in
| different regions.
| throawayonthe wrote:
| because then there is at least one node that knows
| neither the source nor the destination of a request
| sph wrote:
| The law of diminishing returns
| flipped wrote:
| What's the point of having one relay? You're better off using
| a reputable VPN like mullvad or ivpn. Tor is the best you're
| gonna get for low latency anonymous overlay network. It's
| been studied and refined over the years.
| raxxorraxor wrote:
| It would shifts part of the data route info from your
| provider toward that particular relay.
|
| But I wouldn't recommend it of course.
| flipped wrote:
| Of course it would hence you should stick with mullvad, a
| reputable VPN. Tor is not made for single relay paths,
| you're just wasting it's potential.
| mapt wrote:
| It's very difficult for me to contemplate how anybody could
| run a VPN, however reputable, that isn't compromised by one
| intelligence agency at least. Their incentive structures
| and their costs to participate in this space just make it a
| no-brainer.
|
| 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?
| Aurornis wrote:
| This is a joke, for those who didn't notice.
|
| Tor is slow because traffic is routed through multiple
| layers. The design priority is anonymity, not speed.
| paulddraper wrote:
| Your config improvement made it into Google AI
| https://i.imgur.com/v5DsXy9.png
| GoblinSlayer wrote:
| With 3 proxies traffic circles around the planet 2 times, which
| takes light 1/4 second to travel. Response does it again, so
| 1/2 second in total. Light is slow.
| brnt wrote:
| Nature just hasn't switched to Rust (and Arch) yet. Maybe
| it'll also get rid of those pesky black holes.
| mapt wrote:
| Plus TLS handshakes.
|
| 5 proxies does it even slower but would make attacks much
| more difficult.
| tialaramex wrote:
| The modern TLS 1.3 handshake is exactly the same as your
| connection setup. If we ignore the fact that (Because
| Middleboxes) you have to pretend you're talking TLS 1.2 it
| goes like this:
|
| 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
| Thorrez wrote:
| What do you mean by "exactly the same as your connection
| setup."? Are you talking about TCP?
|
| 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.)
| tialaramex wrote:
| Today, Tor doesn't move QUIC so you'd have to do TCP, but
| that's not actually a design requirement of Tor, a future
| Tor could actually deliver QUIC instead. QUIC is
| encrypted with TLS 1.3 so your first packet as the client
| is that Hello packet, there's no TCP layer.
|
| 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.
| flipped wrote:
| You meant Tor network, right? Sadly, making very fast anonymous
| overlay networks is extremely difficult. You either make it
| fast or don't sacrifice anonymity. I personally noticed that
| Tor network has significantly improved and is way faster since
| a few years. It's also not recommended to exit and if you
| religiously stay over onions, you increase your anonymity.
| mhitza wrote:
| And significantly faster to access onion websites than go
| through exit nodes, which are probably saturated most of the
| time.
|
| 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)
| John23832 wrote:
| I think this shows a misunderstanding of the purpose of TOR.
| It's for privacy, not optimal latency for your video stream.
| sandworm101 wrote:
| Hey, if you want a fast anonymity netowrk, there are commercial
| providers. Companies doing research on thier competition use
| these to hide thier true idents from targets. They are not
| cheap (not free but cheaper than AWS imho) but have much
| greater functionality than tor.
|
| https://voodootomato.medium.com/managed-attribution-the-key-...
|
| https://www.authentic8.com/blog/non-attribution-misattributi...
| jfindper wrote:
| > _Hey, if you want a fast anonymity netowrk, there are
| commercial providers._
|
| 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.
| Aurornis wrote:
| > My biggest gripe with the Tor project is that it is so slow.
|
| 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).
| jfindper wrote:
| > _It's not supposed to be a primary browsing outlet nor a
| replacement for a VPN._
|
| Tor _wants_ people to use the network for primary browsing
| because it helps mask the people that need the protection.
| The more people using the network, the better for everyone 's
| anonymity.
|
| They even have a whole "Outreach" section at
| https://community.torproject.org/outreach/
| MangoToupe wrote:
| > And I am also not entirely convinced that Rust is really
| better than C.
|
| Well it's certainly not worse than c, and it's hard to argue
| it's as bad, so...
|
| > I don't think merely moving to Rust makes Tor faster either.
|
| It would be crazy to think switching languages would make a
| network protocol faster without some evidence of this.
| udhghhe wrote:
| > 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.
| MangoToupe wrote:
| This would be a fantastic argument against rust for the
| m68k or some other embedded architecture. But we live in a
| world with an actual rust compiler for basically all
| architectures tor serves. & obviously the c standard can't
| save c from itself.
| xedrac wrote:
| I agree it probably won't make it faster. But there is
| absolutely no comparison when it comes to safety/stability.
| I've written a ton of C code, and it's just not even close.
| Rust really outshines C and C++ in this regard, and by a very
| large margin too.
| udhghhe wrote:
| How much C++ have you written? Not C, but C++.
|
| Do you like pattern matching in Rust? It is one of the
| features that Rust does decently well at.
| nurettin wrote:
| 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.
| testdelacc1 wrote:
| 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 wrote:
| 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.
| jfindper wrote:
| You're reading way to much into the title. "[...] is
| switching to [...]" does not have any implication of being a
| "spur-of-the-moment" thing
| iamnothere wrote:
| Arti is also designed to be embedded as a library in other
| apps, so messaging clients (for example) will be able to
| leverage the network without needing a correctly configured Tor
| daemon on the host.
|
| The extra safety in the code base is nice, but this seems like
| a bigger deal.
| jfindper wrote:
| > _better portability across operating systems_
|
| Does Rust have better portability than C?
| binaryturtle wrote:
| Doubtful. I can't even get Rust to work here on my slightly
| older Mac system. So with TOR switching away from a well
| supported language like C it's simple another project lost to
| me (unlikely you can stick with an older version for long in
| this case as they regularly break backwards compatibility in
| their network.)
| estebank wrote:
| > I can't even get Rust to work here on my slightly older
| Mac system.
|
| 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
| loeg wrote:
| It might have better abstractions over the current popular
| operating systems (Windows, Mac, Linux). Obviously not more
| portable in general.
| marcosdumay wrote:
| Depends on what C code you are talking about.
| testdelacc1 wrote:
| As the link I posted says
|
| > 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.
| ufmace wrote:
| Thanks! This is a much better link than the OP, and better
| preempts the usual round of "why not my other pet language X
| instead"? questions. Clearly this choice and strategy has been
| in the works for a long time and the team has carefully thought
| out all options.
| N_Lens wrote:
| Rust - "I am inevitable"
| fuzzfactor wrote:
| _Rust never sleeps._
|
| N. Young
| agumonkey wrote:
| young and rustless ?
| machomaster wrote:
| Rust in peace
| pdimitar wrote:
| "And I... am the Oxidized Man."
|
| [snaps fingers]
| marcosdumay wrote:
| Unless you use aluminum or stainless steel...
| anthk wrote:
| Why not Go? It's more portable.
| hu3 wrote:
| and easier to learn.
|
| and better funded.
|
| and easier to find devs.
| ramon156 wrote:
| 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
| FieryMechanic wrote:
| Go been around for quite a while now. It isn't going
| anywhere.
| vablings wrote:
| Rust has been around for over 10 years now. In the last
| five years the language hasn't changed much and has
| gotten better and better
| FieryMechanic wrote:
| I didn't like Rust one bit and gave up learning it. Go on
| the other hand is quite nice.
| hu3 wrote:
| > They both suck getting new devs for
|
| 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.
| agumonkey wrote:
| i have no dog in the fight, but based on tor release schedule
| it seems to me that the team is very very talented and rust
| complexity is not a challenge for them
| tjpnz wrote:
| Rust is going to feel more familiar to Tor contributors than
| Go. Based on the list of platinum members (which includes
| Google and Tor btw) there's some serious money going into the
| Rust Foundation, assuming it's managed properly I can't see
| funding as an issue.
|
| https://rustfoundation.org/members/
| hu3 wrote:
| I don't see any transparency with the funds. So it's hard
| to grasp how much is it.
|
| But it's never going to surpass Go which is owned by a 4
| trillion dollar conglomerate.
| preisschild wrote:
| 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 wrote:
| 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 wrote:
| 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...
| anthk wrote:
| No Rust under OpenBSD i686. Rust on PowerMacs? Alpha?
| lynndotpy wrote:
| 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.
| atq2119 wrote:
| Plus, Rust has a more expressive type system.
|
| 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.
| johncolanduoni wrote:
| Rust can create statically-compiled binaries on Linux by
| using musl instead of glibc, but it's not the default like it
| is in Go and is as a result not quite as effortless. There
| are a lot of crates with native dependencies that require
| slight environment tweaks to work on a musl build. Go on the
| other hand goes to great lengths to not need to link to any C
| code at all, to the point of shipping its own default TLS
| library and cryptographic primitives.
| lynndotpy wrote:
| I thought the default for both Rust and Go were to
| statically compile everything _except_ the dynamic link to
| libc? And that you could optionally statically include musl
| with a bit of extra work.
|
| 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.
| steveklabnik wrote:
| You and your parent are talking about slightly different
| things. You are both correct in different ways.
|
| 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.
| lynndotpy wrote:
| Oh that makes more sense! That's a bit of a blindspot to
| me for the pretty bog-standards ways I'd been using Rust
| and Go.
| pezezin wrote:
| Portable to what? Rust works fine on all of today's popular
| platforms.
|
| 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.
| vablings wrote:
| It is still possible to build for targets such as Itanium.
| There is nothing stopping you from writing your own targets
| too in LLVM and its not obscenely difficult
|
| https://github.com/llvm/llvm-
| project/tree/main/llvm/lib/Targ...
| edm0nd wrote:
| >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!
| yjftsjthsd-h wrote:
| That's a good point, really there's no reason to waste time
| on anything but popular platforms. Obviously, of course, this
| means dropping support for everything except Windows (x64 and
| _maybe_ ARM) and macOS (ARM). (\s)
|
| 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.
| anthk wrote:
| Not under OpenBSD i686.
|
| Also, the more heterogeneous it's a CPU architecture support,
| the least exploitable a service will be.
| krior wrote:
| Please elaborate on your last point.
| fithisux wrote:
| Rust is one of the natural choices for this kind of migration.
|
| There are others like Go.
|
| I think they made the choice based on ecosystem, performance and
| prior experience with C.
| giancarlostoro wrote:
| I still wish Mozilla had kept oxidizing Firefox. It would have
| been a net positive for Rust itself.
| anonnon wrote:
| Clearly, the fact that Servo failed must be indicative of
| shortcomings in Mozilla itself, and not Rust the language, its
| ecosystem, or its users.
| johncolanduoni wrote:
| Mozilla was the primary steward of Rust for most of the time
| that the Servo project was active. So if you want to lay
| Servo's failure at the feet of the Rust language, it's pretty
| hard to cast Mozilla as the blameless victims of... whatever
| it is that Rust users as a whole did to make Servo fail.
| psychoslave wrote:
| The language surely has many cons, like any language out
| there. And maybe it wasn't a good fit for Mozilla products.
| But Mozilla the organisation doesn't really looks that great
| in term of governance. Given Rust is now even integrated
| officially in Linux kernel, I have strong doubt that the
| technical caveats are the main factor of misalignment with
| Mozilla priorities.
| WD-42 wrote:
| Did it fail? The servo project seems alive and well, just not
| under Mozilla. They decided CEO pay packages were more
| important.
| anonnon wrote:
| > Did it fail
|
| 13 years to get to v0.0.1 is a success? Look at how much
| progress Ladybird has made in a fraction of that time.
| Remember that these people are constantly starting rewrites
| of C and C++ projects (when they're not demanding others do
| it) in Rust "for safety" (and "oops it's MIT now"), even of
| ancient Unix utilities with minimal attack surfaces like
| the "date" command, yet when it comes to a browser
| rendering engine, which entails computationally-intensive,
| aggressively-optimized rendering of untrusted input--a
| massive attack surface, and the very thing for which Rust
| was supposedly designed--they somehow can't get the right
| combination of enough Rust zealots (and Adderall) to get
| past the finish line.
| notnullorvoid wrote:
| Success isn't a binary thing. It's true that Servo has
| long struggled to make progress, and that can be seen as
| a failure. It's recent progress can also be seen as a
| success.
|
| Your life might improve if you stop believing that Rust
| devs belong to a cult of your own imagination.
| estebank wrote:
| Measuring success of a project against a bar that the
| project didn't set is like complaining that an F1 car is
| hard to park: that's not what it was meant to do.
|
| Servo was meant to be a test-bed for new architectures
| that might or might not be usable by Firefox. It was
| never meant to become Firefox' new web renderer, and it
| wasn't until more recently and long after the Mozilla-
| pocalypse that a new team took over the project with a
| goal of productionalizing the project as a whole. Stylo,
| for example, was integrated into Firefox 57 and allowed
| for parallel CSS style calculation, an effort that was
| tried unsuccessfully multiple times in C++.
| udhghhe wrote:
| There are architectural concerns. Even when Rust proponents
| and cultists try to harass unrelated projects into
| submission, as they are wont to do.
|
| https://github.com/microsoft/typescript-go/discussions/411
| notnullorvoid wrote:
| TS decision to choose Go was primarily, because they could
| take the existing code and do a near 1-1 translation. You
| can frame that as an architectural concern, but it's really
| only one that applies when your attempting to migrate an
| existing program to a new language. The Go rewrite has some
| negative outcomes as well, most concerning is the
| performance of the WASM builds is worse than the old JS/TS
| version.
|
| A TS compiler from scratch built in Rust would be fine.
|
| > cultists
|
| The cult is in your imagination.
| hu3 wrote:
| Not your parent commenter but:
|
| > You can frame that as an architectural concern...
|
| "Go also offers excellent control of memory layout and
| allocation (both on an object and field level) without
| requiring that the entire codebase continually concern
| itself with memory _management_. "
|
| "The TypeScript compiler's move to Go was influenced by
| specific technical requirements, such as the need for
| structural compatibility with the existing JavaScript-
| based codebase, ease of memory management, and the
| ability to handle complex graph processing efficiently. "
|
| If memory management and ability to handle complex graph
| processing efficiently isn't related to architecture to
| you I don't know what to tell you.
|
| [0] https://github.com/microsoft/typescript-
| go/discussions/411
|
| > The cult is in your imagination.
|
| CTRL+F "rust" on the Go issue and see how many results
| you get. 31 for me and that's before expanding spam.
| notnullorvoid wrote:
| > If memory management and ability to handle complex
| graph processing efficiently isn't related to
| architecture to you I don't know what to tell you.
|
| Rust can do complex graph processing, as well as
| efficient easy memory management, but it's going to do it
| in a different structure than a GCed lang would. Hence my
| statement that 1 to 1 translation was the primary factor.
|
| > CTRL+F "rust" on the Go issue and see how many results
| you get.
|
| Yes and so what? There's 35 for .NET or 74 for C#, yet
| you don't see people claiming the C# cult was harassing
| the TS team.
| elevation wrote:
| At least the Chrome team is still oxidizing.
| tialaramex wrote:
| I mean, they are, so presumably you mean _more quickly_ ? There
| 's a HN article about this _after_ Mozilla fired loads of Rust
| hackers, and a larger fraction of the Firefox codebase is in
| Rust than was then, which was in turn more than in 2021 when I
| first was interested.
|
| It's possible that if Rust had remained "secret sauce" for
| Mozilla it would have hurt its usage elsewhere, impossible at
| this distance in time to be sure. There is, for example, far
| less Rust in Chromium (less than 4%) than in Firefox (more than
| 12%).
| buildbuildbuild wrote:
| This was mostly funded by Zcash Community Grants. Good things can
| come from crypto R&D.
| tialaramex wrote:
| Pecunia non olet
|
| I think perhaps cryptocurrency is worse than selling urine for
| its chemical properties, but the principle applies, money is
| just money
| ekjhgkejhgk wrote:
| OT on Tor:
|
| Recently this link was on HN[1]. It ranks your browser on regular
| tracking and fingerprinting separately. "Tor without JS" was the
| only option I found to be completely fingerprint resistant. Even
| Tor "with JS on strict settings" ranked it as only "partly
| fingerprint resistant". (Interestingly firefox without JS never
| returns)
|
| Scary stuff.
|
| I'd like to hear other people's experiences/experiments here.
|
| [1] https://coveryourtracks.eff.org/
| 47282847 wrote:
| Tor Browser tries to widen the fingerprint buckets you can get
| put into by eg rounding off canvas sizes. The widest bucket and
| unavoidable is "Tor (browser) user".
| mawadev wrote:
| You can even track people by favicon which bypasses incognito
| mode. Another part is hiding font urls in css with more
| tracking...
| mr_mitm wrote:
| Was incognito mode ever meant to prevent tracking? I thought
| it was for porn, I mean buying surprise presents on a shared
| computer.
| sharperguy wrote:
| it's commonly used for checking how sites look when not
| logged in, without logging out, or logging in as another
| user temporarily.
| jfindper wrote:
| You're correct, incognito mode never has been for privacy
| protection from websites, ISPs, etc.
| shlomo_z wrote:
| While this was possible in the past, I believe it got patched
| and is impossible today.
| armchairhacker wrote:
| In iOS embedded WebView: "strong protection against Web
| tracking", and a fingerprint of ~20 bits.
| infogulch wrote:
| A basic Brave install: "strong protection against Web
| tracking" / 18.58 bits
| monerozcash wrote:
| Regular OS X safari: Our tests indicate that you have strong
| protection against Web tracking.
|
| >Your browser fingerprint has been randomized among the 378,837
| tested in the past 45 days. Although sophisticated adversaries
| may still be able to track you to some extent, randomization
| provides a very strong protection against tracking companies
| trying to fingerprint your browser.
|
| >Currently, we estimate that your browser has a fingerprint
| that conveys at least 18.53 bits of identifying information.
|
| Anyway, this test doesn't really communicate the results very
| well. Yes, Tor browser stands out. No, it's not easy to
| differentiate between different Tor browser users via this kind
| of fingerprinting.
| ekjhgkejhgk wrote:
| Could you clarify if that's with or without JS?
| monerozcash wrote:
| I have not disabled JS or made any other configuration
| changes on this device. Entirely stock Safari and entirely
| stock MacOS.
| ekjhgkejhgk wrote:
| That's not really believable. I'm starting to think this
| website isn't very reliable.
| monerozcash wrote:
| No, it's believable. All this website is communicating to
| us that most MacOS Safari installs look the same.
| ekjhgkejhgk wrote:
| It's not "install" that matter here. If two people have
| the same "install" but their browser windows have
| different sizes, they'll be distinguishable. Or any
| perperty that can be queried via JS.
|
| Let me rephrase it: you believe it, I don't believe.
| monerozcash wrote:
| Browser window size and timezone are basically the only
| identifying details the page gets besides the fact that I
| use Safari on MacOS
|
| For window size only 1 in 380326.0 browsers has this
| value.
| ekjhgkejhgk wrote:
| For example, what does the section "time zone" and "time
| zone offset" read for you? You have JS on, so what did JS
| return on that point?
|
| I'm downloading safari right now.
|
| EDIT: just saw I need to download playonlinux or wine.
| Forget about it.
| monerozcash wrote:
| It gets my correct timezone.
| ekjhgkejhgk wrote:
| > For window size only 1 in 380326.0 browsers has this
| value.
|
| Sorry, who concluded that this is fingerprintin
| resistant? Does the website tell you that, or was this
| your conclusion? Because my reading is with a number that
| small, you're almost uniquely identifiable. Is it
| possible you're misunderstanding what the report is
| showing?
|
| Would you be assed to continue this conversation
| elsewhere? I'd like to get to the bottom of this?
| monerozcash wrote:
| That's the website output.
|
| Those two values are the only ones returned by the
| browser which are useful for fingerprinting beyond "stock
| safari". Window size being the biggest part of that, but
| window size tends to change fairly regularly.
| losvedir wrote:
| Huh, I use a "stock" (I think?) MacOS Safari and got "Your
| browser has a nearly-unique fingerprint" and "Partial
| protection" for ads and invisible trackers.
|
| Did you change a setting or add an ad blocker or something?
|
| edit: I feel like someone with a username "monerozcash" must
| have some customization to your browsing experience, that
| maybe you don't even remember doing...
| monerozcash wrote:
| No, on this device literally the only customization I have
| is the RECAP browser extension. And even RECAP only runs on
| whitelisted websites.
| Aerbil313 wrote:
| It's probably precisely because his browser is not
| customized that it's not easily fingerprintable, because
| stock Safari has privacy protections and users generally
| don't change anything.
|
| I got a very similar result on unmodified iOS Safari,
| randomized among 380k users and conveying 15.5 bits of
| information. I only have the Dark Reader extension.
| ekjhgkejhgk wrote:
| I'm downloading safari right now.
|
| EDIT: just saw I need to download playonlinux or wine.
| Forget about it.
| pixel_popping wrote:
| Tor without JS is still subject to some degree of
| fingerprinting through CSS (media queries, caching) and
| tracking methods through mouse (without JS).
| SoKamil wrote:
| > and tracking methods through mouse (without JS).
|
| How?
| npn wrote:
| Hovering can trigger network request
| Santosh83 wrote:
| Visiting this site with a freshly installed, stock Tor browser
| (therefore _with_ JS enabled, no settings changed from
| defaults) on Debian stable gives me:
|
| "Our tests indicate that you have strong protection against Web
| tracking."
|
| "Within our dataset of several hundred thousand visitors tested
| in the past 45 days, only one in 301.9 browsers have the same
| fingerprint as yours.
|
| Currently, we estimate that your browser has a fingerprint that
| conveys 8.24 bits of identifying information."
|
| Interestingly, increasing the Tor Browser Security level from
| Safe to Safer actually increased the bits of identifying
| information and reduced the anonymity:
|
| "Within our dataset of several hundred thousand visitors tested
| in the past 45 days, only one in 832.32 browsers have the same
| fingerprint as yours.
|
| Currently, we estimate that your browser has a fingerprint that
| conveys 9.7 bits of identifying information."
|
| And at the Safest Security level (i.e. with JS diabled) the
| identifying bits and anonymization appear to be at their best:
|
| "Within our dataset of several hundred thousand visitors tested
| in the past 45 days, only one in 261.41 browsers have the same
| fingerprint as yours.
|
| Currently, we estimate that your browser has a fingerprint that
| conveys 8.03 bits of identifying information."
| ekjhgkejhgk wrote:
| I'm also on Debian 13 stable, that's definitely not what I
| get with JS. Weird.
| twhb wrote:
| This tool is deeply flawed. Fingerprinting protection is
| sometimes done by binning, which this tool rewards, and is
| sometimes done by randomizing, which this tool harshly
| punishes. The net result is it generally guides you away from
| the strongest protection.
|
| The flip side of this, having the complementary flaw of testing
| only persistence, not uniqueness, is (warning, real tracking
| link) fingerprinting.com/demo. You can try resetting your ID
| and seeing if it changes here. Since tracking requires (a
| degree of) uniqueness AND (a degree of) persistence, the danger
| signal is only failing both the EFF test and this test.
|
| Failing both is a requirement to derive meaning, not being lax:
| measuring only uniqueness would fail a random number generator,
| and measuring only persistence would fail the number 4.
| ekjhgkejhgk wrote:
| You make an interesting point on binning vs randomization.
| I'm not an expert but to me your point is consistent with Tor
| having the "best protection" according to the website,
| because I know that Tor's strategy is binning. However, this
| is what actually makes sense for many variables though. For
| example, font sizes come in integers. If you're trying to be
| clever by "randomizing" and claiming to use decimal-sized,
| you might be the only person in the world to do so and
| immediately fingerprinted. So I think that randomization
| might indeed be a bad idea in many cases.
|
| Your link doesn't work though. I just get "file not found".
| monerozcash wrote:
| It seems to reward totally unique randomized fingerprints
| also, which is maybe not great.
| fuddle wrote:
| Interesting, Chrome failed but Firefox and Brave "have strong
| protection against Web tracking."
| hnthrow82926 wrote:
| I'm sure replacing the battle-tested C implementation with a Rust
| implementation that's extremely vulnerable to supply-chain
| attacks and has seen little real-world usage is not going to
| backfire at all.
| npn wrote:
| It is intended. Like any other US gov funded projects.
| linsomniac wrote:
| Is there any way to run a Tor exit node without expecting to get
| a knock on the door from the FBI/DHS? Like advertising as an exit
| node but only to a whitelist of sites? For ~20 years I ran a
| dozen cabinet at a colo but never felt I could donate bandwidth
| to Tor because of that (did a big mirror server instead), and now
| I have gigabit (could be 10gig) at home, but still just don't
| want to deal with the issues.
| Havoc wrote:
| Not to my knowledge.
|
| > now I have gigabit
|
| You can host torrents to Linux isos to help. You'll need to
| block some Chinese ASNs though. They use fake downloaders to
| detect peers. Like 99% of the traffic my node generated was
| that. Nodes from one ASN that do partial downloads over and
| over
|
| Else hosting open map data tile server though I gather this can
| generate a lot of traffic
| ahmibrme wrote:
| Tor provides a great blog about running an exit node:
| https://blog.torproject.org/tips-running-exit-node/
|
| I remember reading that it's better to register as an
| organization if you want to run an exit node.
|
| If you want to help the network, you can run relays. That's
| much safer. https://community.torproject.org/relay/
| throw816593256 wrote:
| For anyone wondering how else they can help without attracting
| scrutiny, consider running a bridge. I have done this at home
| for years and haven't noticed any ill effects like
| discrimination of my public IPs:
| https://community.torproject.org/relay/setup/bridge/
|
| Or, if you're OK with a little discrimination (say you're colo
| hosted, not residential), but still want to avoid exit-relay-
| level attention, running guard/middle relays is helpful:
| https://community.torproject.org/relay/types-of-relays/
| voidUpdate wrote:
| Isn't Tor a concept, a protocol? It's like saying you're going to
| rewrite http in rust...
| kstrauser wrote:
| No.
| mmooss wrote:
| It's a product. You can download and implement it's many
| components.
| okanat wrote:
| Onion routing is the protocol. Tor is the network and the name
| of the reference implementation.
| runtimepanic wrote:
| Rust adoption in privacy tooling always feels like watching an
| old fortress quietly replace its wooden beams with steel ones.
| Tor's codebase has carried decades of security assumptions, C-era
| tradeoffs and performance scars, so a gradual Rustification seems
| like the most sensible way to buy safety without breaking the
| ecosystem. The real win isn't "rewrite everything" but reducing
| the surface area where memory-unsafety bugs can even exist. If
| the team can shift the high-risk subsystems (parsing, crypto
| glue, protocol edges) into Rust while keeping well-tested C where
| it's stable, Tor ends up with a sturdier core without a multi-
| year rewrite freeze. The interesting question is how far they'll
| push it: Will future pluggable transports be Rust-first? Will
| relay operators eventually run a hybrid runtime? Or does this
| turn into a long coexistence phase like Firefox? Either way, a
| safer Tor is a good Tor.
| nlitened wrote:
| They should just start compiling Tor with Fil-C -- free memory
| safety, no new bugs from full code rewrite
| steveklabnik wrote:
| This move started before Fil-C existed.
___________________________________________________________________
(page generated 2025-12-12 23:01 UTC)