A very old discussion where Rust's syntax was heavily in flux, so that ship has probably sailed ...
In my opinion the author has a point: some libraries (e.g. stdlib) need to use 'unsafe' to implement certain concepts, but its usage in general is heavily discouraged - similar to the situation in Haskell-land where they have unsafePerformIO.
Obviously you are expected to "know what you are doing", when using 'unsafe', and you really should only use it if there is no better alternative.
However it might also lead to cases, where the language gets (unjustly) ruled out for certain projects, as people don't want to write something that's unsafe, so maybe 'trusted' or something similar (without a negating prefix) might have been a better choice. In the end this is obviously just cosmetics and the compiler and the machine won't care, but I am not sure if it is the same for people.
I like the use of "unsafe" for something that you don't want to reach for first. Those who are new get a very clear warning and those who aren't have had the opportunity to understand the nuances.
React uses the term "danger" to express a similar concept. You are trusting this value to already have been sanitized / escaped.
I think "unsafe" was a good name. Rails ERB templates use the `html_safe` name for something that the author knows to be HTML-safe, which is confusingly-named, implying that using `html_safe` makes something HTML-safe.
E.g. there is this (not yet released) language JAI especially built for game programming and if i remember correctly the author ruled out Rust because he claimed that game developers sometimes (often?) have to fiddle with memory to implement certain abstractions and that Rust makes that somehow inconvenient.
Maybe that was not his main point and he still might have ruled it out if 'unsafe' was called different, but I think the name itself carries a misleading naming. I mean who does want to do something that is unsafe?
In my opinion the author has a point: some libraries (e.g. stdlib) need to use 'unsafe' to implement certain concepts, but its usage in general is heavily discouraged - similar to the situation in Haskell-land where they have unsafePerformIO.
Obviously you are expected to "know what you are doing", when using 'unsafe', and you really should only use it if there is no better alternative.
However it might also lead to cases, where the language gets (unjustly) ruled out for certain projects, as people don't want to write something that's unsafe, so maybe 'trusted' or something similar (without a negating prefix) might have been a better choice. In the end this is obviously just cosmetics and the compiler and the machine won't care, but I am not sure if it is the same for people.
Thoughts?