20
votes
Which language would you pick to completely rewrite BSD, Linux, etc.?
It'd my understanding that C has stuck around in the UNIX world for so long, nearly half a century, mostly due to the inertia of legacy code.
If you could snap your fingers and magically port/fork the entire stack of open source codebases to the language of your choice, which would you pick and why?
The main reason C stuck around for so long for OS design (Yes, they write Windows in C as well) is because it's the next best thing to assembly, and it's portable across CPUs.
When writing an OS, you basically need to tell the CPU what to do, step by step. And, you need tight control over each of those steps. No other language will really enable you to do that.
None, to be honest. It would still be C, with a severely limited list of features, and a massive amount of static analysers, unit tests, dynamic analysers, integration tests, fuzzers, etc.
The only languages that kind of look like they could replace C are (a limited subset of) C++ and Ada. The first will need the same amount of programmers' helpers. The second will require a lot of developers, which it doesn't have.
A project you might be interested in is Serenity OS:
OS written from scratch in C++ as a hobby project. I'm a fan of the aesthetic and it's been fun to follow, with the creator regularly posting hacking sessions to YouTube.
Quite the achievement.
@ainar-g
Haiku, also, a spiritual successor to BeOS written entirely from scratch in C++, with some fantastic technical innovations to-boot.
I'm not at all a fan of C++, but Haiku's one of the most interesting modern operating systems.
Haiku looks interesting! I played around with the live usb until the whole thing seemed to run out of memory and crash.
I'm digging the UX and aesthetic, interested in hearing more about these technical innovations.
Edit: I should mention I've got a bit of a fantasy for deploying a no-nonsense get shit done workstation. I've been running Arch for half a decade with i3 and now sway and I love it but sometimes with for something a little less... erratic on the side.
Haiku works really well on computers from the late 2000's - I have a ThinkPad from 2006 (an X60t), and everything on it is supported and functional out of the box except for the touchscreen. I personally run into the problem of it lacking creature comforts, like no ability to disable anti-aliasing on text or having a screen temperature dimmer. It's a bummer, because it really is a neat OS with a bunch of innovative ideas, and I'd love to daily drive it if I could.
SerenityOS is awesome. I discovered it a few months back and have been slowly following it. Can't wait 'till it's usable on more than a VM, but it's surprisingly feature complete as is.
I'd snap my fingers and switch the stack to support formal verification.
For the kernel I'd use seL4. It's a microkernel that handles process scheduling, memory separation, capabilities, and not much else. It's written mostly in C but is fully formally specified and has proofs that it follows the specification.
The ported drivers would be written in Ada/SPARK. This includes device and filesystem drivers. I'd also snap again to make sure there was a framework for proving e.g. properties of services which terminate unexpectedly.
Proper userspace programs would be a little less strictly specified, but I guess if we're porting a BSD they'd be written in something like F*. I suspect that most user utilities — even basic ones like
ls— wouldn't need to be optimized even if written in a high-level style; that writing in a low-level style would still result in shorter, more readable code; and that the convenience and assurance of writing in a type-safe language would far outweigh any downsides anyway.There's even some options in this space, like CertiKOS as a kernel in the Coq world.
Projects like VST also bridge the gap somewhat, by allowing programs written in C to be reasoned about in Coq.
Writing everything in one language doesn't seem like a great idea? For example, I think garbage collection is sometimes okay, such as in the network servers and command-line tools that Go is used for, but there is lower level code where it should be avoided.
Zig and Rust look interesting for low-level code, though they aren't fully baked yet. And you don't want libraries used from multiple languages to have any particular opinion about garbage collection.
Another vote for Zig when it is completed. I've made some (pretty basic) stuff with it, and it is an absolute delight to work with. It also has abilities pretty close to c while avoiding a lot of the bad design of c. If you were to work with rust you would have to actively work against it for a fair amount of the low level stuff, which kinda defeats the purpose of using rust.
I haven't had the chance to read up on Rust as much as I'd like to, so this piqued my interest - where do you think it'd be pushing you the wrong way for this kind of work?
I don't think that it would push you the wrong way, just would be the wrong tool. In fact, many of the things Rust does would make you write a better OS, but as the top comment says, you need to be very close to the metal for writing an OS, and the whole point of Rust is to abstract that level. A lot of the things Rust brings to the table don't help in this case, and you would have to work around some of the protections it provides. For example, It hides most allocations, which is something you need to worry about at an OS level, while Zig has maybe the most obvious allocations, with the allocator being user-space and (by convention, you could make it a global) needs to be passed to functions (or structs) using it, and you have to manage out of memory errors if you use an allocator.
Well, since you asked...
If any language were to become as ubiquitous and all encompassing as C, it would become as overwhelming as C to learn, so I might as well go with the most absurd language I could find.
EDIT: Although since I originally learned from Mindstorms and can still sightread Labview, some open source dataflow based code would be nice, but I still gotta go with derpcode.
Changed my mind...
I would port as much software as possible to Scratch. Not because it would be any good in the wild, but if you wanted people to be able to be fluent in code, it would be nice to start them out on examples that were heavily documented and be able to then explain, "now this is how it would look in the real world."
While its not exactly what your asking, Redox OS is pretty close. Its written in rust and inspired by Plan 9. It is suprisingly complete with a functioning display manager and shell.