People bring this up a lot. What I see here is that thousands of potentially (not actually, just potentially) safety risks have been neatly tagged in the code.

If you took a program written in Zig, Go, C++, or C, you would have no idea which parts of the code were potentially unsafe. In those languages, the entire program is one big unsafe{} block.

Rust isolates unsafe code. Having them explicitly tagged means they're isolated and can be eradicated over time, if need be. Though in many cases, unsafe blocks are quite safe.

Yes - I think the proof of the pudding will be whether they put in the effort to eliminate these unsafe blocks. The conversion to Rust is the starting point that makes this possible, but it's definitely not "done" at this point.

> 78% of those blocks are a single line — a pointer that came from C++, or one call into a C library

Don't those blocks need some additional lines for error checking to prevent the unsafety from spreading to the safe code?

Yes but through iterative ratcheting, some portion of that unsafe can likely be migrated to idiomatic code without unsafe. And the other 96% of the code now has more mechanical guarantees than it did before.

Static linting in Rust via clippy also makes it pretty straightforward to begin enforcing things like "unsafe blocks need to have safety doc comments" as a CI warning or failure, and there are community tools that focus on this topic too.

I can't stand the practice of "LLM porting" personally but if you're going to do a mechanical rewrite from something else into Rust, this (permit unsafe and unidiomatic but 1:1 translation at first) is a fairly reasonable strategy imo.

Possible, yes. But it's not like it's terribly difficult to verify correct usage of "unsafe" that amounts to a basic function call to a C library. Trivial uses of unsafe are pretty innocuous.

dude was writing slop before A.I. Andrew called him out.

I don't write Rust - but I sure know that I'm not supposed to use 'unsafe'.