Hacker News Reader

Comment by ringzero | Hacker News Reader

Just a point of clarification that I found helpful - the patches offered to correct soundness problems, in this case, didn’t significantly impact performance. Your hypothetical still stands, but it’s not necessarily a huge trade off.

View on HN

What about Actix's use of unsafe code in general? In most of the TechEmpower benchmarks Actix seemed to dominate, beating not only the other Rust frameworks but even C++. This is not because of a correlation between the use of unsafe and increased performance?

Not really, no. Most of Actix's unsafe code was unnecessary, and had largely been replaced with equivalently performant safe code over a long series of unpleasantly adversarial patches leading up to the final debacle. Much of the ire directed at the maintainer grew out of an impression that the maintainer was using unsafe to cut corners instead of finding alternative safe solutions. I believe that at the time of project's deletion it had only low 10's of remaining uses of unsafe.

That's quite unfortunate then, the ecosystem losing its fastest web server because of its use of unsafe when the use of unsafe wasn't even necessary for performance.

Well, “the community” is not as a whole happy about the outcome or the way this issue was handled in any way shape or form. I think Steve did a really good job of articulating the undercurrent behind this.

People should be allowed to be free of harassment. I think everyone would have been better off in this case if the individuals who were so concerned about the unnecessary safety, forked Actix and had a SafeActix, that was maintained without the usage they were concerned about.

If the maintainer isn’t going to accept your patches, then it’s time to decide how to move forward without needing to resort to harassment.

Reply on news.ycombinator.com