January 7, 2026
Proofs vs performance cage match
Formal Methods Only Solve Half My Problems
Proofs make apps “correct”—but are they fast? Devs bring the drama
TLDR: An AWS engineer says math-based tools can prove systems are correct but don’t answer speed or cost. Commenters split between theory fans and practical devs, joking about “the other 90%” while asking for tools that handle performance too—especially for JavaScript stacks. This matters when apps face real-world load.
AWS engineer Marc Brooker just dropped a spicy take: mathy “formal methods” like TLA+ and P can prove your system won’t corrupt data (that’s safety) and will eventually respond (that’s liveness), but they won’t tell you if it’s fast, cheap, or calm under chaos. He wants one set of tools that covers both correctness and performance, instead of today’s patchwork of prototypes and simulations. The crowd heard him—and instantly split into camps.
On one side, the snark squad: HPsquared joked, “Maybe they solve the first 90%, but not the other 90%,” and the thread lit up with memes of math proofs versus latency graphs. On the other, the explainer crew: chrisaycock spelled it out—these tools prove correctness, not speed, invoking the classic “prove it, don’t run it” energy. Newcomers piled in with “what is P?” while learners cheered a friendly guide from whinvik and shared this intro. Meanwhile, practical devs crashed the party: “Does any of this work with Node?” asked jadbox, sparking eye-rolls from purists and high-fives from JavaScript land.
The vibe? A tug-of-war between theory lovers and ops realists. Everyone agrees: avoiding data disasters is great—but if your app crawls when traffic spikes, no proof will save you. The community wants tools that can do both, yesterday.
Key Points
- •Formal methods like TLA+ and P are valuable for correctness in distributed systems but are typically applied selectively rather than for full verification.
- •Industrial verification focuses on safety and liveness, leaving performance and cost questions unaddressed by these methods.
- •Key design concerns outside formal verification include latency, cost, scaling under various loads, hardware needs, network sensitivity, replica-driven availability/durability, and overload behavior.
- •Performance questions are currently addressed via prototyping, closed-form modeling, and simulations (Monte Carlo/MCMC), each with trade-offs in speed, effort, and assumptions.
- •The author calls for integrated tools that combine formal modeling and model checking with capabilities to query performance characteristics from the same models.