| ▲ | herni 3 hours ago | |||||||
I disagree. Rust shines when you need perform "unsafe" operations. It forces programmers to be explicit and isolate their use of unsafe memory operations. This makes it significantly more feasible to keep track of invariants. It is completely besides the point that you can also write "shit code" in Rust. Just because you are fed up with the "reimplement the world in Rust" culture does not mean that the tool itself is bad. | ||||||||
| ▲ | gjajric 2 hours ago | parent [-] | |||||||
You have made two major mistakes, which is common among Rust proponents, and which is disconcerting, because some of those mistakes can help lead to memory safety bugs in real life Rust programs. And thus, ironically, by Rust proponents spreading and propagating those mistakes and misconceptions about Rust, Rust developers mislearn aspects, that then in turn make Rust less safe and secure than it otherwise would have been. 1: The portions of the code that have to be checked of unsafe blocks are not limited to just those blocks. In fact, in some cases, the whole module that tiny unsafe blocks resides in have to be checked. The Rustonomicon makes this clear. Did you read and understand the Rustonomicon? 2: Unsafe Rust is significantly harder than C and C++. This is extra unfortunate for the cases where Rust is used for the more difficult code, like some performance-oriented code, compounding the difficulty of the code. Unsafe Rust is sometimes used for the sake of performance as well. Large parts of the Rust community and several blog posts agree with this. Rust proponents, conversely, often try to argue the opposite, thus lulling Rust developers into believing that unsafe Rust is fine, and thus ironically making unsafe Rust less safe and secure. Maybe Rust proponents should spend more time on making unsafe Rust easier and more ergonomic, instead of effectively undermining safety and security. Unless the strategy is to trick as many other people as possible into using Rust, and then hope those people fix the issues for you, a common strategy normally used for some open source projects, not languages. | ||||||||
| ||||||||