[staticassertion]

I think that the premise here is correct - writing unsafe Rust is too hard. There are lots of footguns.

This isn't a very good motivating example but I suppose it does the job of showing the various hoops one has to jump through when using unsafe.

I think right now the approach is to make unsafe "safe" (ie std::mem::uninitialized -> MaybeUninit) at the cost of complex, and eventually to build out improved helpers and abstractions. Obviously this is still ongoing.

But also, just don't write unsafe? It's very easy to avoid.

[smoldesu]

> But also, just don't write unsafe? It's very easy to avoid.

Yeah, there's a weird subset of developers who insist on mixing unsafe and safe code even when they're presented equally performant, safe alternatives. One such example was the Actix framework, where the lead dev refused to merge any fixes for his unsafe code. Eventually, so many merge requests showed up to fix his broken code that he just gave up the project altogether and let the community take over.

If you want to write unsafe code, I think that's perfectly fine, but Rust is not going to cater to your desires. C and C++ will give you the tools you need with the conveniences you want.

[DSMan195276]

> If you want to write unsafe code, I think that's perfectly fine, but Rust is not going to cater to your desires. C and C++ will give you the tools you need with the conveniences you want.

This is a bit of a odd suggestion to me, honestly, you're basically saying Rust is not intended to be a C/C++ replacement. There is definitely a reality that not everything can be written in completely safe Rust, and a lot of the places that Rust could be the most beneficial (Ex. Linux Kernel) are going to require using it.

[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.

[queuebert]

When I want to write unsafe Rust code, I usually find it easier just to use C. The whole purpose for Rust in my work is to be safe.