I’ve been testing Haiku inside QEMU to explore virtualization performance and inspect system file permissions.
While Haiku’s classic C++ architecture is lightweight and elegant, exploring secure filesystem boundaries got me thinking about modern memory safety.
As other OS projects incorporate memory-safe languages, could there be a place for Rust in specific subsystem modules or drivers alongside the core C++ Kit API, or should Haiku remain purely C++?
Would love to hear thoughts from anyone experimenting with Android VMs or language bindings!
From what I understand, with Haiku not being monolithic, you could in theory do you drivers/programs or whatever new kit in whatever programming language that suits you, provided its output binaries can interrop with C++ name mangling?
If I remember, there is already an (albeit unfinished) “haiku” rust crate, if you feel like testing it.
But wouldn’t you have to do unsafe rust for the low-level/driver stuff anyway?
As for replacing existing bit, you would loose compatibility with existing programs (they rely on C++ name mangling).
There are no plans to use Rust in the OS itself. While it’s a great language, we have a hard time enough working with one language, adding a second one would surely come with a lot of new problems, and also limit the gains.
If you’re interested in the use of Rust for an operating system, you can have a look at Redox, which does that, probably better than we could.
If someone is willing to experiment with Rust, you can try it and see how it goes. For userspace apps, it works, but you will have some difficulty using our C++ APIs from Rust (especially as the memory management rules are often not even documented, or not clearly defined at all). For use in the kernel, more work would be required, but on the other hand most of the interface between the kernel and drivers or other modules is not through C++, so at least it should be possible to handle that.