> Rust is too constrained without [unsafe blocks] to get any useful work done.

Just saw this in the wild again.

@veloren has about 330,000 lines of Rust code today. It's a networked, multi-threaded, 3D, portable game and game engine played by thousands of people. Very much not a contrived example. Name any sort of code and you'll find it in there: GUI, packet parsing, physics, DSP, decision trees, database calls, ECS, procgen, audio. It's all in there.

It has 12 instances of `unsafe`:

(1/2)

Of those 12 instances:

- 6 relate to hot reloading (dynamic linking) and aren't even presented in public builds

- 3 relate to the plugin system (JIT compilation and other things that are almost impossible to provide hard soundness proofs for)

- 2 relate to shader compilation (also JIT)

- 1 relates to accessing the OS clipboard and is unsafe because the underlying abstraction is perilously easy to abuse (thanks C)

I know these people are just trolls, but still. It irks me to see people still saying this in the wild.
One argument I've heard is "okay, now tell me how much unsafe is in the dependency tree" but this entirely misses the point: nothing in the dependency tree looks even slightly like a physics engine or a server, let alone a full game & game engine. The measure of things must surely be how much forward progress one can make without leaning on unsafe code. After all: even the safest of languages contain huge language runtimes written in perilously unsafe code. Dig deep enough and you will find it.
(This is a subtoot about the first Linux kernel CVE present in Rust code having been found. The CVE was caused by code in an unsafe block, apparently)
@jsbarretto dang, it's gotta suck to have 99% of your code be marked as "extremely likely not where memory safety issues are".
@dascandy Yeah, what a curse to live with. We might aim at the stars, but hitting the moon instead might as well be failure

@jsbarretto To me this confirms even more that Rust's unsafe {} blocks are a good thing: if you have a crash / vulnerability related to memory corruption, you can dramatically reduce the amount of places you have to check for and it's likely much easier to fix.

I think anyone who has worked in a big enough C or C++ codebase has heard about at least one elusive memory corruption that is somewhere in the code that either took weeks to pinpoint, or took weeks to fix, or is still unfixed months later.

The same is very unlikely to happen in Rust.

@yrlf @jsbarretto as someone maintaining a firmware codebase that's primarily in C (can't do Rust atm because afaict it's not possible to build a whole UEFI firmware as Rust-only) i can attest that there are absolutely memory corruption bugs i have yet to catch in my codebase...
@jsbarretto yeah, one of the key ideas behind Rust is that it's possible to build meaningful safe abstractions on top of unsafe primitives. a lot of work has been done to ensure that we can have meaningful soundness proofs even in the presence of unsafe
@jsbarretto in our firmware for a hardware token running bare-metal without even an allocator I'm guessing the majority of the unsafe code are 3 C library dependencies.

@jsbarretto Rust is useless without unsafe blocks in the same way Python is useless without writing C code.

(Or rather less so. Since a lot of C dependencies you Python code depends on could be safe or mostly safe Rust as well.)

@ids1024 It amounts to the incompleteness theorem, at the limit. There must always be some implicitly trusted core if you go low enough.
@jsbarretto @ids1024 this is the road that leads to building a homebrew CPU out of 7411 logic chips
@aburka @ids1024 Don't tempt me with a good time!
@jsbarretto I think it's worse than that. I think some of them have a genuine belief that unsafe code is faster.
@jsbarretto eh, sadly they are not necessarily trolls. I can see daily, in some PL communities of some low-level languages, people seriously discussing how "Rust has unsafe" and therefore it's ok to use their favorite PL, which to their eyes is as safe as Rust.