[classicasp]

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

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

Why? Monomorphization often leads to great results in microbenchmarks due to super-specialized code but also to bloat.

[Yoric]

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