This seems to be a case of mismatched expectations.
Many want Rust to save us from our current nightmare hellscape of vulnerability-ridden foundations.
So actix-web comes along-- a Rust web framework that is faster than everything else including the C and C++ frameworks-- and people are filled with hope. It's fast and safe, right?
But the actix-web maintainer says he built actix-web just for fun and to see how high he could get in the TechEmpower benchmarks. So he took license to use a lot of unsafe Rust code to improve speed. He apparently was not trying to make the world's best web framework, one that is safe and fast. Just one that is fast. Oops, expectations busted.
Everyone is to blame. No one should believe that all Rust code is perfectly safe, and we need better ways to know which Rust crates are trustworthy. And the actix-web maintainer could have taken more responsibility for setting people's expectations that the project prioritized speed above security.
I love the Rust Book by Steve Klabnik and Carol Nichols. But I think Steve is off base in this post when he implies that Davidoff is wrong about unsafe code increasing a library's security risk. Of course unsafe poses a risk. Of course it's legit to avoid libraries with lots of unsafe code, especially unnecessary unsafe code. Actix-web was taking a lot of risk, more than people expected.
I do think it's legit to avoid libraries with a lot of unsafe code. I myself started avoiding actix after these situations. If folks had simply stopped using it, that would have been a fine outcome here. That's not what happened though.
I am not a Rust guy (yet?). Are safe and super fast mutually exclusive? As I reas the article I sensed your explanation was probably the case. Did the many safety-making patches cause the performance to go down?
Not so much mutually exclusive as "safe, fast, easy, pick two", at least sometimes. It can take a lot of design effort to come up with a safe and efficient way to do some things, so it's often tempting to do something unsafe and efficient and hope it works out.
Many want Rust to save us from our current nightmare hellscape of vulnerability-ridden foundations.
So actix-web comes along-- a Rust web framework that is faster than everything else including the C and C++ frameworks-- and people are filled with hope. It's fast and safe, right?
But the actix-web maintainer says he built actix-web just for fun and to see how high he could get in the TechEmpower benchmarks. So he took license to use a lot of unsafe Rust code to improve speed. He apparently was not trying to make the world's best web framework, one that is safe and fast. Just one that is fast. Oops, expectations busted.
Everyone is to blame. No one should believe that all Rust code is perfectly safe, and we need better ways to know which Rust crates are trustworthy. And the actix-web maintainer could have taken more responsibility for setting people's expectations that the project prioritized speed above security.
I love the Rust Book by Steve Klabnik and Carol Nichols. But I think Steve is off base in this post when he implies that Davidoff is wrong about unsafe code increasing a library's security risk. Of course unsafe poses a risk. Of course it's legit to avoid libraries with lots of unsafe code, especially unnecessary unsafe code. Actix-web was taking a lot of risk, more than people expected.