The Tor Project is switching to Rust

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.

But with no_std, Rust is not memory safe, even when not using unsafe. It does have pattern matching and modules, however.

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.

> But with no_std, Rust is not memory safe, even when not using unsafe.

What makes you say that?

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.

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.

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

Tools like embassy really are great: https://embassy.dev/