I've suspected for a long time that Rust would prove to be a faster language than C++ once it was done, but only as the code scales up. On a line-by-line basis, the two languages are comparable, so microbenchmarks will never show it, but Rust will tend to very, very strongly encourage better architectures that require you to do less copying just to be safe. It's really hard to measure "architectural affordances", though... heck, it's hard to even define them, let alone benchmark them.

OpenSSL has been optimized extensively, so I consider the fact that any hobbyist project with a fraction of the resources able to beat it by that much to be significant in a way that, say, beating "some guy's github json parser" isn't. If I were going to temper my excitement, though, what I'd want is to make sure the Rust implementation isn't unknowingly trading away important security considerations to get that speed, such as whatever constant-time operations may be necessary or guarantees about when the key will be destroyed or whatever. I have no concrete knowledge about that in this specific case, but in a security context it is something I'd want to check in general. OpenSSL has had its stumbles, and the architecture is... debateable, especially when binding to it in a non-C language... but it has also been reviewed a lot, and battle-tested, and a lot of other things this little library just hasn't been yet. (Not because of any deficiency of the library, author, or language, but just, something things can only come from time and scale.)

Rust already beat C in the benchmarks game

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

That boxplot shows both the C and the C++ programs ahead of the Rust programs, so why do you say "Rust already beat C" ?

That's not how I read the title. I think it's impressive that it's faster despite being written in Rust.

Maybe Rust also makes it easier to write fast code (I couldn't say one way or another), but it's great that you at least don't need to sacrifice performance on the altar of safety.

I’m generally positive on rewriting openssl in rust, but agree the comparisons aren’t completely scientific or necessarily more important than correctness. First you should compare performance using the same implementations of cryptographic primitives as these are relatively easily fungible. We also don’t know if for example OpenSSL optimised primitives were used. Secondly the rust language only excludes memory bugs, it doesn’t exclude errors in the implementation of the tls protocol or incorrect usage of cryptographic primitives which can be just as catastrophic for security. These have been prevalent in OpenSSL and are somewhat harder to prevent a priori. For all we know these issues are worse for rustls than OpenSSL. This is where formally verified implementations would be useful.

> Secondly the rust language only excludes memory bugs, it doesn’t exclude errors in the implementation of the tls protocol or incorrect usage of cryptographic primitives which can be just as catastrophic for security.

I linked to a talk about the project elsewhere and it's worth noting that the author of rustls leverages a lot of rust techniques that ensure certain correctness attributes at a semantic level, not just memory safety.

In particular, TLS libraries have long suffered from dealing with the complex composite state machines required by the protocol[0]. Rust makes the expression of safe state machines pretty easy (the talk demonstrates how).

[0]https://www.mitls.org/pages/attacks/SMACK

Crypto libraries is a domain where the advantages of Rust are very important. You need really good performance, and you need really good safety guarantees. Rust is relatively unique in being able to deliver both of those as well as it does.

There are probably a lot of reasons why it's faster, and at least some of those are about rust, and some definitely aren't.

https://www.youtube.com/watch?v=aHMRFZkXq4Y

Here's a good talk about the project. Some of the patterns the author uses are sort of hard to do in other languages (such as pattern matching on composite states).

People do good things with rust. Therefore rust is a good programming language.

Could someone have done this particular good thing in another language? Absolutely. But that's not very relevant.

> Could someone have done this particular good thing in another language? Absolutely

While this is true for many other tasks, I don't think there exists any other programming language that fits so well for safe and efficient protocol implementation (where experimentation speed is not that important)

Given enough time and resources someone could do equivalent work in assembly. The point of Rust is that it should take you less time and resources to do so.