> If what you want is to write code that runs on bare metal then consider Rust
The closest I was to bare metal, i.e. code that works without an OS, when I developed stuff for “small” MCUs, like Intel MCS51, Motorola COP8. Rust supports none of them: https://forge.rust-lang.org/platform-support.html
I’ve developed for Nintendo Wii, nominally there’s an OS but it’s very “thin” one, mostly statically linked libraries provided by Nintendo. Rust can’t compile for that platform either, it only supports PowerPC Linux.
I’m currently working on low-level software working on bare Linux kernel. Rust apparently supports ARM Linux, but C libraries are literally everywhere, both kernel APIs and user mode: drm, kms, gles, udev, freetype, low-level kernel stuff like tons of ioctl calls for SPI and USB I/O, wpa_supplicant, and more. That’s too much native C stuff to integrate together, using a foreign language causes too much friction.
I can think of bare metal software for which Rust is good. If I would work on x86 bare metal hypervisor, I would look at Rust very closely. Platform support is good, not much libraries are needed, and the project is extremely security sensitive so using Rust will probably pay off in the long run. But I don’t think that’s a rule, looks like an exception to me.
It’s still foreign. Might be good enough for isolated libraries, but IMO not good enough for the level of integration with OS required by any complex software. Just too much work.
There’s nix::sys::ioctl in Rust stdlib, but there’re also issues with ergonomics, e.g. https://stackoverflow.com/q/51898034/126995 These variable-length structures are used a lot in practice, not just for HID, SPI and USB bulk protocols use similar things. They’re pain to consume from any other language except C and company (C++, obj-c). C# also has very good FFI, but variable-length C structures at API boundaries still require manual marshalling.
There’re third-party bindings for drm, https://github.com/rusty-desktop/libdrm-rs, but apparently that project is not maintained, not sure it works on ARM. It contains more than 3000 lines of code, which will require support. The equivalent C headers, xf86drm.h and xf86drmMode.h, are not small either (800 and 500 lines, respectively), but the important difference is C headers are already supported by Linux kernel so I don’t have to.
The closest I was to bare metal, i.e. code that works without an OS, when I developed stuff for “small” MCUs, like Intel MCS51, Motorola COP8. Rust supports none of them: https://forge.rust-lang.org/platform-support.html
I’ve developed for Nintendo Wii, nominally there’s an OS but it’s very “thin” one, mostly statically linked libraries provided by Nintendo. Rust can’t compile for that platform either, it only supports PowerPC Linux.
I’m currently working on low-level software working on bare Linux kernel. Rust apparently supports ARM Linux, but C libraries are literally everywhere, both kernel APIs and user mode: drm, kms, gles, udev, freetype, low-level kernel stuff like tons of ioctl calls for SPI and USB I/O, wpa_supplicant, and more. That’s too much native C stuff to integrate together, using a foreign language causes too much friction.
I can think of bare metal software for which Rust is good. If I would work on x86 bare metal hypervisor, I would look at Rust very closely. Platform support is good, not much libraries are needed, and the project is extremely security sensitive so using Rust will probably pay off in the long run. But I don’t think that’s a rule, looks like an exception to me.