> If you can add safety very carefully on top of unsafe stuff (without any help from compiler), why not just use `c` and add safety by just being very careful?

Y'know people complain a lot about Rust zealots and how they come into discussions and irrationally talk about how Rust's safety is our lord and savior and can eliminate all bugs or whatever...

But your take (and every one like it) is one of the weakest I've heard as a retort.

At the end of the day "adding safety very carefully atop of unsafe stuff" is the entire point of abstractions in software. We're just flipping bits at the end of the day. Abstractions must do unsafe things in order to expose safe wrappers. In fact that's literally the whole point of abstractions in the first place: They allow you to solve one problem at a time, so you can ignore details when solving higher level problems.

"Hiding a raw pointer behind safe array-like semantics" is the whole point of a vector, for instance. You literally can't implement one without being able to do unsafe pointer dereferencing somewhere. What would satisfy your requirement for not doing unsafe stuff in the implementation? Even if you built a vector into the compiler, it's still ultimately emitting "unsafe" code in order to implement the safe boundary.

If you want user-defined types that expose things with safe interfaces, they have to be implemented somehow.

As for why this is qualitatively different from "why not just use c", it's because unsafety is something you have to opt into in rust, and isn't something you can just do by accident. I've been developing in rust every day at $dayjob for ~2 years now and I've never needed to type the unsafe keyword outside of a toy project I made that FFI'd to GTK APIs. I've never "accidentally" done something unsafe (using Rust's definition of it.)

It's an enormous difference to something like C, where simply copying a string is so rife with danger you have a dozen different strcpy-like functions each of which have their own footguns and have caused countless overflow bugs: https://man.archlinux.org/man/string_copying.7.en

> This is the koolaid I am not willing to drink.

> If you can add safety very carefully on top of unsafe stuff (without any help from compiler), why not just use `c` and add safety by just being very careful?

There is help from the compiler - the compiler lets the safe code expose an interface that creates strict requirements about how it is being called with and interacted with. The C language isn't expressive enough to define the same safe interface and have the compiler check it.

You can absolutely write the unsafe part in C. Rust is as good at encapsulating C into a safe rust interface as it is at encapsulating unsafe-rust into a safe rust interface. Just about every non-embedded rust program depends on C code encapsulated in this manner.

> Well, that is what good type systems do. Carry information about the types "virally". Anything short is a flawed system.

Good type systems describe the interface, not every implementation detail. Virality is the consequence of implementation details showing up in the interface.

Good type systems minimize the amount of work needed to use them.

IO is arguably part of the interface, but without further description of what IO it's a pretty useless detail of the interface. Meanwhile exposing a viral detail like this as part of the type system results in lots of work. It's a tradeoff that I think is generally not worth it.