The Tor Project is switching to Rust

I still wish Mozilla had kept oxidizing Firefox. It would have been a net positive for Rust itself.

Clearly, the fact that Servo failed must be indicative of shortcomings in Mozilla itself, and not Rust the language, its ecosystem, or its users.

At least the Chrome team is still oxidizing.

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.

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.

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

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%).

> 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.

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.

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.

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++.

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.

> 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.

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.

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.

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?

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.

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