A minimal kernel in Swift, running in QEMU | Hacker News Reader

A minimal kernel in Swift, running in QEMU

carette.xyz

103 pointssurprisetalk26 comments

Embedded Swift is honestly very cool. I never really used Swift itself before, but I think it's a good niche since embedded dev could stand for another tool and the language is pretty nice. It also doesn't really suffer from most of the issues people have historically brought up with Swift (cross platform, slow compiles) etc as it is so small, at least to me. :)

If you're starting from scratch I've found you can actually write ~everything in Swift quite easily (reset vectors, compiler emitted intrinsics, etc). But beyond that I think the best feature is that the C/C++ interop works really well and comes out of the box. Makes two-way adoption easy. I wrote a small boot firmware for a simulator and for fun decided to add signatures to the boot process (mldsa44+jq255). You can just copy the .c and .h files and import them into a modulemap file and you're off to the races. You can just get simple .o files and pass them to the linker. There are only 4-5 "freestanding" functions you have to implement. You can turn off heap allocation. Etc.

It would probably be pretty cool and quite easy for instance to write Zephyr or U-Boot drivers, etc in Swift using these techniques.

More of a hello world than a kernel.

Just pound values into registers! I love it, so old school!

In fact, that's how i/o worked before DMA on many systems. Good times!

everything still works like this

Eh, most device interactions are mostly "build a command list and shared memory buffers" rather than the classic touch a a bunch of registers to perform the data plane work. UARTs are one of the last bastion of the old style, mostly because of how you want them so early in the boot process for debug out, it's nice to not have a shared memory/command list access pattern.

That being said, I've even seen it for UARTs on microcontrollers where they're hoping to not have FIFO block RAMs taking up area dedicated to UARTs that might not even be enabled. There you have a absoute minimal staging buffers in the UART, and a fairly reconfigurable DMA controller to allow you to use sharable main RAM instead.

I bet we're going to see a lot more of this. UNIX kernels have dominated computing use cases outside of desktops for a long time more because they conveniently come with free source code than because they are a great design. Now AI makes it so easy to experiment, I hope we'll see a new era of exploration in OS and framework design. We're already seeing the start of this with Omarchy but it's baby steps and not focused on the lowest levels. The stark differences between NT, XNU, SeL4 and Linux show there's plenty of room for differentiation at the bottom, and (other than SeL4) those are all still very similar due to commercial pressures.

> We're already seeing the start of this with Omarchy

This is where you lost me.

Omarchy is stock Linux with vibe coded config files.

If we were seeing experimental kernel designs, new memory management, abstraction layers over GPUs and TPUs baked in as OS primitives than as device drivers, and so on, I'd get excited.

But AI slop propagated by a fascist with an obvious and stupid agenda? No. That's not an example of something interesting.

The comment you replied to is ‘how to say you don’t know or understand what Omarchy is, without saying it’

In other words, they lost me there too.

I know what Omarchy is. I have it running in a VM right now.

I have yet to see any OS developer go all-in on AI and agentic coding in the same way. Maybe Microsoft. But my point was about new operating systems, with new ideas.

Omarchy? the arch-deviated, vibe-coded, dark-money, techno-fascist wet-dream famous for pushing unstable updates that break the system - is that really what you want to use as an example for actual thoughtful work that a reliable kernel needs ? Common now, dude.

As a counterpoint, you are lumping a lot and generalising a lot there, if we're specific then you can't really trivially replace e.g. the Linux kernel with an AI project in whatever language you want. An incredible amount of work has gone into the Linux kernel and its design, and the infrastructure under that veneer of a "UNIX kernel" is too significant to hand-wave away. The issues facing Linux are well beyond (but not excluding) those created by using a dangerous language like C, or using hacky/outdated UNIX interfaces and conventions.

Yes you can try and take things in an original direction but we're ignoring the incredible amount of work that's gone into Linux, solving most of the problems you can't imagine and that AI will burn though a lot of time and tokens trying to re-solve (badly, without a ton of intelligent intervention).

I think you're more likely to see more people experimenting with existing open source work, rather than generating new projects. These new projects are easy come, easy go.

Most of the tricky problems solved in the kernel are hardware quirks related, and AI can just use the existing driver sources as a reference.

I agree. I actually used Claude to rewrite some famous kernels (in OCaml): https://github.com/aryx/IX/tree/main/kernels with xv6, plan 9, oberon, singularity, Squeak on the bare Metal. So easier now to experiment in OS design.

Same here, the OS nerd part of me misses the heterogeneity of computing systems, before it became UNIX/POSIX vs Windows for the most part.

Now with WSL and its use being increasingly relevant (MXC, Windows Server 2025, Windows IoT Enterprise), Windows is increasingly looking just like DEC, IBM and Unisys mainframes (microcomputers) with their UNIX subsystems[0].

So we really need new ideas in OS space.

The mobile space has some alternative approaches, however it is mostly replacing userspace, while keeping an UNIX kernel underneath.

[0] - Yeah, Windows NT already had it somehow, but we all know how little effort that was.

Maybe some day if I find the time I'd like to make a Singularity style single address space OS with GraalVM, except with a fully garbage collected unified heap. In the past it wasn't feasible for a bunch of reasons but I think they're solvable now.

If you have that then so much overhead can disappear, and you can design such better APIs.

> In the past it wasn't feasible

Wirth did it at least twice, with Medos-2 (1983) and later with various flavours of Oberon System.

Good proof of concept showing Embedded Swift can target freestanding ARM without runtime bloat.

there are dozens and dozens of kernels around - it's just not hard to do

if you want a serious challenge, try making some drivers

“machine emulators for hackers”

“Hack the Planet!”? “Mess with the best die like the rest”? WTF?

The movie Hackers (1995).

Those are references to "Hackers" the movie from 1995.

Missed the chance for a "RISC architecture is going to change everything" reference given that it's targeting aarch64.

Indeed. “RISC is good.”

This is a prime example of how to spot poser vs real programmers.

How could one even start programming without sewing HACKERS the movie. cult classic

And Wargames. Oh an Antitrust too.

Awful. Seriously. 100% CPU usage with "while true:"

Reply on news.ycombinator.com