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!

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…

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

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

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

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