There are several reasons to choose a language rather than another. I personally don't like Rust at all, so I don't see any reason to use it, neither do I see any advantage in using it. But that's only my opinion. A lot of osdev currently is made by hobbyist (not counting the handful of really succesful kernels), so the main argument is simply personal and there is nothing wrong with it. Moreover, keep in mind that Rust is pretty new while C/C++ are decades old, this means more support, more portability, more people that know how to use it, ... This is not negligible at all.
> If yes, why people still even think about doing it with unsafe languages?
What you need for OS or embedded development is a language that doesn't get in your way. C doesn't get in your way. C is the first language that both stayed out of your way and also provided reasonable productivity features (over BCPL, B, and assembly).
It was only recently that people have figured out how to come close to a "safe" language that doesn't get in your way.
Here is a test case: grab an ARM Cortex-Mx processor. Boot, configure the I/O matrix, and set up, oh say, the counter/timer peripherals for PWM motor control and quadrature decode. If you can do that without a trip to an "unsafe" language, that is a worthy accomplishment for your safe language.
Another test case might be doing page swapping and page-table updates on a virtual memory subsystem on a multi-core CPU without a trip to an unsafe language.
I guess a more direct answer to your question is that when you get down to the hardware, you have to deal with weirdo bit fields, volatile hardware registers, strange read/write ordering requirements, interlocks, and even some totally non-interlockable volatile stuff. C can do it (although I admit it uses language features not everyone sees every day).
Example? Standard language that never required a trip to assembly language for system level programming?
On IBM's, PL/I didn't cut it that regard.
On a UNIVAC you could do a lot of system programming in FORTRAN, but only because there were a zillion proprietary extensions that accessed system programming primitives.
BASIC on a Commodore 64 had PEEK() and POKE() but that doesn't count either, very non-standard.
FORTH? Nope... still asm at the bottom.
Concurrent Pascal? Nope... not safe, despite the type checking, because you could twist variant records however you liked. And I think there was asm at the bottom anyway, IIRC.
COBOL, well, CDC COBOL had a bunch of extensions, too, but you still ended up in asm for system programming.
Show me the source code for a device driver in a high-level language that pre-dates C/B/BCPL.
> On a UNIVAC you could do a lot of system programming in FORTRAN, but only because there were a zillion proprietary extensions that accessed system programming primitives.
Just like pure ANSI C without compiler extensions.
> Standard language that never required a trip to assembly language for system level programming?
Try to implement 100% of libc in ANSI C without writing one single line of Assembly, syscalls into the underlying OS or compiler specific language extensions.
> Show me the source code for a device driver in a high-level language that pre-dates C/B/BCPL.
You shouldn't complain about extensions to the language. C needs extensions too. For example, many architectures have 3 (or more) memory spaces: program/code, data, IO. If you want to do anything on IO, you'd have to rely on non-standard (proprietary) extensions to C, or, like FORTH, get to asm at the bottom, and call those functions from your C program.
Either my sarcasm detecter is broken today, or you've never read the source code of a FORTH system. Or perhaps you are commenting that FORTH doesn't have high-level programming constructs -- but of course FORTH allows meta-programming, so you roll your own.
I'm saying that it's shenanigans that he's justifying disqualifying FORTH as a systems programming language because "it's ASM at the bottom." So I'm on your side of that debate.
> I guess a more direct answer to your question is that when you get down to the hardware, you have to deal with weirdo bit fields, volatile hardware registers, strange read/write ordering requirements, interlocks, and even some totally non-interlockable volatile stuff. C can do it (although I admit it uses language features not everyone sees every day).
I agree with you that building an entire OS to interface with hardware without using _any_ unsafe code is, by some definition of the word, impossible.
However that doesn't mean you must limit yourself to unsafe languages for the other 90% of the operating system code.
Sure it can and it has been done multiple times, although the industry hasn't cared much besides high integrity software, where software errors cost human lives.
"Why doesn't everyone agree with me that statically enforced safety is the only necessary consideration when building hobby projects?"
And yes, an operating system can be developed from scratch with Rust, maybe with a sprinkle of assembly, but every attempt I've seen makes widespread use of `unsafe', so the value mostly comes from Rust's modern type system with its traits and enums.
> > Can an operating system be developed from scratch using a safe language such as Rust?
> We don't know.
Sure we do. Redox[0] boots into a desktop environment with a filesystem, etc etc. What we don't really know is how performant/portable/etc you could make it if you put the same amount of manpower into it as went into <other operating system of choice>.
We do know some prototype can boot. We don't know about operating system being in use in any environment for any purpose.
Damn, we don't know could the browser engine written in Rust work or not, despite the fact writing a browser engine was the goal of Rust from the day one.
By the way, network card driver can be written in LuaJIT (and perform well) too[1]. Shall we do it?
> Damn, we don't know could the browser engine written in Rust work or not, despite the fact writing a browser engine was the goal of Rust from the day one.
We kind of do at this point. It renders reasonably well, faster on some workloads than existing browsers. The majority of work still to do involves chasing down rendering bugs, and building a shell around it. That's a lot of work, but it's the sort of work that isn't breaking new ground like the work with integrating JS and the DOM and a GC into Rust, it's regular boring work. (There's some exciting things going on - see WebRender - but they're mostly theoretically optional and the browser would work perfectly fine and performant if it had much of the same infrastructure as it has today.)
> By the way, network card driver can be written in LuaJIT (and perform well) too[1]. Shall we do it?
Lua's already used for some embedded development. Using LuaJIT as a network driver in some cases seems reasonable to me - especially if you were running it as a userspace process under a microkernel.
Kind of, indeed. Last time I've seen comparison of html5ever with plain C HTML parser, we suddenly realized it is painfully slow, 'uses the proof-of-concept DOM' and whatnot[1]. So we don't know. We've yet to see anything written in Rust used in production environment, just anything.
> Using LuaJIT as a network driver in some cases seems reasonable to me
Why don't we see LuaJIT zealots in every thread on every board in every discussion of something written in C or C++, I wonder?
> we suddenly realized it is painfully slow, 'uses the proof-of-concept DOM' and whatnot
Err, no, you've misread that. html5ever serializes into an arbitrary datastructure, provided by the program using html5ever. It also ships with its own datastructure to serialize into for testing purposes (the "proof-of-concept DOM"), which Servo does not use. It's therefore not a benchmark of html5ever as used in Servo.
More reasonable would be benchmarking Firefox's HTML parsing as it stands in Firefox against Servo's HTML parsing, from text to a fully built up DOM as usable by the rest of the browser in both cases.
On the other hand, in some rendering benchmarks (once the DOM has loaded and the page is actually rendering), Servo is much, much faster than other browsers[0].
If yes, why people still even think about doing it with unsafe languages?