How Rust-OS look like in API surface?


I think Rust will eventually be used as a language for a new generation of OS.
My poor imagination cannot draw a clear idea about how it will look like for the future programmers.

C-based OS is all settled roughly around the standardized API set like POSIX.
Do we have to replicate POSIX similar set of standard for Rust-breed OS?

POSIX encapsulated OS (current C-breed OS) are all interfaced by C functions,
and every other languages are to interact in terms of POSIX-C functions.

What if we create an OS in Rust-lang? Do all other languages need to implement
Rust-API? What would be a practical definition of Rust-OS API? Do we need
to stick to the existing tech set like POSIX, slightly modified for Rust ?
Of do we have to define a whole new set of OS API, reflecting the nature of

I know that it is too early to discuss this topic… but I think if we are successful
enough to define a clean set of Rust-OS API, then the actual creation and
application of Rust OS will be accelerated.

Eventually we’re going to create a new one, don’t we? No existing OS will match it
in terms of security and performance, am I right? Building a sound, concrete,
modern and fast OS might be a number 1 goal of Rust-lang, if we take this
language serious enough, because no other languages even dare to do that,
if not only for personal, educational purpose.


In my opinion there’s no practical sense in making a new general-purpose OS from scratch. It’s just overwhelming amount of work, and I seriously doubt that there’s a need for a new OS when we’ve got already working Windows, Linux, and ${your favorite flavor of BSD}.

But I think the area where Rust really might shine, though, are single-purpose OS kernels and unikernels (such as Mirage). And, as I understand it, we can avoid costly kernel context switches because of language-based protection - that’s why Rust looks very promising here.


If we are thinking only 2~3 years of time-span, you are right. But a language lives much longer than that.
During the last 60 years, Unix/Linux kernels were written several times from the scratch. Why not again?


Just waiting. Someone will do it, one day :)!


It’s definitely possible, considering Servo - without doubt a browser engine is a very big project as well.

But, what I’m trying to say here, is that in my opinion it’s more probable to expect something completely different rather than a new “classic” operating system akin to Linux, OS X or Windows - like Servo is rethinking a browser engine from the base, making it parallel. And Rust is certainly a good choice to innovate in a similar vein in the OS field - like in the unikernel example I’ve provided above.


It will probably happen eventually (I am hopeful).

I guess the API will be smaller and more usecase driven. A lot of work is spent optimizing IO paths with zero-copy and doing encryption without continuous context switching.

But I guess it will not be the huge-pile-of-drivers OS like linux or the *BSDs are, since those represent millions of work hours. Rather I think it will be an OS running on some paravirtualization layer or microkernel that only provides virtio access to the hardware.

API wise I think there should be a focus on developer friendly and very straight forward async semantics for most interactions.

But I dont think rust can go the way of singularity or other research projects and do a single address-space OS (eliminating expensive context switches) protected by a managed runtime, since rust is not totally safe.

I hope we find a new set of helpful abstractions, even if they are a lot more complex. A complex starting point is maybe better than a very simple one and everyone has to replicate all the bits one needs using the messy userland (dbus lol, btrfs, sqlite in every process, sandboxing…).

Also a lot of system actions should be done transactionally. Like changing a set of firewall rules, or transferring a port binding from one process to another without loosing any connections, doing multiple mounts or whatever.

I think rust is a much better language to manage complexity than C, which becomes a mess very quickly.