Why would anyone want to run Erlang in space?
Sign in
Subscribe
A few years ago, I started a new job.<br>The company was an MVNO, like Cricket Wireless or Mint Mobile. MVNOs are sort of outsiders in the telecom industry compared to the "big three" carriers, since they act as "resellers" of cell service on the same towers. Despite that, they often make many of the same software architecture choices. It was this history that influenced my company to develop their core software stack in Erlang.<br>A brief history of Erlang<br>Erlang seems like a very "weird" programming language to many modern software engineers. It was first developed by Ericsson in the 1980s to help develop telecom switches that had to route phone calls from place to place. It's a functional programming language, and it inherits much of its syntax from Prolog:<br>hello() -><br>Msg1 = "Hello, ",<br>Msg2 = "world!~n",<br>Msg3 = Msg1 ++ Msg2,<br>io:format(Msg3).Variables are immutable in Erlang, and you can't redefine them once they're set.<br>Perhaps due to its unpopular syntax and other language quirks, Erlang is not widely used. As of May 2026, TIOBE doesn't even rank Erlang in the top 40 programming languages used globally. And yet... several of the world's largest software products are built with Erlang (or Elixir) including WhatsApp, Klarna, and Discord.<br>The Erlang programming language runs on a virtual machine, like Java. Elixir is another programming language that can run on the Erlang VM, with slightly friendlier syntax. For the most part the advantages I attribute to Erlang in this post can also be assumed to apply to Elixir.
What explains this contradiction? Erlang is used to make huge products that scale to millions of users, and yet isn't widely used or well understood by many developers outside of the companies that use it. It all comes down to whether you need the features that Erlang provides.<br>Erlang has a very particular set of features.Remember when I mentioned that Erlang was first designed for telecom switches? That use case had some very particular requirements. Some of those included:<br>High concurrency: The ability to handle large amounts of traffic, sometimes on a limited hardware budget<br>Hot code-reloading: The need to change code at runtime without affecting customers using the service (updating your switch while it's handling a customer's 911 call can't drop the in-progress call)<br>Graceful degradation: The need to handle some types of failures without bringing the whole system down<br>Erlang was designed with some of these specific features in mind, and for teams who need these requirements, choosing to use Erlang can simplify many parts of their development process.<br>Many software applications choose to provide these features through tooling outside a programming language. Modern DevOps techniques like horizontal scaling and application-aware (layer 7) load balancing can provide concurrency, and orchestration software like Kubernetes can handle rolling out code updates slowly to a large fleet of servers.
Even with these options, some teams may still choose Erlang because of how it simplifies the development experience and integrates all of these features into a single platform. I prefer writing Erlang and Elixir because I find it easier to read and reason about systems when these features are close to the code.
But what does all this have to do with space? As it turns out, there's another industry that cares a lot about high-reliability systems that degrade gracefully.<br>A brief history of computing in spaceflight<br>Computers appeared in space exploration pretty early on. Early manned missions like Gemini (1961-1966) had computers with an optional fallback to manual control. Early unmanned missions like Mariner 2 (1962), Mariner 4 (1964-1967), and Mariner 5 (1967) used electronic devices called "sequencers" to trigger maneuvers and scientific observations. These weren't initially programmable, but they evolved into something closer to a computer starting with Mariner 6 and 7 (1969-1970, for both).<br>Beginning with the Apollo missions (1967-1972), the spacecraft computer stopped being "optional" and became more like the "fourth crewmember" for the mission. A 1.3 second time delay between the Earth and the Moon meant that direct control of the spacecraft from the ground was ill-advised, especially during landing and ascent from the lunar surface. This led to the development of the Apollo Guidance Computer.<br>Indeed, the development of the AGC led to recognition of software engineering as a discipline in itself. Margaret Hamilton coined the term "software engineering" while she was leading the Apollo Guidance Computer project at MIT's Instrumentation Lab.
When systems as complex as programmable computers started being a core component of spacecraft, reliability became a major concern. Different mission profiles addressed this in different ways:<br>Mariner 6 included a manual sequencer along with the first programmable one. Both sequencers could run in...