5 ms·
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 "
by dingdingdang 10mo ago
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!
- staticassertion 10mo agoIsn'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.
- morkalork 10mo agoIs 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.
- uecker 10mo agoIt 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.
- steveklabnik 10mo agoWell, given that this has been going on for years, you can already start to empirically evaluate that question.
- yjdiquhf 10mo ago> (So far, it's a not-very-complete client. But watch this space!)
- steveklabnik 10mo agoYes, 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.
- yjdiquhf 10mo ago[flagged]
- ue7gjelwjd 10mo ago[flagged]
- steveklabnik 10mo agoDo 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.
- uecker 10mo agoThe distribution I use already has limited security updates for Rust: https://www.debian.org/releases/trixie/release-notes/issues.en.html#go-and-rust-based-packages 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.
- classicasp 10mo agoI 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.
- gldrk 10mo agoGiven 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++.
- uecker 10mo agoWhy? Monomorphization often leads to great results in microbenchmarks due to super-specialized code but also to bloat.
- Yoric 10mo ago> 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?
- bluGill 10mo agoSometimes language is a limiting factor and so you need to change languages before getting better. However this is rare.