[ivraatiems]

Calling Rust "a C/C++ replacement" is, I think, slightly underselling what it's supposed to do. As I understand it, the goal of Rust is more "take all these things that were historically hard to do safely and make them easier to do safely" than "replace C/C++ 1 for 1".

[DSMan195276]

Is it actually achieving that goal though if the advice is "use C if you have to do `unsafe` stuff"? That's really my point. IMO the language was always intended to be able to be used in any situation C is used (with maybe a few exceptions), which includes situations where `unsafe` is necessary.

[smoldesu]

For starters, the example I gave (Actix framework) had no such situations where unsafe code was imperative to having it function. That's where the drama originated from there.

Secondly, I don't think the goal of Rust is to rewrite the entire kernel (or replace C/C++ for that matter). Rust is optimized around writing ergonomic, safe code. It's compiler is designed to produce high-performance binaries with minimal UB. Sure, they could designate a team for making the unsafe Rust experience better, but why bother? C++ already does that and does it well. The idea of "oxidation", or slowly replacing safety-critical portions of a program in Rust, doesn't necessitate fully replacing any of the languages that came before it, and while there are situations where unsafe code is undeniably necessary, I don't really think there's much of a reason to replace C or C++ for those uses. Any of the replacements you could write in Rust wouldn't be ergonomic, easy to read or well optimized.

[DSMan195276]

I feel like you're ignoring the actual history here, these are a few excerpts from right before the 1.0 release of Rust[0]:

> Rust has remained true to its goal of providing the safety and convenience of modern programming languages, while still offering the efficiency and low-level control that C and C++ offer.

> When used in its own most minimal configuration, it is even possible to write an operating systems kernel in Rust.

> The resulting design is not only simpler to learn, but it is also much "closer to the metal" than we ever thought possible before. All Rust language constructs have a very direct mapping to machine operations, and Rust has no required runtime or external dependencies.

They do actually have a group working on making `unsafe` better, so they do somewhat recognize the problem (I'm not sure about the results, but the last time I looked at it was probably over a year ago): https://github.com/rust-lang/unsafe-code-guidelines

Perhaps another catch is that, at least in my experience, the most common situation where `unsafe` can into play is interop with other languages/libraries/etc.. Some of it is avoidable, but a certain amount of it is necessary just be able to interface with existing non-Rust code, so it's not really optional in those situations.

Also, just to be clear, I do actually like Rust, and I've written a few different things in it. I just think the state of `unsafe` is poor to the point that it's very hard to determine if you're doing something correctly, which in my opinion makes unsafe unusable for its purpose.

[0]: https://blog.rust-lang.org/2014/09/15/Rust-1.0.html

Edit: To be clear, I'm not attempting to defend Actix, that was silly. I'm just talking about situations where unsafe is unavoidable, which really covers a lot of potential usages of Rust.