UB in Rust vs C

Remembering that WUFFS exists and that other languages of this class (specialised languages suitable only for a particular purpose e.g. crunching big data sets) could be made is much more optimistic and shows us what our future might look like, even though obviously the Linux kernel couldn't be written in WUFFS

Even though you couldn't write the entire Linux kernel in WUFFS, you could design restricted languages for interesting subsets of the Linux kernel. For example, it should be possible to come up with a restricted language for handling on-disk filesystem layout, such that the resulting code will either successfully handle whatever bunch of bytes you give it, or error out nicely because the filesystem is corrupt. It should also be possible to come up with a language that validates all syscall arguments (including following userspace pointers), to protect against weird acts on the part of userspace.

Part of the point of languages like WUFFS is to change the way you develop software that handles potentially dangerous inputs; instead of trying to validate on the fly, you have a layer that maps "all possible inputs" into "either error, or expected input state". And this is valuable because humans are really bad at thinking about "all possible inputs" (there's around 2**44 possible states for my SSD's exposed storage areas, for example, and I doubt that anyone has carefully thought through how xfs will behave for every single one of those 2**44 states supplied to it as "valid XFS image, please mount"). By having the machine say "you haven't come up with an answer for the meaning of these 2**30 states, because they're neither missing a signature, nor valid", you encourage the programmer to think this through fully.

Today people like to put Rust (without unsafe)/WUFFS and C# (also without unsafe)/Java (without JNI modules) into the same group, but I think we need to distinguish them, somehow, because they have, in some sense, radically different approach to UB and, more importantly, to safety.

And, IMNSHO this whole story with C#/Java craze was gigantic waste of time and resources.

In some sense C# and Java tell the developer: don't think about safety, we got it covered, unsafety in the managed code just doesn't exist, while Ada, Rust and WUFFS tell the exact opposite story: hey, you have to think about safety all the time, when you write each line of code, but don't worry, we would double-check your reasoning about why your code is safe and if we couldn't understand you reasoning compiler would tell you.

That dichotomy was noticed ages ago by Tony Hoare and was distilled into his famous phrase saying: there are two ways to write code — write code so simple there are obviously no bugs in it, or write code so complex that there are no obvious bugs in it.

The majority of today's safe languages belong to the write code so complex that there are no obvious bugs in it and only care about memory safety and absence of UB (and usually achieve both via the use of heavy runtime system). And these languages are all slow for a reason. I always felt that this reason is use of tracing GC but could never imagine how alternative can look like — till Rust made it accessible to the masses (Ada was always trying to do what Rust did, but was unable to invent working solution till Rust gave it and then, of course, Ada stole it and thus closed the loophole that existed for decades).

And when I looked from where it arrived in Rust I was surprised to find out that it was lifted from the tracing-GC based language! The trajectory was, essentially: start with tracing-GC language, go after write code so simple there are obviously no bugs in it property, add affine type system to make code safer, realize that GC is now superfluous and ditch it entirely.

This have proven what I actually felt intuitively all along (tracing GC is bad solution to safety issues) but also have shown me that problem is not tracing GC per see, problem is an attempt to solve safety problems by moving them into a managed runtime (which then needs GC to avoid UB).

Ultimately only human may handle safety and unsafety (Java tutorials that I saw usually include example of how stack implementation needs to turn “erased” elements into nullptr or else GC couldn't remove them), and if compiler can verify that solution that human invents then the end result is both safe and faster than an attempt to ensure safety via the use of managed runtime (which doesn't even work!).

WUFFS is an example of next step after Rust, is some sense: it's not general-purpose solution but when it can be used it's both safer and faster.

Maybe 10 or 20 years from now Rust replacement would be made and it would adopt these ideas, but for now I think it's enough to establish that fact that language that allow you to be crazy but puts on the straitjacket with sleeves tied at the back and places you into a room with padded walls and language that tells you “what you wrote makes no sense, go and redo your code” are radically different approaches to “safe” language without UB.

tokio::spawn({
    let io = cx.io.clone():
    let disk = cx.disk.clone():
    let health_check = cx.health_check.clone():
    async move {
        do_something(io, disk, health_check)
    }
})

tokio::spawn(async move {
    do_something(cx.io, cx.disk, cx.health_check)
})

tokio::spawn(async clone {
    do_something(cx.io, cx.disk, cx.health_check)
})

That's why I said references must point to a valid place, not a valid instance. It's entirely permissible for the place that's pointed at to not be a valid instance, as long as it's a valid place for the referent type to live in.