The things that unsafe enables are arbitrary pointers, FFI, and accessing union members in a C struct. It seems highly unlikely to me that unsafe would fix any beginner's problem.
reply.clone() on the other hand is indeed an easy/quick fix for a lot of issues you'd face when learning rust.
I think beginner programmers are unlikely to use unsafe when learning rust but people coming from c or c++ who are beginners at rust might use unsafe all over the place.
replyExactly - we have been using C or C++ for decades and most of us have a lot of experience. We think like programmers in the languages meaning we often do things that Rust won't allow without unsafe. A small percent of the time that is the right thing (which is why Rust have unsafe), but very often there is a Rust way that is just as performant if only we knew how to think like Rust programmers.
replySadly it still feels like it's one of the languages where the language doesn't trust you, it tries to force you to do things "the right way". I do love quite a few of its design like how traits are, not forcing every method into the declaration, and the standard library is much less crazy than the C++ version.
replySadly, other things a bit less so - the story for the thin battery-less stdlib + npm-style churn encourages bloat, and the semantics are obsessed with safety at a heavy cost to productivity unless you spam clone() and reference-counting - but then your program becomes slow, kind of negating the advantages, you might as well have written it in C# or something...
Most of the time the rust way is just as good, just different.
replyYeah it doesn’t trust you, and for good reason the decades of developers making the same mistakes over and over again. If everyone was perfect you wouldn’t need Rust, but no one is perfect and that’s why Rust exists.
replyYes, but this this is not a problem at all because any bug caused by misuse of unsafe (or unwrap) is entirely the fault of the programmer (or the AI) and not of Rust. /s
reply