←back to thread

The Tor Project is switching to Rust

(itsfoss.com)
348 points giuliomagnifico | 3 comments | 12 Dec 25 12:35 UTC | HN request time: 0.672s | source
Show context
epolanski ◴[12 Dec 25 12:55 UTC] No.46243675[source]▶
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.

replies(8): >>46243722 #>>46244465 #>>46244778 #>>46245023 #>>46245269 #>>46245325 #>>46246309 #>>46250138 #
GuB-42 ◴[12 Dec 25 15:28 UTC] No.46245023[source]▶
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.

replies(1): >>46245428 #
hgomersall ◴[12 Dec 25 16:06 UTC] No.46245428[source]▶
FWIW, rust is great on a tiny embedded system.
replies(2): >>46245494 #>>46245897 #
udhghhe ◴[12 Dec 25 16:12 UTC] No.46245494[source]▶
But with no_std, Rust is not memory safe, even when not using unsafe. It does have pattern matching and modules, however.
replies(1): >>46245932 #
1. estebank ◴[12 Dec 25 16:53 UTC] No.46245932[source]▶
> But with no_std, Rust is not memory safe, even when not using unsafe.

What makes you say that?

replies(1): >>46246986 #
2. estebank ◴[12 Dec 25 18:34 UTC] No.46247150[source]▶
> 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.

3. steveklabnik ◴[12 Dec 25 18:57 UTC] No.46247403[source]▶
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.