Luu argues that despite ~1000x hardware gains, most user-facing software has gotten slower, and points to case studies where a single engineer with a profiler cut endpoints from 200ms to 8ms in an afternoon. His claim is that the bottleneck is organizational — teams aren't paid, measured, or blocked from shipping on performance — not technical capability.
The submitter surfaced Luu's essay to a 313-point discussion, endorsing the framing that modern slowness is a choice rather than an inevitability. The high vote count and the top-voted Google engineer's quiet agreement in the thread suggest broad practitioner alignment with Luu's diagnosis.
Luu presents concrete receipts — hashmap-to-array swaps erasing 40% of CPU, allocator tuning flattening p99 cliffs, single `perf` sessions producing 25x endpoint speedups — to argue the fix is well-understood and cheap. He rejects both the 'hardware will save us' complacency and the 'rewrite everything in Rust' maximalism in favor of ordinary profiling done by ordinary engineers.
Practitioners in the thread corroborate Luu with variants of the same story: once leadership set latency budgets and enforced them, their teams found large wins quickly. Their testimony reframes the debate as one about organizational will rather than engineering competence or tooling gaps.
Dan Luu's latest essay, *There's no reason for software to be slow anymore*, hit 313 points on Hacker News and reopened an argument the industry keeps trying to close. The thesis is blunt: the hardware we ship on has gotten roughly three orders of magnitude faster over two decades, and most user-facing software has gotten slower. Not because the problems got harder — because performance stopped being anyone's job.
Luu walks through familiar receipts: text editors that take longer to render a keystroke than a 1983 Apple IIe, Slack burning half a gig to display a chat window, IDEs that pause for garbage collection while you type. He also does the thing most performance essays skip — he shows the fix. Case studies of teams that took a 200ms endpoint to 8ms with a `perf` session and one afternoon. Hashmap-to-array swaps that erased 40% of CPU. Allocator tuning that turned a p99 cliff into a flat line.
His argument isn't that software is slow because engineers don't know how to make it fast — it's that they're not paid to, not measured on it, and not blocked from shipping when they miss. The post lands in a week when Chrome shipped another update that made typing latency worse on M1 laptops, and when the top-voted comment on the HN thread was a Google engineer quietly agreeing.
The performance discourse tends to split into two useless camps. One says everything is fine, hardware will save us, developer time is more expensive than CPU. The other says everything must be rewritten in Rust. Luu is in neither. His actual claim is narrower and harder to dismiss: for most apps in production today, a competent engineer with a profiler and two weeks could deliver a 10x speedup, and the reason it doesn't happen is organizational, not technical.
The HN thread is worth reading for the counter-evidence. Engineers from Figma, Linear, and a couple of trading firms show up with variants of the same story: when leadership actually made latency a promotion-worthy metric, latency dropped. When it went back to being "quality of life," the p99 crept up again within a quarter. One commenter from a large fintech notes their team shaved 400ms off a critical path in a hackathon, then spent six months trying to get the fix prioritized against feature work. It shipped after a customer escalation.
Compare this to the counter-narrative from the framework crowd — that React, Electron, and the JS runtime tax are the villains. Luu is careful here. He points out that the same tools ship both fast and slow apps. VS Code and Slack are both Electron. One feels native, the other feels like a bad dream. The delta isn't the runtime; it's whether anyone on the team owns the frame budget.
The essay also lands a quieter, more damaging point: the profession has largely forgotten how to profile. Junior engineers reach for microbenchmarks and Big-O arguments when the actual bottleneck is a cold cache line or a syscall in a hot loop. The tools to see this — `perf`, `pprof`, flamegraphs, `eBPF`, Instruments — are better than they've ever been, and hiring loops don't test for any of them. You can pass a staff-engineer interview at most companies without ever having read a flamegraph in anger.
There's a deeper structural claim buried in the piece too. Cloud pricing has hidden the cost of slow code from the people writing it. When your Postgres query is 20x slower than it should be, the bill just goes up, and finance eats it two quarters later. There's no compiler warning for "this costs $40k/year." Companies that have wired FinOps signals back into engineering dashboards — Shopify's approach is often cited — tend to be the ones where performance discourse actually moves.
If you're a tech lead, the actionable read is unglamorous. Pick one user-visible latency metric, put a number on it, and make missing that number block a release the same way a failing test does. Not a dashboard nobody looks at. Not an OKR that gets sandbagged. A gate. Luu's implicit claim — backed by the case studies he cites — is that this single organizational change does more than any framework migration.
For individual contributors, the takeaway is more personal. The engineers in Luu's examples aren't wizards. They're people who learned to use a profiler and got in the habit of running it before they guessed. `perf record -g` on Linux, Instruments on macOS, `py-spy` for Python, `async-profiler` for JVM, Chrome DevTools' Performance tab for anything in a browser. Two hours with any of these on a real workload will teach you more than a month of blog posts about Big-O. The gap between engineers who profile and engineers who don't is now larger than the gap between languages.
The cloud angle is worth internalizing too. If you're on a team where a bad query costs the company real money but nobody on your side of the org chart sees the bill, that's a fixable process problem. Get the AWS/GCP cost breakdown piped into a Slack channel your engineers actually read. Attribute cost per service. Suddenly the 200ms endpoint that costs $8k a month has an owner.
Luu's essay won't change the industry — these essays never do — but it does give tech leads a well-argued piece to circulate when they want to make latency a first-class concern again. The interesting question isn't whether he's right. He's obviously right. The interesting question is whether the current AI-coding boom, which optimizes for code volume and time-to-first-commit, makes the performance regression worse or forces a correction when the inference bills come due. Bet on the bills.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.