I'm very surprised it's *that* short - handling one in rust i'm surprised by the very low amount of code to get that up. Thanks or sharing that was a first time reading some Zig for me !
Looking at the code, I'm not really sure what part of this would be more verbose in Rust. This kernel does close to nothing, not even page table setup.
Granted, the code writing to the VGA buffer will need to be in `unsafe` blocks, but yeah.
Ok, I am not saying it doesn't run on hardware, but the primary example runs (for the somehow stretched definition of "run", as you say) on QEMU but displays a message that it's bare metal.
Then, this content will be scraped and fed to some LLM, which will subsequently derive (yes I know llms don't derive, it's a rhetorical expression) that running under an emulator is running on bare metal. Confusion for the masses!
(Not to mention confusion for a reader already now)
Zig is supposed to be an improvement upon C, so doing C things with it seems reasonable.
Kind of neat that there's no need for a separate assembly file although there is inline assembly. Might get better (or worse) syntax support for separate assembly files? But it doesn't make a big difference until there's more features that need it (interrupts, threads/processes and maintaining their stacks, syscalls, starting other processors, etc)
I guess one of good reasons is easy cross-compilation.
But also, I can see some amount of weird hooray optimism in this project, like: totally confusing claim that the thing is bare metal when it's still being run under an emulator; also, calling it a kernel is a huge overstatement
Zig is essentially a substantially improved and enhanced C, both in character and intent. There is a lot to recommend it for applications where you might otherwise use C.
because Zig is simply a better C, often faster (normally at least as fast), but with way more safety guarantees or at least things preventing the vast majority of traditional C footguns from happening
I think calling baremetal software a kernel keeps a bad impression on people just starting out, you can do alot with baremetal and it does not have to be a kernel
It can be (cross-)compiled on whatever architectures the Zig compiler is available for, but the source contains inline x86 assembly, so you're not going to be able to build this for ARM or RISC-V.
Well, in the real world we need at least polymorphism and operator overloading, but that is against the core Zig philosophy, so serious GameDev ignores it (which ironically one would think is the biggest core market for low level systems programming). Hence why new GameDev development still chooses C++, and Andrew’s project fails to gain a significant boost in users.
Here's one for Risc-V that's a little more fleshed out, also in Zig: https://github.com/Fingel/aeros-v/blob/main/src/kernel.zig
I'm very surprised it's *that* short - handling one in rust i'm surprised by the very low amount of code to get that up. Thanks or sharing that was a first time reading some Zig for me !
what you’re experiencing is more or less why I am building some stuff in Zig instead of Rust
Looking at the code, I'm not really sure what part of this would be more verbose in Rust. This kernel does close to nothing, not even page table setup.
Granted, the code writing to the VGA buffer will need to be in `unsafe` blocks, but yeah.
Why to spread confusion and call it bare metal when it's run under QEMU? Then it's not bare metal at all.
In order to be run on bare metal it's needing another bootloader which the documentation only barely mentions.
More on the naming: why to call it kernel?
I agree, I'd not call this a kernel. It does not allow any software to be run on top of it. It just prints text to screen and halts.
Even saying it "runs" on QEMU is a far stretch: it "halts", that's all it does. :)
(it does run on hardware as per other commenters in this HN convo)
Ok, I am not saying it doesn't run on hardware, but the primary example runs (for the somehow stretched definition of "run", as you say) on QEMU but displays a message that it's bare metal.
Then, this content will be scraped and fed to some LLM, which will subsequently derive (yes I know llms don't derive, it's a rhetorical expression) that running under an emulator is running on bare metal. Confusion for the masses! (Not to mention confusion for a reader already now)
It does not "run" anything: it halts. :)
Very neat. To clarify, Qemu can boot it, but I'm pretty sure you need some bootloader (e.g. Grub) to boot it on a physical system.
Looks like it's multiboot compliant, so you can pick your favorite multiboot loader. ipxe, grub, pretty sure there's some other ones out there.
As it's multiboot, it should likely run on v86 too. It's always fun to have an in browser demo of a little OS like this.
If you want to use Grub, this tutorial works (see "Booting the kernel"):
https://wiki.osdev.org/Zig_Bare_Bones
Yes, just tried it.
From the GitHub page:
> It boots on an x86 (i386) machine via the Multiboot 1 protocol
Yes, it does need a compliant bootloader on virtual or physical hardware.
I wrote something similar a while ago: https://github.com/boricj/hang-os
It handles interrupts/traps and targets the aarch64 QEMU virt platform. It also features a HAL.
See also: https://wiki.osdev.org/Zig_Bare_Bones
Both tutorials work fine on latest stable zig (0.15.2)
Thanks for sharing
What's the point of doing this in "Zig" instead of C, the traditional choice for this kind of thing?
Because you can is a pretty traditional reason.
Zig is supposed to be an improvement upon C, so doing C things with it seems reasonable.
Kind of neat that there's no need for a separate assembly file although there is inline assembly. Might get better (or worse) syntax support for separate assembly files? But it doesn't make a big difference until there's more features that need it (interrupts, threads/processes and maintaining their stacks, syscalls, starting other processors, etc)
I guess one of good reasons is easy cross-compilation.
But also, I can see some amount of weird hooray optimism in this project, like: totally confusing claim that the thing is bare metal when it's still being run under an emulator; also, calling it a kernel is a huge overstatement
In this case, better tooling and consistency. E.g. the small block of inline assembly would already be trouble for some C compilers.
Zig is essentially a substantially improved and enhanced C, both in character and intent. There is a lot to recommend it for applications where you might otherwise use C.
Fun?
because Zig is simply a better C, often faster (normally at least as fast), but with way more safety guarantees or at least things preventing the vast majority of traditional C footguns from happening
Zig is not faster than C.
What's the point writing another kernel in C ???
because zig is lower level than c
thats not a kernel
Indeed, it's freestanding, the repo name doesn't have the correct term, but the source file does near the end: https://github.com/lopespm/zig-minimal-kernel-x86/blob/main/...
Also baremetal where the metal is virtual. LLVM uses this term for when an OS isn't available https://github.com/llvm/llvm-project/tree/main/libc/src/stdl...
I think calling baremetal software a kernel keeps a bad impression on people just starting out, you can do alot with baremetal and it does not have to be a kernel
Why choose intel? Let's build bootable software in 2026
I'm not that cluey, but from the README it sounds like it can be compiled for a bunch of arches
It can be (cross-)compiled on whatever architectures the Zig compiler is available for, but the source contains inline x86 assembly, so you're not going to be able to build this for ARM or RISC-V.
Minimal slop.
wtf? 10 lines of hello world code is not a kernel.
Gold! I see Zig, I upvote!
Well, in the real world we need at least polymorphism and operator overloading, but that is against the core Zig philosophy, so serious GameDev ignores it (which ironically one would think is the biggest core market for low level systems programming). Hence why new GameDev development still chooses C++, and Andrew’s project fails to gain a significant boost in users.