Hall of FameJeff Dean, Peter Norvig; interactive by Colin Scott20121 min read
Related reading
The Tail at Scale
The paper defines “tail‑tolerant” systems that keep interactive latency (≤100 ms) low even as services scale to thousands of servers, and surveys the main causes of latency outliers. It shows that techniques such as request replication, hedged requests, and resource isolation can dramatically shrink the latency tail with modest overhead, enabling higher utilization without over‑provisioning.
Hall of Fameresearch.google1 minpaperFaster Starts, Less JavaScript Overhead
Codename One reduced startup latency and JavaScript overhead by publishing screen state atomically, indexing style lookups, avoiding unnecessary artwork generation, and refining suspension analysis, yielding measurable speedups.
CodeName Onecodenameone.com7 minFaster Maps: Chasing Swiss Speed
ParparVM’s HashMap suffered catastrophic miss latency due to linear probing on dense integer keys. By adopting CPython‑style perturbed probing (Swiss‑table style) and extending tagged immediate values to more primitives, miss latency dropped from 32 s to ~45 ms, allocation pressure fell dramatically, and overall performance stayed roughly flat despite a modest hit‑time slowdown.
CodeName Onecodenameone.com8 minArticle: Your Next DSL Author Is a Language Model
Typed Domain Grounding (TDG) embeds a DSL inside a mainstream language the LLM already knows (e.g., Kotlin) and uses the host compiler as an oracle. The author describes five building blocks—embedding, choosing a host language with high training‑data frequency, compiler‑driven type safety, a generate‑compile‑repair loop, and an on‑demand teaching tool—and shows measured results from kUML, a Kotli…
InfoQinfoq.com18 minWhat Every Programmer Should Know About Memory
The paper explains how modern CPU caches, memory controllers, and NUMA architectures affect program performance and what developers can do to write cache‑friendly code. It provides concrete advice and tooling to reduce cache misses, avoid false sharing, and place memory near the accessing cores.
Hall of Famefreebsd.org397 minpaperCan we stop with the uptime percentages?
This article argues that uptime percentages are a poor public interface for communicating service reliability because their non-linear nature is not intuitive to non-infrastructure people. It proposes showing absolute downtime (e.g., hours affected) alongside percentages for better clarity for a general audience.
Hacker News front pagejim-nielsen.com2 minHN144112
