July 30, 2026
Pick two… and duck
Concurrency, interactivity, mutability, choose two
Programmers are fighting over whether you can really fix a live app without blowing it up
TLDR: The article argues you can’t safely have a program that is fast, easy to inspect while running, and easy to change at the same time. Commenters immediately fought over that claim, with some saying the logic is flawed and others insisting the real answer is: yes, you can do it, but it’s expensive and hard.
A nerdy thought experiment about fixing a running program turned into a full-on comment-section cage match. The article’s big claim is simple: when a program is doing many things at once, lets you poke around live while it runs, and also lets you change data on the fly, something eventually gives. In plain English: if you edit the engine while the car is speeding down the highway, don’t act shocked when sparks fly.
But the crowd on the discussion thread was not ready to nod politely and move on. One of the loudest reactions was basically, “Wait, this logic makes no sense.” User mrkeen called out the article’s wording with a sharp little roast: if multiple parts of the program are already touching the same data, then saying there are “no concurrency issues” just because a human isn’t poking at it felt wildly off. That sparked the biggest drama: is the article making a deep point, or just explaining it badly?
Then came the performance wars. The piece paints copying data as painfully slow, using Erlang as the example, and commenters instantly pounced. roenxi practically rolled their eyes through the screen, arguing that if data can’t change, why keep copying it like it’s 1999? Another reader said the benchmark looked “weird,” which in internet engineer-speak is only one step below calling it cursed. And just when the whole thing seemed headed for doom, my-next-account dropped the swagger bomb: you actually can have it all in most cases, it’s just a ton of work. Translation: the article says “pick two,” while the comments yell, “skill issue.”
Key Points
- •The article argues that combining concurrency, runtime interactivity, and mutable shared state can create unsafe conditions in running programs.
- •It uses a Common Lisp server inspected through Emacs and SLIME as an example where an interactive hash-table update can conflict with another thread's read.
- •The article says some languages, including C, Rust, and Go, prioritize performance by dropping runtime interactivity.
- •It describes Python and Ruby as limiting concurrent data access with a Global Interpreter Lock, making interactive state access safer but slower.
- •It presents Erlang as a model that avoids shared mutable state through message passing and copied values, while noting a performance cost for that approach.