Fusion – A hobby OS implemented in Nim

Original Article ↗ Hacker News Discussion ↗

Project & Design Goals

  • Fusion is a hobby OS written in Nim, targeting bare metal and x86, with a documented development journal.
  • Design goals include: single-address-space OS, capability-based security, and modeling processes as state machines communicating via statically typed channels.
  • The author explicitly wants to diverge from Unix/“everything is a file,” and experiment with new abstractions.

Choice of Nim & Memory Management

  • Nim is described as a statically typed, C/C++/JS-compiling language with strong C interop, inline assembly, templates/macros, and optional GC.
  • Current Nim uses ARC/ORC (reference counting) by default, so there is no stop-the-world GC; low-level code often uses raw pointers with some manual memory management.
  • The author finds Nim simple, expressive, and performant, preferring it over C (UB/age), C++ (complexity/OOP), Rust (perceived complexity, lots of unsafe in kernels anyway), Zig (syntax noise, allocator focus), and Swift (poor bare‑metal support).

Nim Language Debates

  • Positives: Python-like syntax, deterministic memory management, strong standard library, easy FFI, good for systems and embedded work.
  • Concerns:
    • Backward compatibility/breakages reported as occasional but not frequent.
    • Case/style insensitivity (only first letter is case-sensitive) is contentious: some see it as a non-issue aided by style checks and great for FFI; others see it as a readability and “production-scale” risk.
    • Some dislike 2‑space indentation; others use 4 spaces without problems.
    • Desire for better sum types, pattern matching, and IDE support, especially for JetBrains tools.

OS Development Challenges & Advice

  • Hardest part reported is task switching: structuring stacks, switching contexts transparently, and handling user/kernel mode transitions.
  • Broader OSDev challenges listed: boot process, scheduling, VFS, drivers, graphics, USB, POSIX/CRT support.
  • Recommended resources: Intel SDM, OSDev wiki, existing kernels, and hobby OSes; emphasis on heavy reading, incremental progress, and modest expectations.

Typed Channels and Beyond-Files Abstractions

  • Files are criticized as unstructured blobs requiring ad‑hoc conventions.
  • Proposed abstraction: typed channels (Channel[T], with Source[T]/Sink[T]), with registered serializers, used for IPC, syscalls, and services.
  • Goal: system-wide, statically typed composition of processes (and even GUIs), not just shell-level pipelines.
  • Comparisons/inspirations mentioned include nushell, PowerShell object pipelines, Singularity OS, and research systems like Ethos; observers note potential benefits for observability and modularity.

Syscall Batching & Performance Ideas

  • Discussion of minimizing syscall overhead via batching and asynchronous channels between user and kernel.
  • Vision: user tasks as state machines driven by channel events (I/O completion, timers, interrupts, GUI events), replacing Unix-style signals.
  • Some commenters relate this to microkernel IPC costs and Linux’s io_uring/polling ideas; small “VM-like” interpreters for bounded batched syscalls are also brought up.

Ecosystem, Tooling, and Community

  • Nim’s ecosystem is seen as small but with a surprisingly capable standard library; third-party bindings (e.g., OpenCV, Nostr) can be under-maintained, forcing users to roll their own.
  • Community is described as helpful but not yet at “critical mass,” with no big-tech backing; marketing and community safety are noted as factors in slower adoption.
  • Documentation versioning and discoverability issues are raised; suggestions include better version banners and canonical links.
  • There is enthusiasm for more Nim-based systems projects (e.g., RTOS), and for the quality of Fusion’s documentation and writeups.