Matt Godbolt sold me on Rust by showing me C++

This is my observation too:

> Rust is still too hard for the average programmer

What's the best way to "onboard" average programmers to Rust? Is it possible to avoid the more complex syntax and still be productive?

Or does Rust require us to fire and replace our "average c++ programmers" with super-smart Rust programmers?

The result type is obviously insufficient for writing nontrivial programs, because nontrivial programs fail in nontrivial ways that need exceptional control flow. The result type does not work because you have to choose between immediate callers handling failures (they don't always have the context to do so because they're not aware of the context of callers higher up on the call stack) or between propagating all of your error values all the way up the stack to the error handling point and making your program fantastically brittle and insanely hard to refactor.

I think C/C++ are mature in the sense that everyone has gotten tired of trying to fix these issues. But I think we're getting further and further from "well understood" as time goes on. Very few practicing software engineers understand all the nuances of header files, C files, object files, static and dynamic linking, and how different compilers & ABI targets interact with all of that stuff. To say nothing of configure scripts, makefiles, automake & autoconf, pkgconfig, cmake and ninja and all the rest.

Just today, I spent 2 hours trying to get an OS kernel (SeL4) to compile for ARM64. This is an officially supported platform. I ran into a series of problems:

- A recent update to sel4 meant I need to set -DCONFIG_ARM_TLS_REG_TPIDRU for thread-local storage. (Leaving it out is a compiler error). This flag isn't in the configuration script - and it took me awhile to figure out how to set it through cmake + ninja.

- The gcc-aarch64-linux-gnu toolchain was recommended somewhere in the docs. On newer versions of gcc, that pulls in libgcc_eh.a, which tries to use _dl_find_object - which is of course linux only. So the build fails.

- So I swapped to gcc14's aarch64-none-elf cross compiler toolchain, which doesn't assume a dynamic linker is available. gcc-aarch64-none-elf isn't available in apt for some reason, even though the 32 bit counterpart is. From there, I ran into a new compiler error. Turns out the arm gcc toolchains are built against an old version of binutils that didn't have support for SHF_GNU_RETAIN. That is needed for the retain macro to work in C. And retain is used by sel4. This is just a compiler warning, but because sel4 promotes all warnings to errors, the build fails. I could have built my own compiler with a newer binutils. But I ended up just disabling the warning, because you only live once. I briefly tried gcc11 because that's recommended elsewhere in the docs, but gcc11 has the same problem.

All of this headache was from trying to build sel4 - which is all straight C, and one of the highest quality C projects I've ever seen. The codebase is mathematically proven to be correct. But oh my goodness, what a horrendous mess it is trying to work with it. And of course, just to try and get the build process going, I needed to install multiple compilers, ninja, cmake, python and a bunch of random python packages, and google's 'repo' tool to manage dependencies. What is this junk.

Personally I'd prefer to work with clang, but I've had enough pain for one day. And I know swapping compilers will for sure break something else.

If sel4 was written in zig or rust, it would be 10x easier to build and work with. Zig handles cross compilation to any supported platform out of the box. Rust can install toolchains trivially with rustup. Rust also has consistent stability guarantees, ensuring code doesn't "rot" with new compiler versions. And of course, both handle dependencies much, much better. And no need for cmake / ninja / random python scripts to compile. Zig and rust also don't behave differently based on someone else's binutils version. Wtf.

If C is too "mature" to fix these problems, I'm going to switch languages. Sel4 is only 20k lines of code. I wonder if it'd be less work to port it to zig than work with it in C. (I'd consider rust, but rust code can't prevent panics.)

The problem is 'undefined behaviour' is far too powerful.

Why not make division by zero implementation defined. I'm happy with my compiler telling me my program will get terminated if I divide by zero, no problem. Let's even say it "may" be terminated (because maybe the division is optimised out if we don't actually need to calculate it, fine).

My problem is that UB let's compilers do all kinds of weird things, like assume if I write:

    int dividebyzero = 0;
    if(y == 0) { dividebyzero = 1; }
    z=x/y;

Then set dividebyzero to always be 0, because 'obviously' y can't be 0, because then I would invoke undefined behaviour.

Also, for two-complement, it's fairly common people want wrapping behaviour. Also, I don't think basically anyone is using C++ on non-twos complement CPUs (both gcc and clang don't support it), and even if it does run on such CPUs, why not still require a well-defined behaviour, in the same way C++ runs on 32-bit and 64-bit systems, but we don't say asking for the size of a pointer is undefined behaviour -- everyone just defines what it is on their system!

My main issue with panics is poor interop across FFI boundaries.