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.
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.
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".
I agree on randomization, but there are other places where it doesn’t stick out like that. I’ll look up specifics if I find the time, but I think reading canvas data without permission is one place it’s utilized, including by Tor.
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.
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...
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.
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.
> 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?
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.
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”.
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."
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.
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.
> 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.
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.)
> 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].
I'm on a slightly older version than 10.12. I'm out of this limited support range. The problem is that as soon Apple cuts off older systems by heavy force all of the Mac developers running in circles like lemmings and cut off their projects from the older versions too: feeding right into Apple's policy to deprecate older systems for their own greed.
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.
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.
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%).
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.
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.
First, wine was widely panned for years before it stopped sucking.
Second, you're simply ignoring that parent poster mentioned Ladybird, a non-rust project which is advancing much more speedily than servo. And I think they have a valid point -- and while the jury is still out, it's possible that in other rust-centric efforts which have experienced foot-dragging (eg WASI), the root cause may be rust itself.
Parent poster expressed their point somewhat sarcastically, but if I (C++/python dev, I admit!) were a betting transfem, my money would be on them being right.
That said, I think the Tor project got this decision right. This is as close to an ideal use-case for rust as you can get. Also, the project is mature, which will mitigate rewrite risk. The domain is one where rust can truly shine -- and it's a critical one to get right.
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.
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++.
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.
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.
> 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.
> 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.
Sure, and Rust is the most used language for modern TS/JS tooling, outside of TS/JS. There would have been substantial ecosystem benefits had Rust been chosen.
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!
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.
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.
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.
The distribution I use already has limited security updates for Rust: https://www.debian.org/releases/trixie/release-notes/issues.... which reduces my security. The cargo supply chain issues are also very obvious, I am far more worried about this than I ever will be about memory safety, but hopefully tor reduces its reliance on random dependencies.
I find that surprising given that Debian breaks Rust programs up into individual apt packages, but ultimately, other distros do not have this issue. It’s also about userspace programs and not the kernel, which does not use external packages and so sidesteps this completely.
Debian forky has Rust in the kernel on by default.
Right, from my understanding, Debian was packaging Rust programs in the same way as C ones. So they’d update the individual library and it should be all good. They deduplicated all of the dependencies in their trees.
This seems reasonable to me. If you have a tarmaggeedon, you update one library instead of thousand of packages. Although I am not sure how well this can work in Rust with monomorphization.
Do you think the sibling comment was flagged to "protect me" whatever that means, or is it because "Are you high on Prozac?" is not really a productive comment?
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.
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.
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.
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++.
> 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.
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…
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.
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".
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).
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.
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#
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.
I think companies hired too many Rust engineers, and now those engineers are writing technical blogs and making product decisions. We're seeing a lot of those everyday on HN first page
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.
> (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.
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.
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.
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.
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.
I don't know where I've lied about this, supposedly. Unless you say that, because of this implementation exception (which is based on target, not std vs no_std by the way) as meaning that "there's no UB in safe Rust" to be a lie.
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.
> For an example, if a function in no_std overflows, it can result in undefined behavior, no unsafe required. And stack overflows are easy in Rust, like they are easy in most other systems languages.
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.
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
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.
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.
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.
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.
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.
And of course, "impossible to refactor" just is very deep in the bullshit territory. "more fun to write new code" would probably be more honest, and the Rust proponents created a marketing narrative that allows them to do this while pretending (and probably also believing themself) to do a good thing.
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!)
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.
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.
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
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 :)
Yes, but let's not forget it's voluntary based. There are lots of high quality nodes, although less which are basically burning money and getting nothing in return. We all believe in a censorship-resistant and free web but only few are willing to take action. My two small guard/middle relays are rented at 10$/m each and is only 100Mbit/s non-metered up/down because it gets expensive.
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.
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
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.)
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.
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.
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)
Onions are extremely fast and for the level of anonymity they provide, it's an amazing advancement. It's surprising that Reddit has kept their onion in working condition given their poor attempts (a very bad TLS fingerprinting for all redlib instances) recently to shutdown redlib instances.
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.
> Tor browser team doesn't want to for simple reason: fingerprinting.
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.
As much as I agree with it, they see it as another maintenance headache and unnecessary attack surface. NoScript is the only extension which they've been shipping since quite a while.
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.
>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.
> 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).
>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.
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.
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.
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.
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...
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.
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.
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?
> 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.
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.
Ahh here you are speaking nonsense again. We ain't talking formal logic, we're speaking human to human
> 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 (or "lie" as I'm sure you'd term it), 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 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.
I've written C++ for 15 years. It's the language I have the most experience with. And yes, pattern matching is a must, particularly for any language that has sum types.
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.
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/
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
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.
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.
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
See? This is exactly my point. The last 32-bit only Intel CPUs were the original Intel Core series. Core 2 was already 64-bit, and it was released in 2006.
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.
2) Linux runs all of the world supercomputers, most of the internet infrastructure (server, routers, etc), most of the cellphones (Android), and lots of other things. Its global marketshare is way bigger than macOS and all the BSD put together.
To remain clear: This is largely devil's advocate. I believe that niche platforms generally should be supported, and that includes GNU/Linux on amd64, and NetBSD on literal VAX (yes, that is an officially supported platform in current NetBSD), and RedoxOS on ARM, and OpenBSD on MIPS, and [...]. I just think it's really weird to claim that GNU/Linux, with 3% of the desktop market, should be supported, but a platform that is similarly a small fraction of Linux is dead weight that should be dropped.
With that said, remainder of this comment continues with the position that GNU/Linux, which I am writing this comment on, is obviously not worth supporting for the same reasons as i.e. MIPS and RISC-V.
> 1) Development resources are finite.
That is an argument in favor of cutting niche platforms like GNU/Linux.
> 2) Linux runs all of the world supercomputers,
You can't defend a niche OS by pointing out that it's used in a tiny niche market. How many supercomputers exist on earth? I'd bet you there are more working MIPS installations than supercomputers.
> most of the internet infrastructure (server, routers, etc),
I'll grant you headless machines used by IT folks, but that's still a specific subset of the market and it has little bearing on whether, say, Tor should support it as a desktop OS.
> most of the cellphones (Android),
Android/Linux is quite different from GNU/Linux; effectively nobody developing for Android is targeting Linux in any meaningful sense.
> and lots of other things. Its global marketshare is way bigger than macOS and all the BSD put together.
Only if we include embedded systems and servers. If you intend to target servers, then yes obviously Linux matters. Otherwise, not so much.
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.
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.
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.
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.
Golang doesn't dynamically link to libc by default on Linux either - it calls the Linux kernel ABI directly (since that ABI is stable). The main upshot of this is that you don't have to worry about the classic glibc version bingo by default, while with Rust you have to go through some extra steps to avoid that.
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.
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.
This is legit question, especially for Tor binaries.
Advantage of Rust (or original C implementation) is for users that do not have runtime and want to import Tor libraries (like arti-client) in their code. Go could work but those unmanaged languages are better here. So in the end Rust (or C, C++ etc.) can serve more user-cases.
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.
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.
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
Complete rewrites have been done before. They're not impossible tasks. C to C++ (like with fish), C++ to Rust (fish again, Tor, etc), Java to C# (something I've seen), C# to C++ (evernote), Blender Game Engine to Godot (many small cases), Godot to Lumberyard (something I've seen), Unity to Godot (many small cases), etc. And there are all the myriad rewrites within the same language, or across major breaking changes (like Python 2 to Python 3).
I think "you should never do a full rewrite" is something of a reactionary response to the juvenile idea new devs and interns get every now and then. But sometimes, a rewrite really is a good idea.
But in this case, per the announcement ( https://blog.torproject.org/announcing-arti/ ), the reasons are pretty convincing. The major reasons are, unsurprisingly, all around memory safety.
> Godot to Lumberyard
Do you remember what project(s) this was? I'd be super curious on the motivations of the developers. I guess I could see it when it first went open source and Godot wasn't all it was today.
It was a project I worked on as an intern at Electric Boat. I can only speak to specifics I was explicitly given the okay to share though (i.e. this is all on my LinkedIn).
The project was a virtual training simulation for a submarine cockpit, first in Blender Game Engine. With support for BGE being deprecated, I was tasked to find an alternative engine and to port the work. (I'm very proud my research pointed to Godot- this was during the Godot 2 era).
There was a lot of interest in the project, but my internship was coming to an end and they decided to port it to Amazon Lumberyard for fear of Godot's longevity and support. They didn't want to be left "waiting for Godot". The final task I took on was to document the project, to make that transition easier for whoever came next.
The issue is that every other week there is a rewrite of something in Rust. I just do an eyeroll whenever I see that yet another thing is being rewritten in Rust.
I've tried compiling large projects in Rust in a VM (8GB) and I've run out of memory whereas I am sure a C/C++ large project of a similar size wouldn't run out of memory. A lot of this tooling I had to compile myself because it wasn't available for my Linux distro (Debian 12 at the time).
A lot of the tooling reminds me of NPM, and after spending a huge amount of my time fighting with NPM, I actually prefer the way C/C++/CMake handles stuff.
I also don't like the language. I do personal stuff in C++ and I found Rust really irritating when learning the language (the return rules are weird) and just gave up with it.
> whereas I am sure a C/C++ large project of a similar size wouldn't run out of memory
This is a common issue on large C++ projects for users with limited resources. You typically have to tinker with build settings and use a different linker etc.. to get the project building without OOMing.
> A lot of the tooling reminds me of NPM
My feeling is that you'd have the same criticism about a lot of other modern ecosystems because they allow you to pull dependencies easily. With things like vcpkg, that's also possible in C++ but even without it: nothing stops the same behavior of importing "random" code from the internet.
A lot of the modern tooling feels like a rube goldberg machine when it goes wrong. If you are forced (like I am) because of byzantine corporate rules to use older version of said tools, it is extremely painful. Don't get me started on stuff like babel, jest, ts-jest and all that gubbings. AI been a godsend because I can ask Claude what I want to do.
I use vendor directory in my C++ project and and git submodules and I've got a build that works cross platform. The biggest issue I ran into was MinGW and GCC implement the FileSystem library differently (I don't know why). It wasn't too difficult to fix.
To be fair, you haven't explained why it's an issue to see projects being rewritten in Rust, other than it is a bit annoying to you?
For me, I had a very good experience rewriting a project in Rust (from Python). It was just an improvement in every regard (the project was easier to build and distribute, it was a good opportunity to rearchitect it, and the code ended up 20k times faster.) So, I have the opposite feeling when I see titles like these.
I also feel the opposite about the tooling. For me, cmake, npm, pip, maven, etc. all live in this realm where any invocation could become a time purgatory. The big thing that makes me like Rust is that I've never had that experience with cargo. (In fact, pip was the primary motivation to move away from Python to Rust. Everything else was just nice.)
I'm not saying this to convince you to feel otherwise, I just wanted to offer how I felt about the same topics. I grew up with C and Java, but Rust clicked after I read SICP and followed along in Racket. I could probably fill a page of small grievances about Rust's syntax if I had to.
Rewriting stuff is largly a waste of time unless the underlying design/product is flawed. You are going to have to solve the same challenges as before but this time in Rust.
Anyone that been on a "rewrite" knows that often the end result will look like the previous implementation but in <new thing>.
So what I see is a lot of development effort to re-solve problems that have already been solved. I think Ubuntu did this with the core-utils recently (I don't keep up with the Linux dramas as there is a new one every week and tbh it isn't interesting a lot of the time). They ended up causing bunch of issues that I believe were already fixed years ago.
There are issues with things in Linux land that have been issues for years and haven't been resolved and I feel that development effort would have probably been better spent there. I don't pay canonical employees though, so I guess I don't get to decide.
> A lot of the tooling reminds me of NPM, and after spending a huge amount of my time fighting with NPM, I actually prefer the way C/C++/CMake handles stuff.
I guess you and me live different lives because I have spent far more time messing with ancient C/C++/CMake/Automake/Autoconf/configure/just have this particular .so file in this particular spot/copy some guys entire machine because this project only builds there/learn and entirely different language just to write build files (CMake sucks and 5 other alternatives are just lipstick on a pig) etc. etc.
I am of the opinion that half of Rusts success is based on that fact that C/C++'s tooling is annoying and ancient. People want to write code not mess with build envs.
The issue you are describing isn't an problem with C/C++ tooling. It is to do with how the developer dealt with dependencies i.e. poorly. BTW this happens in any language if they do that. I've had to deal with some awful C# code bases that would only compile on one guys machine.
I am a hobbyist C/C++ developer and have a intermediate size code base that builds on Linux, Windows (MinGW and MSVC) and MacOS and I didn't do anything particularly special. What I did do is setup CI early on in my project. So I had to fix any issues as I went along.
Sure. That doesn't matter. Of course you can keep writing your C/C++ or using CMake, nobody is going to stop that. But other people's project are not going to stop adopt new tech stack because how you feel about it.
> That doesn't matter. Of course you can keep writing your C/C++ or using CMake, nobody is going to stop that.
What it is going to cause is having to learn a bunch of new tooling which I have to somehow to get behaving on my Debian box, because a particular tool that I will need to compile from source will have a bunch of Rust dependencies.
I've already run into this BTW, where I wanted to compile something in Rust and it needed a third party task runner called "just". So I then needed to work out how to install/compile "just" to follow the build instructions.
Why they needed yet another task runner, when I am pretty sure make would have been fine, is beyond me.
> But other people's project are not going to stop adopt new tech stack because how you feel about it.
I don't expect them to. That doesn't mean I can't comment on the matter.
RE: memory, any self-respecting CI/CD system will allow you to compile any Rust project without out-of-memory halts.
RE: NPM, you have a right to a preference of course. I certainly don't miss the times 20 years ago when pulling in a library into a C++ project was a two-week project in itself. make and CMake work perfect right up until they don't and the last 2% cost you 98% of the time. Strategically speaking, using make/CMake is simply unjustified risk. But this is of course always written off as "skill issue!" which I gave up arguing against because the arguers apparently have never hit the dark corners. I have. I am better with Just and Cargo. And Elixir's mix / hex.
What you like as a language (or syntax) and what you roll your eyes at are obviously not technological or merit-based arguments. "Weird" I can't quite place as an argument either.
Use what you like. We all do the same. The original article lists good arguments in favor of Rust. Seems like a good case of "use the right tool for the job" to me.
> RE: NPM, you have a right to a preference of course. I certainly don't miss the times 20 years ago when pulling in a library into a C++ project was a two-week project in itself. make and CMake work perfect right up until they don't and the last 2% cost you 98% of the time. Strategically speaking, using make/CMake is simply unjustified risk. But this is of course always written off as "skill issue!" which I gave up arguing against because the arguers apparently have never hit the dark corners. I have. I am better with Just and Cargo. And Elixir's mix / hex.
I've lost countless hours having to get the rube goldberg machine of npm, jest, typescript, ts-jest and other things to work together. In contrast when I was learning OpenGL/Vulkan and general 3d programming, I decided to bite the bullet and just do C++ from the start as that was what all the books/examples were in. I had been told by countless people how hard it all was and how terrible the build systems were. I don't agree, I think the JS ecosystem is far worse than make and CMake. Now I am already an experienced programmer that already knew C# and Java, maybe that helped as they have many of the same concepts as C++.
Now I did buy and read a book on CMake and I did read the C++ 11 book by Bjarne Stroustrup (I found it second hand on ebay I think).
> What you like as a language (or syntax) and what you roll your eyes at are obviously not technological or merit-based arguments.
They aren't. What I am trying to convey is that it feels like a lot of things are done because it is the new shiny thing and it is good for resume/CV padding.
> "Weird" I can't quite place as an argument either.
The return keyword is optional IIRC in some circumstances. I think that is weird. I think I stopped there because I just wasn't enjoying learning it and there are zero jobs in my area of it.
> Use what you like. We all do the same.
The issue is that I think it (Rust) is going to worm it way everywhere and I will be forced to deal with it.
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.)
> 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.
I don't understand why many people on here say "humans", instead of people. It sounds like you are talking as if you are a grey alien on a space ship somewhere.
What you are complaining about is abuse of tools/language features. This can happen in any language and/or tools.
That doesn't mean the tool itself is bad.
> Help me understand the actual technical criticism buried in the "worm its way everywhere", please. And in the
"it's good for CV/Resume padding" statement as well.
They are self explanatory. I don't like it when someone does this stupid game of not understanding common idioms.
> It's a strange thing to say and it smells like a personal vendetta which is weirdly common on HN about Rust and to this day I have no idea why even though I have asked many people directly.
It isn't. What typically happens is that a tool lets call it "Y" get used everywhere to the point where you cannot use "X" without "Y".
Ruby used to get used for CV padding. I used to work in a Windows/.NET shop and someone wrote a whole service using Ruby on Rails in a Suse Linux. That person left and got a job doing Rails shortly after.
> Rust has objective technical merits and many smart devs have documented those in their blogs -- journeys on rewrites or green-field projects, databases, network tools (like OP), and even others. Big companies do studies and prove less memory safety bugs over the course of months or years of tests.
Just because <large company> does something and says something is true doesn't mean it is or is suitable for everyone or it is actually true.
I have worked at many <large corps> as a contractor and found that the reality presented to the outside world is very different to what is actually happening in the building.
e.g.
I was working at a large org that rewrote significant portions of their code-base in new language instead of simply migrating their existing code-base to a new runtime.
I made plenty of money as a contractor, but it was a waste resources and the org lost money for 3 years as a result.
BTW they never fully transitioned over to the new code-base.
Company blogs and press releases will say it was a success. I know for a fact it wasn't.
> The Linux kernel devs (not unanimously) have agreed that Rust should no longer have experimental status there recently -- and people are starting to write Linux drivers in Rust and they work.
So I will need any additional toolchain to build Linux drivers. This is what is meant by "worming its way in". I have done a LFS build and it takes a long time to get everything built as it is.
> I am honestly not sure what would satisfy the people who seem to hate Rust so passionately. I guess it announcing full disband and a public apology that it ever existed? Yes this is a bit of a sarcastic question but really, I can't seem to find a place on the internet where people peacefully discuss this particular topic.
You are making assumptions that I hate Rust. I don't. I just don't care for it.
What I do hate is hype and this constant cycle of the IT industry deciding that everything has to be rewritten again in <new thing> because it is trendy. I have personally been through it many times now, both as an end user and as a developer making the transition to the <new thing>.
You are kind of ranting on general trends here, not to mention misrepresenting what I said which I cannot see as arguing in good faith (never said that big companies using something makes it good; I said that they did studies -- that's absolutely very much not the same as many other types of cargo culting that they do which I'll agree is never credible).
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.
> You are kind of ranting on general trends here, not to mention misrepresenting what I said which I cannot see as arguing in good faith (never said that big companies using something makes it good; I said that they did studies -- that's absolutely very much not the same as many other types of cargo culting that they do which I'll agree is never credible).
I didn't misrepresent anything you said. You misunderstood what I said. I said companies will claim all sorts of things and the reality behind the scenes is very different. Having a study is one form of making claims. What works at one company may not work at another.
> I am not pretending to not understanding anything as well by the way,
Yes you were. What I said was plainly obvious.
CV driven development is a well known and understood phenomenon.
Technology stacks being subverted is a well known and understood phenomenon.
It is very annoying when people pretend not to understand basic idioms. It is a dishonest tactic employed by people online, I've been online now since the late 90s and have seen it done many times. You are not the first and won't be the last.
> I was trying to find objective technical disagreements and still can't find any in your reply.
I gave you them. Several in fact.
Part of engineering is understanding that resources aren't infinite and you have to make trade offs. So how resources (money, time, man power, compute) is used is technical. I make calls all the time on whether something is worth doing based on the amount of time I have.
This is often discussed on many blogs, podcast and books about software engineering.
What you want to do is narrow discussion down to the sort of discussion "well they found they found X more bugs using Y technique". Ignoring the fact that they may had to spend a huge amount of man power to rebuild everything and created many more bugs in the process.
> I am seeing a bit of curmudgeon-ing on several places though, so I am bowing out.
Yes I am disillusioned with the industry after working in it for 20 years. That doesn't invalidate what I say.
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.
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.
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.
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.
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.
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.
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.
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/
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.
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".
Sorry, fixed link: https://demo.fingerprint.com/playground.
I agree on randomization, but there are other places where it doesn’t stick out like that. I’ll look up specifics if I find the time, but I think reading canvas data without permission is one place it’s utilized, including by Tor.
[flagged]
It seems to reward totally unique randomized fingerprints also, which is maybe not great.
[flagged]
This is the 3rd copy of a flagged comment within a single minute.
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.
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...
No, on this device literally the only customization I have is the RECAP browser extension. And even RECAP only runs on whitelisted websites.
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.
I'm downloading safari right now.
EDIT: just saw I need to download playonlinux or wine. Forget about it.
The randomisation features were significantly improved in Safari 26. Is that the version you have?
Could you clarify if that's with or without JS?
I have not disabled JS or made any other configuration changes on this device. Entirely stock Safari and entirely stock MacOS.
That's not really believable. I'm starting to think this website isn't very reliable.
No, it's believable. All this website is communicating to us that most MacOS Safari installs look the same.
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.
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.
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.
It gets my correct timezone.
> 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?
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.
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”.
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."
I'm also on Debian 13 stable, that's definitely not what I get with JS. Weird.
Tor without JS is still subject to some degree of fingerprinting through CSS (media queries, caching) and tracking methods through mouse (without JS).
> and tracking methods through mouse (without JS).
How?
Hovering can trigger network request
You can even track people by favicon which bypasses incognito mode. Another part is hiding font urls in css with more tracking...
Was incognito mode ever meant to prevent tracking? I thought it was for porn, I mean buying surprise presents on a shared computer.
You're correct, incognito mode never has been for privacy protection from websites, ISPs, etc.
it's commonly used for checking how sites look when not logged in, without logging out, or logging in as another user temporarily.
While this was possible in the past, I believe it got patched and is impossible today.
Interesting, Chrome failed but Firefox and Brave "have strong protection against Web tracking."
In iOS embedded WebView: “strong protection against Web tracking”, and a fingerprint of ~20 bits.
A basic Brave install: "strong protection against Web tracking" / 18.58 bits
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.
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.
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.
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
>better portability across operating systems
Does Rust have better portability than C?
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.
It might have better abstractions over the current popular operating systems (Windows, Mac, Linux). Obviously not more portable in general.
Depends on what C code you are talking about.
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.)
> 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
I'm on a slightly older version than 10.12. I'm out of this limited support range. The problem is that as soon Apple cuts off older systems by heavy force all of the Mac developers running in circles like lemmings and cut off their projects from the older versions too: feeding right into Apple's policy to deprecate older systems for their own greed.
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.
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.
I still wish Mozilla had kept oxidizing Firefox. It would have been a net positive for Rust itself.
At least the Chrome team is still oxidizing.
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%).
Clearly, the fact that Servo failed must be indicative of shortcomings in Mozilla itself, and not Rust the language, its ecosystem, or its users.
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.
Did it fail? The servo project seems alive and well, just not under Mozilla. They decided CEO pay packages were more important.
> 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.
> 13 years to get to v0.0.1 is a success?
Wine took a roughly same amount of time to be versioned as well, but no one calls Wine a failure.
First, wine was widely panned for years before it stopped sucking.
Second, you're simply ignoring that parent poster mentioned Ladybird, a non-rust project which is advancing much more speedily than servo. And I think they have a valid point -- and while the jury is still out, it's possible that in other rust-centric efforts which have experienced foot-dragging (eg WASI), the root cause may be rust itself.
Parent poster expressed their point somewhat sarcastically, but if I (C++/python dev, I admit!) were a betting transfem, my money would be on them being right.
That said, I think the Tor project got this decision right. This is as close to an ideal use-case for rust as you can get. Also, the project is mature, which will mitigate rewrite risk. The domain is one where rust can truly shine -- and it's a critical one to get right.
i'd say that wine has much less dev effort and the specs they re up against aren't as public as the web ones, so huge kudos to the wine team.
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.
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++.
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.
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
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.
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.
> 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.
Obviously, C# is one of Microsoft's flagship language along with TypeScript.
So it's expected to be frequently mentioned there.
Sure, and Rust is the most used language for modern TS/JS tooling, outside of TS/JS. There would have been substantial ecosystem benefits had Rust been chosen.
Do you have a source for that?
Because esbuild is Go. tac was TypeScript and will be Go. Bun is Zig.
Come to think of it. I don't use a single Rust tool for the web. node is c++. deno breaks too much.
So, do you have a source for your claim?
Transpilers: SWC, Oxc Linters/Formatters: DPrint, deno lint, Biome, Oxlint, Oxfmt Bundlers: Rolldown (replacing esbuild in Vite), Rspack, Turbopack, and certain components of Parcel
All built with Rust
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.
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!
Sometimes language is a limiting factor and so you need to change languages before getting better. However this is rare.
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.
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.
Well, given that this has been going on for years, you can already start to empirically evaluate that question.
> (So far, it's a not-very-complete client. But watch this space!)
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.
The distribution I use already has limited security updates for Rust: https://www.debian.org/releases/trixie/release-notes/issues.... which reduces my security. The cargo supply chain issues are also very obvious, I am far more worried about this than I ever will be about memory safety, but hopefully tor reduces its reliance on random dependencies.
I find that surprising given that Debian breaks Rust programs up into individual apt packages, but ultimately, other distros do not have this issue. It’s also about userspace programs and not the kernel, which does not use external packages and so sidesteps this completely.
Debian forky has Rust in the kernel on by default.
I guess the want to be able to update individual libraries to provide security updates.
Right, from my understanding, Debian was packaging Rust programs in the same way as C ones. So they’d update the individual library and it should be all good. They deduplicated all of the dependencies in their trees.
This seems reasonable to me. If you have a tarmaggeedon, you update one library instead of thousand of packages. Although I am not sure how well this can work in Rust with monomorphization.
[flagged]
[flagged]
Do you think the sibling comment was flagged to "protect me" whatever that means, or is it because "Are you high on Prozac?" is not really a productive comment?
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.
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.
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.
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++.
Why? Monomorphization often leads to great results in microbenchmarks due to super-specialized code but also to bloat.
> 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?
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…
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.
He wrote it because he has eyes and has seen how the typical conversations about switching to Rust often go.
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".
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).
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.
"Another aspect to consider is that all garbage collected languages are memory safe."
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.
That's a great comment and I agree.
Even C programmers with decades of experience are having hard time writing safe programs in C. If that's not enough, I don't know what is.
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#
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-...
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.
I think companies hired too many Rust engineers, and now those engineers are writing technical blogs and making product decisions. We're seeing a lot of those everyday on HN first page
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.
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.
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.
FWIW, rust is great on a tiny embedded system.
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.
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.
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.
Tools like embassy really are great: https://embassy.dev/
But with no_std, Rust is not memory safe, even when not using unsafe. It does have pattern matching and modules, however.
> But with no_std, Rust is not memory safe, even when not using unsafe.
What makes you say that?
[flagged]
I don't know where I've lied about this, supposedly. Unless you say that, because of this implementation exception (which is based on target, not std vs no_std by the way) as meaning that "there's no UB in safe Rust" to be a lie.
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.
> For an example, if a function in no_std overflows, it can result in undefined behavior, no unsafe required. And stack overflows are easy in Rust, like they are easy in most other systems languages.
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.
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
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.
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.
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.
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.
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.
And of course, "impossible to refactor" just is very deep in the bullshit territory. "more fun to write new code" would probably be more honest, and the Rust proponents created a marketing narrative that allows them to do this while pretending (and probably also believing themself) to do a good thing.
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!)
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.
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.
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.
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.
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
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 :)
Yes, but let's not forget it's voluntary based. There are lots of high quality nodes, although less which are basically burning money and getting nothing in return. We all believe in a censorship-resistant and free web but only few are willing to take action. My two small guard/middle relays are rented at 10$/m each and is only 100Mbit/s non-metered up/down because it gets expensive.
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.
Nature just hasn't switched to Rust (and Arch) yet. Maybe it'll also get rid of those pesky black holes.
Plus TLS handshakes.
5 proxies does it even slower but would make attacks much more difficult.
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
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.)
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.
I think this shows a misunderstanding of the purpose of TOR. It’s for privacy, not optimal latency for your video stream.
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.
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)
Onions are extremely fast and for the level of anonymity they provide, it's an amazing advancement. It's surprising that Reddit has kept their onion in working condition given their poor attempts (a very bad TLS fingerprinting for all redlib instances) recently to shutdown redlib instances.
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.
> Tor browser team doesn't want to for simple reason: fingerprinting.
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.
As much as I agree with it, they see it as another maintenance headache and unnecessary attack surface. NoScript is the only extension which they've been shipping since quite a while.
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...
>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.
> 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).
>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/
[dead]
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.
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.
How is 3 so much better than 2, but 4 not so much better than 3?
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.
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.
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.
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.
That reminds me of the holy Handgranate of the Monty pythons
The right number for you to use is the default. But the right default is not necessarily 3.
because then there is at least one node that knows neither the source nor the destination of a request
The law of diminishing returns
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.
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...
The setting doesn’t exist.
Your config improvement made it into Google AI https://i.imgur.com/v5DsXy9.png
If this is sarcastic you should probably add /s or someone might actually follow your "advice".
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.
Yeah I was confused! Pretty sure this is not configurable.
Or people should not be idiots and think for themselves just a smidge, and not use /s.
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.
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?
It would shifts part of the data route info from your provider toward that particular relay.
But I wouldn't recommend it of course.
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.
> 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.
> 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.
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.
[flagged]
I literally said on here two days ago that I thought that in the past the Project was hostile to gccrs: https://news.ycombinator.com/item?id=46219460
I have been a fan of gccrs the entire time.
> Yet you are wrong
Ahh here you are speaking nonsense again. We ain't talking formal logic, we're speaking human to human
> 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 (or "lie" as I'm sure you'd term it), 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 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.
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.
I've written C++ for 15 years. It's the language I have the most experience with. And yes, pattern matching is a must, particularly for any language that has sum types.
This was mostly funded by Zcash Community Grants. Good things can come from crypto R&D.
Pecunia non olet
I think perhaps cryptocurrency is worse than selling urine for its chemical properties, but the principle applies, money is just money
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.
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/
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/
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
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.
Isn't Tor a concept, a protocol? It's like saying you're going to rewrite http in rust...
Onion routing is the protocol. Tor is the network and the name of the reference implementation.
It's a product. You can download and implement it's many components.
No.
i'm starting to wonder what if those rust rewrites might be covert attempt to introduce back doors in plain sight?
Rust - "I am inevitable"
"And I... am the Oxidized Man."
[snaps fingers]
Unless you use aluminum or stainless steel...
Rust never sleeps.
N. Young
young and rustless ?
Rust in peace
They should just start compiling Tor with Fil-C — free memory safety, no new bugs from full code rewrite
This move started before Fil-C existed.
[flagged]
It did look like that ever since an NSA critical Tor developer got canceled using the same methods as against Assange.
I suppose soon we'll get nsa-leftpad from cargo as a dependency among 347 other packages.
What was the parent comment?
[dead]
Why not Go? It's more portable.
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.
>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!
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...
Not under OpenBSD i686.
Also, the more heterogeneous it's a CPU architecture support, the least exploitable a service will be.
Please elaborate on your last point.
See? This is exactly my point. The last 32-bit only Intel CPUs were the original Intel Core series. Core 2 was already 64-bit, and it was released in 2006.
i686 should have died a long, long time ago.
No, the last 32-bit-only Intel CPUs were Atom models in ... I think we decided 2011 last time this came up.
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.
Because:
1) Development resources are finite.
2) Linux runs all of the world supercomputers, most of the internet infrastructure (server, routers, etc), most of the cellphones (Android), and lots of other things. Its global marketshare is way bigger than macOS and all the BSD put together.
To remain clear: This is largely devil's advocate. I believe that niche platforms generally should be supported, and that includes GNU/Linux on amd64, and NetBSD on literal VAX (yes, that is an officially supported platform in current NetBSD), and RedoxOS on ARM, and OpenBSD on MIPS, and [...]. I just think it's really weird to claim that GNU/Linux, with 3% of the desktop market, should be supported, but a platform that is similarly a small fraction of Linux is dead weight that should be dropped.
With that said, remainder of this comment continues with the position that GNU/Linux, which I am writing this comment on, is obviously not worth supporting for the same reasons as i.e. MIPS and RISC-V.
> 1) Development resources are finite.
That is an argument in favor of cutting niche platforms like GNU/Linux.
> 2) Linux runs all of the world supercomputers,
You can't defend a niche OS by pointing out that it's used in a tiny niche market. How many supercomputers exist on earth? I'd bet you there are more working MIPS installations than supercomputers.
> most of the internet infrastructure (server, routers, etc),
I'll grant you headless machines used by IT folks, but that's still a specific subset of the market and it has little bearing on whether, say, Tor should support it as a desktop OS.
> most of the cellphones (Android),
Android/Linux is quite different from GNU/Linux; effectively nobody developing for Android is targeting Linux in any meaningful sense.
> and lots of other things. Its global marketshare is way bigger than macOS and all the BSD put together.
Only if we include embedded systems and servers. If you intend to target servers, then yes obviously Linux matters. Otherwise, not so much.
Try living without OpenSSH and the rest of *BSD contributions.
Linux is not an ISA
So? They're both part of the platform software has to target.
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.
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.
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.
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.
Golang doesn't dynamically link to libc by default on Linux either - it calls the Linux kernel ABI directly (since that ABI is stable). The main upshot of this is that you don't have to worry about the classic glibc version bingo by default, while with Rust you have to go through some extra steps to avoid that.
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.
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.
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)
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.
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...
No Rust under OpenBSD i686. Rust on PowerMacs? Alpha?
Probably because:
- better data race handling;
- no garbage collection, more predictable performance;
- stricter type system that can enforce constraints better;
- closer to metal and better FFI support.
Which seems to matter more for Tor project than support for some barely used platform.
This is legit question, especially for Tor binaries.
Advantage of Rust (or original C implementation) is for users that do not have runtime and want to import Tor libraries (like arti-client) in their code. Go could work but those unmanaged languages are better here. So in the end Rust (or C, C++ etc.) can serve more user-cases.
and easier to learn.
and better funded.
and easier to find devs.
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
> 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.
Go been around for quite a while now. It isn't going anywhere.
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
I didn't like Rust one bit and gave up learning it. Go on the other hand is quite nice.
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/
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.
https://killedbygoogle.com/
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
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.
Complete rewrites are always a bad idea ... [mutters of agreement] ... except in Rust! [cheering]
Complete rewrites have been done before. They're not impossible tasks. C to C++ (like with fish), C++ to Rust (fish again, Tor, etc), Java to C# (something I've seen), C# to C++ (evernote), Blender Game Engine to Godot (many small cases), Godot to Lumberyard (something I've seen), Unity to Godot (many small cases), etc. And there are all the myriad rewrites within the same language, or across major breaking changes (like Python 2 to Python 3).
I think "you should never do a full rewrite" is something of a reactionary response to the juvenile idea new devs and interns get every now and then. But sometimes, a rewrite really is a good idea.
But in this case, per the announcement ( https://blog.torproject.org/announcing-arti/ ), the reasons are pretty convincing. The major reasons are, unsurprisingly, all around memory safety.
> Godot to Lumberyard Do you remember what project(s) this was? I'd be super curious on the motivations of the developers. I guess I could see it when it first went open source and Godot wasn't all it was today.
It was a project I worked on as an intern at Electric Boat. I can only speak to specifics I was explicitly given the okay to share though (i.e. this is all on my LinkedIn).
The project was a virtual training simulation for a submarine cockpit, first in Blender Game Engine. With support for BGE being deprecated, I was tasked to find an alternative engine and to port the work. (I'm very proud my research pointed to Godot- this was during the Godot 2 era).
There was a lot of interest in the project, but my internship was coming to an end and they decided to port it to Amazon Lumberyard for fear of Godot's longevity and support. They didn't want to be left "waiting for Godot". The final task I took on was to document the project, to make that transition easier for whoever came next.
The issue is that every other week there is a rewrite of something in Rust. I just do an eyeroll whenever I see that yet another thing is being rewritten in Rust.
I've tried compiling large projects in Rust in a VM (8GB) and I've run out of memory whereas I am sure a C/C++ large project of a similar size wouldn't run out of memory. A lot of this tooling I had to compile myself because it wasn't available for my Linux distro (Debian 12 at the time).
A lot of the tooling reminds me of NPM, and after spending a huge amount of my time fighting with NPM, I actually prefer the way C/C++/CMake handles stuff.
I also don't like the language. I do personal stuff in C++ and I found Rust really irritating when learning the language (the return rules are weird) and just gave up with it.
> whereas I am sure a C/C++ large project of a similar size wouldn't run out of memory
This is a common issue on large C++ projects for users with limited resources. You typically have to tinker with build settings and use a different linker etc.. to get the project building without OOMing.
> A lot of the tooling reminds me of NPM
My feeling is that you'd have the same criticism about a lot of other modern ecosystems because they allow you to pull dependencies easily. With things like vcpkg, that's also possible in C++ but even without it: nothing stops the same behavior of importing "random" code from the internet.
A lot of the modern tooling feels like a rube goldberg machine when it goes wrong. If you are forced (like I am) because of byzantine corporate rules to use older version of said tools, it is extremely painful. Don't get me started on stuff like babel, jest, ts-jest and all that gubbings. AI been a godsend because I can ask Claude what I want to do.
I use vendor directory in my C++ project and and git submodules and I've got a build that works cross platform. The biggest issue I ran into was MinGW and GCC implement the FileSystem library differently (I don't know why). It wasn't too difficult to fix.
To be fair, you haven't explained why it's an issue to see projects being rewritten in Rust, other than it is a bit annoying to you?
For me, I had a very good experience rewriting a project in Rust (from Python). It was just an improvement in every regard (the project was easier to build and distribute, it was a good opportunity to rearchitect it, and the code ended up 20k times faster.) So, I have the opposite feeling when I see titles like these.
I also feel the opposite about the tooling. For me, cmake, npm, pip, maven, etc. all live in this realm where any invocation could become a time purgatory. The big thing that makes me like Rust is that I've never had that experience with cargo. (In fact, pip was the primary motivation to move away from Python to Rust. Everything else was just nice.)
I'm not saying this to convince you to feel otherwise, I just wanted to offer how I felt about the same topics. I grew up with C and Java, but Rust clicked after I read SICP and followed along in Racket. I could probably fill a page of small grievances about Rust's syntax if I had to.
Rewriting stuff is largly a waste of time unless the underlying design/product is flawed. You are going to have to solve the same challenges as before but this time in Rust.
Anyone that been on a "rewrite" knows that often the end result will look like the previous implementation but in <new thing>.
So what I see is a lot of development effort to re-solve problems that have already been solved. I think Ubuntu did this with the core-utils recently (I don't keep up with the Linux dramas as there is a new one every week and tbh it isn't interesting a lot of the time). They ended up causing bunch of issues that I believe were already fixed years ago.
There are issues with things in Linux land that have been issues for years and haven't been resolved and I feel that development effort would have probably been better spent there. I don't pay canonical employees though, so I guess I don't get to decide.
> A lot of the tooling reminds me of NPM, and after spending a huge amount of my time fighting with NPM, I actually prefer the way C/C++/CMake handles stuff.
I guess you and me live different lives because I have spent far more time messing with ancient C/C++/CMake/Automake/Autoconf/configure/just have this particular .so file in this particular spot/copy some guys entire machine because this project only builds there/learn and entirely different language just to write build files (CMake sucks and 5 other alternatives are just lipstick on a pig) etc. etc.
I am of the opinion that half of Rusts success is based on that fact that C/C++'s tooling is annoying and ancient. People want to write code not mess with build envs.
The issue you are describing isn't an problem with C/C++ tooling. It is to do with how the developer dealt with dependencies i.e. poorly. BTW this happens in any language if they do that. I've had to deal with some awful C# code bases that would only compile on one guys machine.
I am a hobbyist C/C++ developer and have a intermediate size code base that builds on Linux, Windows (MinGW and MSVC) and MacOS and I didn't do anything particularly special. What I did do is setup CI early on in my project. So I had to fix any issues as I went along.
Sure. That doesn't matter. Of course you can keep writing your C/C++ or using CMake, nobody is going to stop that. But other people's project are not going to stop adopt new tech stack because how you feel about it.
> That doesn't matter. Of course you can keep writing your C/C++ or using CMake, nobody is going to stop that.
What it is going to cause is having to learn a bunch of new tooling which I have to somehow to get behaving on my Debian box, because a particular tool that I will need to compile from source will have a bunch of Rust dependencies.
I've already run into this BTW, where I wanted to compile something in Rust and it needed a third party task runner called "just". So I then needed to work out how to install/compile "just" to follow the build instructions.
Why they needed yet another task runner, when I am pretty sure make would have been fine, is beyond me.
> But other people's project are not going to stop adopt new tech stack because how you feel about it.
I don't expect them to. That doesn't mean I can't comment on the matter.
RE: memory, any self-respecting CI/CD system will allow you to compile any Rust project without out-of-memory halts.
RE: NPM, you have a right to a preference of course. I certainly don't miss the times 20 years ago when pulling in a library into a C++ project was a two-week project in itself. make and CMake work perfect right up until they don't and the last 2% cost you 98% of the time. Strategically speaking, using make/CMake is simply unjustified risk. But this is of course always written off as "skill issue!" which I gave up arguing against because the arguers apparently have never hit the dark corners. I have. I am better with Just and Cargo. And Elixir's mix / hex.
What you like as a language (or syntax) and what you roll your eyes at are obviously not technological or merit-based arguments. "Weird" I can't quite place as an argument either.
Use what you like. We all do the same. The original article lists good arguments in favor of Rust. Seems like a good case of "use the right tool for the job" to me.
> RE: NPM, you have a right to a preference of course. I certainly don't miss the times 20 years ago when pulling in a library into a C++ project was a two-week project in itself. make and CMake work perfect right up until they don't and the last 2% cost you 98% of the time. Strategically speaking, using make/CMake is simply unjustified risk. But this is of course always written off as "skill issue!" which I gave up arguing against because the arguers apparently have never hit the dark corners. I have. I am better with Just and Cargo. And Elixir's mix / hex.
I've lost countless hours having to get the rube goldberg machine of npm, jest, typescript, ts-jest and other things to work together. In contrast when I was learning OpenGL/Vulkan and general 3d programming, I decided to bite the bullet and just do C++ from the start as that was what all the books/examples were in. I had been told by countless people how hard it all was and how terrible the build systems were. I don't agree, I think the JS ecosystem is far worse than make and CMake. Now I am already an experienced programmer that already knew C# and Java, maybe that helped as they have many of the same concepts as C++.
Now I did buy and read a book on CMake and I did read the C++ 11 book by Bjarne Stroustrup (I found it second hand on ebay I think).
> What you like as a language (or syntax) and what you roll your eyes at are obviously not technological or merit-based arguments.
They aren't. What I am trying to convey is that it feels like a lot of things are done because it is the new shiny thing and it is good for resume/CV padding.
> "Weird" I can't quite place as an argument either.
The return keyword is optional IIRC in some circumstances. I think that is weird. I think I stopped there because I just wasn't enjoying learning it and there are zero jobs in my area of it.
> Use what you like. We all do the same.
The issue is that I think it (Rust) is going to worm it way everywhere and I will be forced to deal with it.
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.)
> 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.
I don't understand why many people on here say "humans", instead of people. It sounds like you are talking as if you are a grey alien on a space ship somewhere.
What you are complaining about is abuse of tools/language features. This can happen in any language and/or tools.
That doesn't mean the tool itself is bad.
> Help me understand the actual technical criticism buried in the "worm its way everywhere", please. And in the "it's good for CV/Resume padding" statement as well.
They are self explanatory. I don't like it when someone does this stupid game of not understanding common idioms.
> It's a strange thing to say and it smells like a personal vendetta which is weirdly common on HN about Rust and to this day I have no idea why even though I have asked many people directly.
It isn't. What typically happens is that a tool lets call it "Y" get used everywhere to the point where you cannot use "X" without "Y".
Ruby used to get used for CV padding. I used to work in a Windows/.NET shop and someone wrote a whole service using Ruby on Rails in a Suse Linux. That person left and got a job doing Rails shortly after.
> Rust has objective technical merits and many smart devs have documented those in their blogs -- journeys on rewrites or green-field projects, databases, network tools (like OP), and even others. Big companies do studies and prove less memory safety bugs over the course of months or years of tests.
Just because <large company> does something and says something is true doesn't mean it is or is suitable for everyone or it is actually true.
I have worked at many <large corps> as a contractor and found that the reality presented to the outside world is very different to what is actually happening in the building.
e.g.
I was working at a large org that rewrote significant portions of their code-base in new language instead of simply migrating their existing code-base to a new runtime.
I made plenty of money as a contractor, but it was a waste resources and the org lost money for 3 years as a result.
BTW they never fully transitioned over to the new code-base.
Company blogs and press releases will say it was a success. I know for a fact it wasn't.
> The Linux kernel devs (not unanimously) have agreed that Rust should no longer have experimental status there recently -- and people are starting to write Linux drivers in Rust and they work.
So I will need any additional toolchain to build Linux drivers. This is what is meant by "worming its way in". I have done a LFS build and it takes a long time to get everything built as it is.
> I am honestly not sure what would satisfy the people who seem to hate Rust so passionately. I guess it announcing full disband and a public apology that it ever existed? Yes this is a bit of a sarcastic question but really, I can't seem to find a place on the internet where people peacefully discuss this particular topic.
You are making assumptions that I hate Rust. I don't. I just don't care for it.
What I do hate is hype and this constant cycle of the IT industry deciding that everything has to be rewritten again in <new thing> because it is trendy. I have personally been through it many times now, both as an end user and as a developer making the transition to the <new thing>.
You are kind of ranting on general trends here, not to mention misrepresenting what I said which I cannot see as arguing in good faith (never said that big companies using something makes it good; I said that they did studies -- that's absolutely very much not the same as many other types of cargo culting that they do which I'll agree is never credible).
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.
> You are kind of ranting on general trends here, not to mention misrepresenting what I said which I cannot see as arguing in good faith (never said that big companies using something makes it good; I said that they did studies -- that's absolutely very much not the same as many other types of cargo culting that they do which I'll agree is never credible).
I didn't misrepresent anything you said. You misunderstood what I said. I said companies will claim all sorts of things and the reality behind the scenes is very different. Having a study is one form of making claims. What works at one company may not work at another.
> I am not pretending to not understanding anything as well by the way,
Yes you were. What I said was plainly obvious.
CV driven development is a well known and understood phenomenon.
Technology stacks being subverted is a well known and understood phenomenon.
It is very annoying when people pretend not to understand basic idioms. It is a dishonest tactic employed by people online, I've been online now since the late 90s and have seen it done many times. You are not the first and won't be the last.
> I was trying to find objective technical disagreements and still can't find any in your reply.
I gave you them. Several in fact.
Part of engineering is understanding that resources aren't infinite and you have to make trade offs. So how resources (money, time, man power, compute) is used is technical. I make calls all the time on whether something is worth doing based on the amount of time I have.
This is often discussed on many blogs, podcast and books about software engineering.
What you want to do is narrow discussion down to the sort of discussion "well they found they found X more bugs using Y technique". Ignoring the fact that they may had to spend a huge amount of man power to rebuild everything and created many more bugs in the process.
> I am seeing a bit of curmudgeon-ing on several places though, so I am bowing out.
Yes I am disillusioned with the industry after working in it for 20 years. That doesn't invalidate what I say.
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.
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.
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.
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.
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.
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.
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.
Opinions with “always” in them are always a bad idea.
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.
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.
It is intended. Like any other US gov funded projects.
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.