Editorial intro
A compact experiment landed on Hacker News this week: a developer built the full RealWorld (Medium clone) reference app using Lean 4 — a language better known for machine‑checked proofs than production web services. The result is a working, test‑passing implementation that forces a fresh conversation about what "production" can mean for proof‑oriented languages.
In Brief
I built the RealWorld app in Lean 4
Why this matters now: Lean 4 and the RealWorld reference app together show that a proof‑assistant language can run a complete, testable web stack — useful evidence for teams curious about correctness‑first development.
According to the author's writeup, the implementation passes both the RealWorld API and website test suites. The stack uses community libraries (routing, HTML generation, Postgres driver, JSON, crypto, markdown) plus server‑side rendering and a tiny frontend script (Datastar) for interactivity. The backend clocks in at roughly 1,033 lines — reportedly shorter than comparable TypeScript, Go, and C# versions — and demonstrates compile‑time checks that catch mismatches the moment you build.
"There is a RealWorld implementation in Lean."
Deep Dive
I built the RealWorld app in Lean 4
Why this matters now: Lean 4’s RealWorld implementation gives engineers concrete evidence that dependently typed / proof assistant tools can support real web app constraints while delivering compile‑time guarantees that reduce whole classes of runtime bugs.
Lean 4 is primarily known as a proof assistant and dependently typed language; it emphasizes machine‑checked reasoning about programs. That heritage shows through: the author points out concrete safety wins, like route‑handler type checks failing at compile time, stored slugs proven well‑formed, and automatic escaping of user text unless an unsafe primitive is used. Those are not academic toy checks — they map directly to common web vulnerabilities and developer mistakes.
Technically, the project stitches together a lot of small, new libraries: lean‑routing, lean‑html, leanpostgres, lean‑json, lean‑libcrypto, lean‑jose, lean‑markdown, and more. The frontend is mostly server‑rendered HTML with a "Datastar" script for sprinkles of interactivity; this keeps the trusted surface small and lets Lean’s guarantees cover the rendering path. That architecture matters: heavy client frameworks would have invited far more complexity for a language ecosystem still finding its browser interop story.
But the writeup is candid about tradeoffs. The Lean ecosystem is young: many libraries are single‑contributor, and the runtime still has bugs that limit throughput until a patched runtime is released. Frequent language upgrades can break code unless you pin versions. Those are practical, near‑term blockers for teams considering Lean for customer‑facing services today. In short: the code works and proves interesting properties, but using Lean in production will feel different from using a mature framework with hundreds of contributors and battle‑hardened releases.
Why those tradeoffs matter beyond hobbyist pride: correctness‑by‑construction is a compelling idea for an industry moving toward mixed AI/human code generation. The project shows how some safety properties — route typing, slug well‑formedness, default escaping — become first‑class concerns baked into compilation. That reduces a category of runtime checks and ad‑hoc test coverage you otherwise need to engineer. Still, full formal derivation of a web app (i.e., proving the implementation matches a high‑level specification end‑to‑end) remains an open, hard problem — the author is explicit that this is an experiment, not a verified full stack.
Community reaction underlines the tension between astonishment and realism. Some comments framed the work as a sane exploration of Lean’s everyday usability; others simply labeled it "amazing work." Those responses matter because they indicate the audience: this is compelling to formal methods folk and curious full‑stack engineers, but it’s not yet a mainstream production narrative.
Where this goes next is easy to predict and hard to achieve at the same time. If the Lean runtime stabilizes and a few of the small libraries mature (more contributors, better docs, compatibility promises), Lean could become a viable choice for high‑assurance services: think security‑sensitive admin panels, internal tooling where invariants matter, or components in a heterogeneous stack where correctness is a priority. If those ecosystem improvements don’t happen, Lean 4’s RealWorld will remain an impressive demonstration and a pointer toward what might be possible when proof systems meet production constraints.
Closing Thought
This RealWorld port shows that proof assistants are leaving the ivory tower and running HTTP. It’s not a green light for wholesale migrations yet — but it is undeniable evidence that correctness‑oriented tooling can be made practical for everyday web problems, if the community and runtime catch up.