I agree, I started Rust before this drama (I wouldn't call that an _issue_, it was the whole culture that goes wrong here), now peoples try to understand why you need unsafe, but it hasn't been the case and for _years_ it was almost impossible. actix-web is the pivot point but the simple fact you need a sad situation like this show how crazy the safety discussions were before, really.
Once again: Things are changing and I'm more than happy to see pragmatism in the Rust community. But you can't behave like all of this didn't happens.
> Sometimes the unsafe patterns we bring with us just don't match the Rust model.
I agree and noticed this too in some cases (compiler does miracles), that's why discussions have to be serious.
I think that was always the case. actix is a singularly unique example, and I had never seen anything like it before or since. Not even close. There just hasn't been any Rust project with that kind of popularity that also contained egregiously unsound code. So we're not just talking about unnecessary use of unsafe here, but egregiously unsound usage of unsafe.
The attitude toward 'unsafe' has pretty much always been the same. Use it. It exists for a reason. But make sure it's justified and strive for soundness.
There will always be outliers, but I actually think the Rust community has done a really great job around discussing unsafe in the years since the actix-web issue. See a really great discussion at: https://www.reddit.com/r/rust/comments/we91es/good_example_o...
Just some anec-data, but I had some benchmark code which was unsafe (indexing into an array of bytes, no UTF8 validation), that I wanted to rewrite as safe (by leaning on the std lib, so plenty of unsafe under the hood) just to see how much slower it would be, and the code ended up being ~20-30% faster. Sometimes the unsafe patterns we bring with us just don't match the Rust model.