#8 · home-lang/home-os

Context

CLAUDE.md is unambiguous:

ALWAYS USE THE HOME PROGRAMMING LANGUAGE FOR home-os DEVELOPMENT ...All new code MUST be written in Home. Only use non-Home languages for: Assembly (.s files) for bootloader. Zig/C/Other: NEVER.

But scripts/build-rpi5.sh actually builds the RPi5 kernel from a Zig file:

.root_source_file = b.path("../../home-os/kernel/src/rpi5_main.zig"),

That's a direct contradiction with the project's stated rule. The reason it exists is that home-lang's arm64 codegen is a stub — there's no working "Home → arm64 binary" path today, so the rpi5 build had to fall back to Zig.

Blocker

home-lang/home #5 — arm64 backend is a stub — native compilation broken on Apple Silicon (https://github.com/home-lang/home/issues/5)
That issue calls for bringing arm64.zig to parity with x64.zig so home compiles to arm64 natively. Once that lands, this becomes unblocked.

Scope (once unblocked)

Author a real kernel/src/rpi5_main.home that performs the same boot-time setup as the current rpi5_main.zig
Update scripts/build-rpi5.sh to compile rpi5_main.home via the home compiler targeting aarch64-freestanding
Delete rpi5_main.zig
Verify the produced kernel image still boots on RPi5 hardware (or QEMU -machine raspi)
Update CLAUDE.md to remove the implicit Zig escape hatch

Risks

Performance regressions (Home codegen vs hand-written Zig for boot-critical code)
Missing language features that the Zig version relied on (inline asm, packed structs, calling-convention attributes)
Worth surfacing those as separate home-lang issues during the port

Why this matters

Restores internal consistency (the language we built the OS to demonstrate is actually used to build the OS)
Forces home-lang to handle real freestanding arm64 codegen needs, which improves the language for everyone