Show HN: Building a web server in assembly to give my life (a lack of) meaning

Original Article ↗ Hacker News Discussion ↗

Project & Motivation

  • Hand-written ARM64 assembly web server for macOS; started as a personal learning/therapeutic project.
  • Author describes assembly as meditative: constraints and minutiae help focus.
  • Many commenters express emotional resonance with doing “hard, unnecessary things” for fun or meaning.

Code Structure, Docs, and How to Read It

  • Codebase ~3,000 LOC with ~1,000 LOC of comments; intended as a learning resource.
  • Recommended reading order: main file (ymawky.S), then request handlers (e.g., get.S), with parsing and small modules as needed.
  • Modularization via multiple assembly files using .global symbols and a Makefile to compile and link .o files.
  • Some want more high-level architecture docs; author plans to add.

Portability & OS / Syscall Details

  • Currently macOS-only ARM64; porting to Linux is non-trivial:
    • Different syscall registers (x16 vs x8), trap instructions (svc #0x80 vs svc #0), and syscall numbers.
    • Darwin-specific syscalls/structs: proc_info(), getdirentries64(), sigaction layout differences, directory entry differences vs Linux getdents64().
  • Discussion of whether #ifdef-based portability is realistic; author says possible but impractical given how it was started.
  • Note that macOS syscalls are not considered stable; Go switched to calling libSystem.dylib, but this project intentionally avoids it.

Performance & Design Choices

  • Uses fork-per-connection model; author expects it to be slower than nginx/Apache, where the bottleneck is fork(), not instruction-level efficiency.
  • Assembly may help with binary size/startup but not fundamentally with this concurrency model.

Assembly vs Higher-Level Languages

  • Some nostalgia for C64/Amiga/x86 assembly; others emphasize maintainability and configuration complexity on modern PCs.
  • ARM64 praised as cleaner than x86 by some; others find RISC constraints and immediates frustrating.
  • Several argue most real-world web apps are better served by languages like Go, C, etc.

LLMs, Craft, and the Future of Coding

  • Major debate: could/should an LLM write this, and does that cheapen the achievement?
  • One camp: LLMs make such feats trivial, reducing them to gimmicks and threatening employment; mourning “death of a human artform.”
  • Other camp: value is in the journey, understanding, and craftsmanship, which LLMs can’t replace; LLM code often low quality and hard to maintain.
  • Some see LLMs as just another tool raising the bar of what’s feasible; others fear over-reliance and loss of deep understanding.

Community Reactions

  • Strong enthusiasm: “cursed and wonderful,” “metal,” “heroic,” inspiration for similar hobby projects (e.g., software renderers, RISC-V work).
  • Skepticism from a pragmatic perspective: poor portability, maintainability, and lack of production relevance.
  • Broader philosophical riffs on “artisanal code,” hobby vs career, and finding meaning in difficult, arguably “useless” projects.