Honest reflections on the most underappreciated technology in software engineering
OTP is the most underappreciated technology in the history of software. That is a strong claim and I am making it without qualification. The Open Telecom Platform -- a terrible name for what is actually a complete framework for building fault-tolerant distributed systems -- solved problems in 1986 that the rest of the industry is still writing blog posts about in 2026. Supervision trees, process isolation, hot code reloading, graceful degradation. The solutions are forty years old. The industry is still catching up.
"Let it crash" is the most counterintuitive and most correct philosophy in programming. Every instinct you have from years of Ruby tells you to handle errors, rescue exceptions, write defensive code, prevent crashes at all costs. OTP says: let the process die. A supervisor will restart it. The state will be recovered. The system will heal itself. This is not reckless -- it is the most sophisticated error handling strategy ever designed. It just sounds reckless if you come from a world where a crash means a 500 error and a PagerDuty alert.
Think about what this means practically. In Rails, you write rescue blocks, retry logic, circuit breakers, health checks, graceful degradation handlers. You build all of this yourself, in application code, and you test it, and you maintain it, and it still breaks in production because error handling code is the hardest code to test. In OTP, fault tolerance is not application code. It is infrastructure. The runtime handles it. Your supervisor tree defines recovery strategy. Your processes are isolated. One crash does not cascade. This is not a framework feature. It is a fundamental architectural difference.
GenServer, Supervisor, Application, Task, Agent -- these are not just abstractions. They are battle-tested patterns extracted from decades of building systems that cannot go down. Ericsson's telecom switches ran OTP with nine nines of availability. Not five nines. Nine nines. That is less than 32 milliseconds of downtime per year. The patterns that achieved that are now available to you, for free, built into the language runtime.
The hardest part for a Rails developer learning OTP is not the concepts. It is accepting that the framework has already solved problems you have been solving manually for years, and solved them better. That is a humbling realization and a liberating one.
Conclusion #
OTP is not a library you learn. It is a way of thinking about systems that, once internalized, makes everything else feel incomplete. The combination of process isolation, supervision trees, and message passing creates a foundation for building reliable systems that no amount of application-level error handling can match. For someone who has spent years building Rails applications and dealing with the inevitable production failures, OTP is the answer to a question you have been asking your entire career: how do you build systems that heal themselves?
Predictions #
-
"Let it crash" will initially feel wrong, then revelatory, then obvious -- and you will wonder why every language does not work this way
-
You will mentally redesign at least one past Rails application as a supervision tree and realize how much simpler the error handling would have been
-
GenServer will click when you stop thinking of it as an object and start thinking of it as a process with a mailbox
-
Supervision trees will become your favorite whiteboard interview topic -- they are elegant, visual, and demonstrate deep systems thinking
-
You will develop a mild frustration with Rails error handling after learning OTP, because you will see how much of it is unnecessary complexity