Elixir developers question 'let it crash' philosophy as user experience suffers
A three-word mantra meant to describe sophisticated fault tolerance is creating real problems when applied without nuance
The user clicked submit on their form, expecting their work to be saved. Instead, their Phoenix LiveView interface crashed silently, wiping their progress and leaving them staring at a reloaded page with no explanation. From the server's perspective, everything worked perfectly—the crashed process restarted cleanly, ready to serve the next request. From the user's perspective, the application had simply eaten their work.
This scenario, outlined by Elixir consultant Zach Daniel in a recent blog post, captures a growing tension within the Elixir programming community. Daniel argues that "let it crash"—a cornerstone of Erlang and Elixir philosophy—has become a reductive slogan that encourages poor user experience design. His critique has sparked intense debate about whether one of functional programming's most elegant concepts has become a victim of its own catchiness.
The philosophy that built telecommunications
"Let it crash" emerges from genuinely sophisticated thinking about fault tolerance. Joe Armstrong, who created the Erlang programming language on which Elixir runs, developed the concept whilst building telecommunications systems at Ericsson in the 1980s and 1990s. His 2003 doctoral thesis, "Making Reliable Distributed Systems in the Presence of Software Errors," describes a radical approach: instead of defensive programming that tries to anticipate every possible failure, build systems where components can fail safely.
The technical architecture is genuinely elegant. Armstrong designed supervision trees—hierarchical structures where supervisor processes monitor worker processes. When a worker crashes due to an unexpected error, its supervisor restarts it in a known good state. The system continues running whilst the failed component heals itself. The Ericsson AXD301 telephone switch, built using these principles, reportedly achieved 99.9999999% reliability.
"The real magic of the BEAM is that for any given piece of code running in Elixir, there is another, higher level piece of code that knows how to handle errors that cannot be locally handled," explains Daniel. This creates what Armstrong called location transparency—processes can restart whether they're on the same machine or across different hardware, enabling both fault tolerance and distributed computing.
From precision to mantra
Sophisticated technical concepts have a way of being simplified as they spread through programming communities. "Let it crash" became the three-word summary of Armstrong's work, repeated in conference talks, blog posts, and community discussions. Like many technical mantras, it began as precise shorthand among experts and gradually became conventional wisdom among practitioners who hadn't necessarily studied the underlying principles.
Fred Hebert, author of "Learn You Some Erlang for Great Good!" and one of the BEAM ecosystem's most respected educators, has observed this pattern throughout his career. The phrase "let it crash" appears frequently in discussions about Erlang and Elixir, often detached from the supervision structures that make it meaningful. Developers learn the slogan before understanding the context.
This transformation reflects what researchers call cargo cult programming—applying techniques without understanding their underlying principles. The term comes from Pacific Islander communities who built replica airstrips after World War II, hoping to summon the cargo planes they'd seen during the conflict. They copied the form without grasping the function.
When elegant theory meets messy reality
The cargo cult problem becomes apparent when developers apply "let it crash" to user-facing systems without considering the human experience. Daniel provides a concrete example: an Elixir web application handling file uploads that crashes when encountering invalid data. The technical system responds beautifully—the crashed process restarts, supervisors log the error, and the application continues serving other users. But the person whose file upload failed receives no feedback about what went wrong or how to fix it.
"There is a user on the other end of this," Daniel emphasises. "In the case of LiveView, the websocket is driving at least some part of their experience. Establishing a websocket takes time. What will the user experience be? Will they see a flash message about something going wrong? Will some of their UI state reset?"
Phoenix LiveView, Elixir's framework for building interactive web applications, illustrates this tension particularly clearly. LiveView maintains application state on the server and pushes updates to users' browsers via websockets. When the server process crashes, the application recovers without full page refreshes—technically impressive, but potentially jarring for users.
GitHub issues and forum discussions describe LiveView applications that crash during user interactions, causing forms to reset, progress to disappear, and interface state to revert unexpectedly. One developer reported that their application would crash after users triggered certain event combinations, leaving people confused about whether their actions had been processed.
The community reckoning
Daniel's critique has prompted broader examination of how programming communities handle sophisticated technical concepts. The Hacker News discussion of his blog post reveals tension between theoretical elegance and practical constraints. Some commenters defend the traditional interpretation, arguing that "let it crash" remains valid when properly applied. Others acknowledge that the phrase encourages poor error handling practices.
"It is very strange that a post trying to explain the concept of 'let it crash' in Elixir does not mention the doctoral thesis of Joe Armstrong," wrote one commenter, suggesting that discussions have become disconnected from their technical foundations. Another observed that true fault tolerance requires more sophisticated error handling strategies than simple process restarts.
The debate reflects a broader challenge facing technical communities: how to maintain the nuance of complex ideas whilst enabling them to spread. Catchphrases serve important functions—they create shared vocabulary, signal community membership, and summarise complex concepts. But they can also become substitutes for genuine understanding.
"While 'let it heal' may not be as catchy, I think it better captures the BEAM's true superpower," Daniel suggests. "Not that our processes can die, but that they can always come back to life." This reframing shifts focus from the crash itself to the recovery mechanism—the supervision structures that Armstrong actually designed.
Beyond the slogan
The "let it crash" controversy illustrates how technical communities can become prisoners of their own rhetoric. Programming languages develop distinctive cultures around particular approaches. These cultures help developers understand when to apply specific tools and create community identity. But cultural markers can also constrain thinking.
When "let it crash" becomes a badge of community membership rather than technical guidance, it discourages nuanced analysis. Developers may feel pressure to demonstrate their Elixir knowledge by embracing the philosophy wholesale, rather than applying it judiciously where it makes sense.
The solution isn't to abandon fault tolerance principles but to engage more seriously with their implementation. This means understanding supervision trees, designing for graceful error recovery, and considering user experience alongside system resilience. It means treating "let it crash" as the beginning of a conversation about error handling, not the end.
Several Elixir developers now advocate more sophisticated approaches that combine supervision's technical benefits with careful attention to user experience. These approaches use pattern matching and thoughtful error handling to provide meaningful feedback whilst still allowing processes to crash when encountering genuinely unexpected situations.
Lessons for technical communities
The Elixir community's grappling with "let it crash" offers broader lessons about how technical knowledge spreads and evolves. Programming communities need mechanisms for maintaining connections between catchy phrases and sophisticated concepts. This might involve documentation that links mantras to their technical foundations, education that emphasises understanding over memorisation, and cultural norms that reward nuanced thinking over tribal signalling.
The controversy also highlights the importance of considering human factors alongside technical elegance. Armstrong's supervision trees represent genuine innovation in fault tolerance, but their value depends on thoughtful implementation that considers the entire system—including the people using it. The most elegant technical solution becomes counterproductive if it creates poor user experiences.
Daniel's intervention has prompted valuable reflection within the Elixir community about balancing theoretical sophistication with practical constraints. Rather than abandoning the principles behind "let it crash," developers are working to apply them more thoughtfully. This evolution suggests that technical communities can course-correct when individuals challenge conventional wisdom with evidence and nuance.
The debate over three words reveals something important about how programming communities handle complex ideas. The catchphrases that help us communicate can also constrain our thinking if we're not careful. The solution isn't to avoid memorable language but to maintain the connection between slogans and their sophisticated foundations—ensuring that as ideas spread, their nuance travels with them.