Why would anyone run Erlang in space?

A few years ago, I started a new job.

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.

A brief history of Erlang

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:

hello() ->
   Msg1 = "Hello, ",
   Msg2 = "world!~n",
   Msg3 = Msg1 ++ Msg2,
   io:format(Msg3).

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.

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.

Remember when I mentioned that Erlang was first designed for telecom switches? That use case had some very particular requirements. Some of those included:

• High concurrency: The ability to handle large amounts of traffic, sometimes on a limited hardware budget
• 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)
• Graceful degradation: The need to handle some types of failures without bringing the whole system down

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.

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.

A brief history of computing in spaceflight

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).

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.

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:

• Mariner 6 included a manual sequencer along with the first programmable one. Both sequencers could run in parallel and compare their results to ensure neither encountered an error.
• The Apollo Guidance Computer was "backed up" by the Abort Guidance System, which was developed by an entirely separate team and monitored the AGC during lunar descent so it could initiate an abort at any time.
• The Space Shuttle (1981-2011) used a network of 5 computers which could be retasked into "redundant sets" of 2 or more machines depending on the level of reliability required for a particular mission phase. Each computer would check the others' outputs and could "take over" primary control of an actuator at any point.
• The ISS (1998-today) uses an even bigger network of computers called MDMs. It shares the "many computers on the same bus" concept with the Space Shuttle, but features less automatic failover.

Beyond the reliability of the actual hardware components, software reliability was thoroughly evaluated too. Every space mission has included many months of rigorous software evaluation to ensure as many errors as possible are identified and patched prior to flight.

Some computers, like the Apollo Guidance Computer, stored their programs in read-only "core rope memory" that was woven by hand months prior to launch. Code stored this way couldn't be changed after memory production started due to the long production times. This meant there was extra pressure to get the code "right" the first time. Code couldn't be changed after manufacture on the ground, so it definitely couldn't be changed in space.

Later missions used read/write core-rope, plated wire memory, and eventually RAM made from integrated circuits. These missions had the ability for ground controllers to upload new code while spacecraft were in flight, but it wasn't a particularly simple operation.

Take the Voyager space probes (1977-today) as an example. NASA has uplinked patches several times while the probes were in flight, most recently in 2024 as a part of an effort to fix a hardware issue in a section of Voyager 1's Flight Data System (FDS) CMOS memory. These patches were likely uploaded by sending updated program instructions along with an instruction to write them to a specific memory address. And they did it without a simulator for the Voyager computers on the ground. Scary.

My hope is that this brief history has illustrated that space missions share some of the same requirements as critical earth-based infrastructure, like redundancy for critical operations and the ability to change code safely during a mission without downtime.

What's the plan, exactly?

A few months ago, I was rewatching an episode of Star Trek: The Next Generation. Whenever Geordi and Data were troubleshooting some problem on the ship, collaborating between a station on the bridge and a station down in Engineering, I always found myself daydreaming about how the heck a computing system for a starship that large would even work. Naturally, my mind drifted to Erlang.

Encountering Erlang in my work was an exciting change compared to what I was experienced with in the software world. It was one of my first real exposures to functional programming, and it seriously impressed me how the Erlang VM could deliver high concurrency and reliability "baked in" to the way the language was designed. In the several years I've learned and worked with the language, I've moved past the "honeymoon phase" and into the "real" phase of working with it as a tool, and it has still largely held up to my expectations... and even exceeded them in some areas.

This blog is an experiment. I've loved space for as long as I can remember, but as a professional software engineer at a SaaS company, I've never come close to working on an actual space mission. I'd like to use this space to combine my love for these two things, (Erlang and spaceflight), and perhaps generate some real research along the way.

Here are some ideas of experiments I'd like to write about on this site:

• Implementing CCSDS protocols in Erlang:
  • The Consultative Committee for Space Data Systems (CCSDS) is a standards body that develops protocols and standards for software in spaceflight applications.
  • Many in-flight missions use their protocols for key functions, like packet transfer over radio, file transfer (I mentioned CFDP above), and time sync
  • Erlang's binary pattern matching makes this a fun software-only library project. Indeed, another space enthusiast recently completed a parallel effort in OCaml, which is running in space right now!
• Profiling the Erlang VM's performance under radiation conditions:
  • Space is a notoriously harsh environment for memory systems. Cosmic rays can cause all sorts of damage to different types of memory, from simple bit flips (SEUs) to permanent hardware damage (SELs)
  • Most missions attempt to solve for this using radiation hardened memory and processors, but errors can still slip through. The Erlang VM was not designed to account for these types of data corruption at all, and has not been tested under these conditions.
  • Some ancient forks of QEMU (like FIES and FIESer) exist to perform fault injection and support some types of memory faults. I'd like to run the Erlang VM under a modern emulator, (like Renode) inject faults, and document common failure modes.
• Implementing an Erlang distribution protocol with checksums:
  • A system of Erlang nodes can work together to run a single application, communicating over a "distribution protocol". Erlang has a built-in distribution protocol, but the protocol the VM uses is also pluggable.
  • The built-in Erlang distribution protocol does not have any data integrity or checksums built in, since it runs over TCP by default. An interesting exercise could be to implement checksums on messages sent over the distribution protocol, to ensure that messages between nodes cannot be corrupted by radiation effects.
• Running Erlang on RTEMS:
  • RTEMS stands for Real-Time Executive for Multiprocessor Systems. It is an open source real-time operating system that has been used for many space missions by both NASA and the European Space Agency (ESA).
• GRiSP is a project to compile the Erlang VM for RTEMS, to better enable the use of Erlang in embedded applications. I'd like to familiarize myself with GRiSP, and potentially compile and run Erlang on RTEMS on hardware that already has flight heritage, like a Zynq-7000.

Maybe these projects will lead to launching a CubeSat running Erlang in a few years... who can say? Either way, I'd love to have you along for the journey with me.

Thanks for reading... and see you out there!

References

Most of the Erlang background section was something I was able to put together from my own memory and experience, so I didn't reference any materials there aside from the TIOBE Programming Community Index.

The section detailing the history of computers in space would not have been possible without the fantastic resource of Computers in Spaceflight: The NASA Experience, written by the late Dr. James E. Tomayko, in his time at Wichita State University in Wichita, Kansas. This NASA Contractor Report was published in 1988, and is available for PDF download from the NASA Technical Reports Server (NTRS) under document number 19880069935. This report is itself an incredible resource, and it only covers the history of spaceflight until 1988. I definitely plan to write a blog post dedicated to what I've learned from this report sometime in the future.

I'd also like to give a special thanks to Wichita State University Libraries' Special Collections department, for helping me find a photocopy for a misplaced page that was in the incorrect location in the NASA PDF. They also have 50 boxes of physical ephemera from Dr. Tomayko's research I hope to get a chance to see someday. The catalog ID for that collection is MS-87-08, and the listing of contents can be browsed here.

The brief mention of the ISS's computer network was possible thanks to Chapter 5 of The International Space Station: Operating an Outpost in the New Frontier, by Robert Dempsey, an ISS Flight Director. I only briefly reviewed this chapter, but the whole book is worth a blog post of its own in the future too! You can find a PDF of the eBook on this page (direct link).

For a more in-depth look at how the incredible team at NASA helped patch Voyager in flight in 2024, you can read through this joint press-release from NASA/JPL: "NASA's Voyager 1 Resumes Sending Engineering Updates to Earth". It goes into more detail than my brief mention above. This article by Steven Leibson from Electronic Engineering Journal is also a great source, if you'd like to know more of the specifics related to the memory chips that failed. (It also cites Tomayko, who I mentioned above.)