Hacker News now runs on top of Common Lisp

Dark mode, user styles, and accessibility

• Many commenters use extensions (Dark Reader, uBlock, Tampermonkey) to get dark mode, but these break in in‑app/embedded browsers and require constant maintenance when sites change.
• Some argue dark mode should be a browser responsibility via generic algorithms (invert, hue-rotate, APCA-based contrast), user stylesheets, or prefers-color-scheme; others note browsers have largely dropped rich user-stylesheet support and generic darkening breaks complex apps.
• There’s pushback that “colors should be good if the site is well-styled”, met by accessibility counterarguments: users may need different colors, font sizes (including smaller), animation disabling, etc.
• HN’s tiny fonts and low-contrast metadata are criticized as inaccessible; others say browser zoom/minimum font size is the right fix, not redesign.

Common Lisp / SBCL and the Arc runtime

• The change is clarified: HN wasn’t rewritten; the Arc runtime was reimplemented in Common Lisp (Clarc) on SBCL.
• SBCL is praised as “disgustingly performant”, with strong optimization tools, type annotations, and parallelism; Racket/Chez is described as solid but more VM-like and historically weaker for lightweight parallel IO-heavy tasks.
• Some see Common Lisp as more pragmatic for production than Racket, while Racket users highlight its strengths in GUIs and research but acknowledge its different priorities.

Open sourcing Clarc vs the HN app

• The article’s wording caused confusion: anti‑abuse code blocks open‑sourcing the full HN application, but not necessarily Clarc.
• Maintainers say Clarc and the app are mostly separate; a plausible path is porting the already-scrubbed original Arc release to Clarc and open-sourcing that.

Anti‑abuse mechanisms and “security through obscurity”

• HN’s abuse prevention is explicitly described as relying on hidden heuristics; separating these from core logic is now difficult.
• Several commenters distinguish cryptographic “real security” (Kerckhoffs’ principle, formal invariants) from fuzzy domains like spam and moderation, where obscurity is pragmatic and raises attacker cost.
• Others argue even in security, obscurity can be part of a cost‑shifting strategy, but everyone agrees abuse-control isn’t the same as cryptography.

Moderation model and community design

• HN is contrasted with Slashdot and Reddit: far fewer features, heavy but mostly user-driven moderation, plus substantial manual and tooling-assisted intervention.
• Some praise this “less is more” approach and intentional gatekeeping as key to discussion quality; others worry about groupthink, hidden downmodding, and lack of tools like friend/foe or per‑score filtering.
• There’s a recurring theme that HN’s incentives (not growth- or ad‑maximizing) and stability-first ethos explain its longevity and resistance to UI churn.

Performance, architecture, and simplicity

• Commenters are impressed that HN historically ran on a single core; this is used as evidence of how fast modern hardware is and how over‑engineered many stacks have become.
• Heavy threads (5k+ comments) can now be slow since pagination was removed, but most consider that an edge case.
• Examples like 4chan’s static HTML pages and simple text-only architectures are cited to argue that IO/caching, not CPU, is the real bottleneck and that microservice-heavy approaches often waste resources.

Custom stacks, rewrites, and “triviality” of HN

• Some say HN’s visible functionality (text posts, comment trees) could be replicated in a weekend or by an AI agent; others counter that hidden robustness, security, and abuse controls are the real work.
• A few share positive experiences running sizable sites on idiosyncratic stacks: easier to optimize for users, but harder to hire for.
• Joel Spolsky–style “never rewrite” is challenged; HN’s move is held up as a special case: a runtime swap for a relatively stable, text-centric product at large scale.