Rust-Written Apple DRM Linux Kernel Driver Renders First Cube

- Implicit casts

It has the following coercions:

+ Subtyping, which is based on lifetimes, not inheritance -- e.g. I can use a global array somewhere an array with a shorter lifetime is required

+ unique references to shared references, unique references to mut pointers, shared references to const pointers, mut pointers to const pointers

    &mut ---> &
     |        |
     v        v
    *mut ---> *const

+ "unsizing coercions" -- if you have some pointer type that points to e.g. an array of known size, and you want to change it to a (bounds-checked!) pointer to an array of unknown size (a slice, in Rust parlance), that coercion occurs

+ function types to function pointer types

+ the ! type to any other type -- there are no values of the ! type, so this is sound (it's the type that e.g. exit() returns)

- loop keywords -- it's just for and while, not even do-while

- switch -- It has real ML-style pattern-matching, with extra goodies for pattern-matching on arrays more easily. This doesn't have the fallthrough problems of C, and is more expressive to boot.

- enum -- Again, the real ML-style design. Typesafe, and _far_ more expressive.

- _Generic -- Another ML-family design :) This time via traits, which are similar to typeclasses in languages that have those instead. Think, "interfaces, but don't require a vtable (unless the programmer requests one)"

- typeof -- Nope, though there's (ML-family-style again!) type inference, so the cases where it'd be necessary in e.g. C macros just aren't a problem.

- No explicit number of bits -- the builtin types are u8, i32, f64, etc. -- the only ambiguously-sized integers are isize/usize, which I believe are specified to be the same size as size_t; I don't know that there's a pointer-sized integer type for platforms with larger pointers than size_t's (e.g. ARM Morello and other CHERI CPUs)

Which language(s) do you like more for writing this kind of systems program?