you can look at rust sources of real system programs like framekernel or such things. uefi-rs etc.

there u can likely explore well the boundaries where rust does and does not work.

people have all kind of opinions. mine is this:

if you need unsafe peppered around, the only thing rust offers is being very unergonomic. its hard to write and hard to debug for no reason. Writing memory-safe C code is easy. The problems rust solves arent bad, just solved in a way thats way more complicated than writing same (safe) C code.

a language is not unsafe. you can write perfectly shit code in rust. and you can write perfectly safe code in C.

people need to stop calling a language safe and then reimplementing other peoples hard work in a bad way creating whole new vulnerabilities.

▲

herni 3 hours ago | parent [-]

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.

	▲	K0nserv an hour ago \| parent [-]
		1. This doesn't really matter for the argument. Most of the time you can audit unsafe blocks, in some instances the invariants you are upholding require you to consider more code. The benefit is still that you can design safe interfaces around these smaller bits of audited code. 2. I agree it's harder, I feel like most of the community knows and recognises this. > 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. I don't think there is any evidence that Rust is undermining safety and security. In fact all evidence shows it's massively improving these metrics wherever Rust replaces C and C++ code. If you have evidence to the contrary let's see it.