In this article, we look at the origin story of Elixir and its creator, José Valim. 

What led José to create Elixir? What were the early days like? How did it grow?

Who is José Valim?

José Valim is a Brazilian software engineer, who developed an interest in multi-core systems at a young age.2

Going back to my first computer that I got when I was 8 to 10 years old, it was a powerful computer at the time, but two years later, not even that… So I had a Pentium 100, and a boy at school told me he had a Pentium 233. And I was like, “How come? We just got this computer, we’ve barely finished paying for it. How come you have a machine that is more than twice as fast as mine?

José understood early that the next step in computing would not simply be more powerful single-core machines, but rather machines with multiple cores.

José and Ruby

The first programming language José got really good at was Ruby. 

A year after graduating from University in 2009, José founded Platformatec, a Ruby-focused software development agency. A year into Platformatec, he became part of the Rails core team, and continued contributing for another four years. 

In his Rails projects, José frequently kept running into hard-to-reproduce bugs related to race conditions. In a multi-core system, it’s possible that two cores try to modify the same place in memory, or handle the same resource at the same time. Languages such as Ruby didn’t protect against such race conditions caused by improper synchronization of memory access.

José started thinking about how he might tackle this problem.

It’s this curiosity that led him to create Elixir.

Converging Ideas

In his search for a solution, José attributes two points of no return.

The first was discovering functional programming — specifically, immutability. The concept of immutability meant that data was not shared across processes. This eliminated a category of problems plaguing other procedural and object-oriented programming languages. The second was his discovery of the Erlang Virtual Machine.

Erlang was first developed as proprietary software within Ericsson in 1986. It was later released as free and open-source in 1988. It was designed to scale telephony systems that required fault tolerance and distribution. Erlang supported concurrency both within a single machine and communication between machines. The latter was something other languages did not support easily.

José's exploration into functional programming wasn't limited to Erlang. He delved into languages like Frink and Clojure, enriching his understanding of functional paradigms. However, it was the capabilities of the Erlang VM that ultimately inspired him.

Recognising its potential, José chose it as the foundation for his own programming language — Elixir.

Early Days of Elixir

By April 2011, José had v0.3 of Elixir ready, and was using it for personal projects.

However, his initial prototype did not meet the complete vision he had for Elixir.

Replicating Ruby- features within the Erlang VM required adding extra layers of abstraction over Erlang, reducing Elixir's interoperability with it. Any new function or module in new Erlang releases would have to be wrapped first in Elixir, which meant that Elixir would constantly be playing catch up with Erlang.3

As a result, Jose took a break to first study other languages and gather insights for improving Elixir. He became more critical of features added to Elixir. For every feature, he questioned its necessity and optimal implementation.

After months of research, Elixir’s foundation was formed. José approached Plataformatec in February 2012 to discuss the possibility of sponsoring Elixir, and got their green signal. He published v0.5 of Elixir in May 2012, the very first release on the Elixir website.

To get others excited about Elixir, José attended events and met other programmers. He shared about Elixir and gathered feedback about the language. During the Oredev Conference in 2012, José expressed his vision for Elixir. He wanted Elixir to enhance developer productivity and promote language extensibility. He also wanted to preserve a high degree of compatibility with Erlang. 4

The early iterations of Elixir did not have as many features as the language today. In fact, the Stream module was only introduced in v0.10 in July 2013, a year after the release of v0.5. Another milestone for Elixir was the announcement of ElixirConf in April 2014.

Nowadays, major releases are less frequent, often focusing on "quality of life" improvements. However, the ecosystem has been growing, supporting Elixir's use in modern systems.

Elixir’s Ecosystem

One of Elixir's greatest strengths is its community of developers who contribute libraries and frameworks. These are five of the projects that have become the cornerstones of the Elixir ecosystem.

Phoenix

Phoenix was first developed in 2014 by Elixir developer Chris McCord. Phoenix is a server-side web framework inspired by Ruby on Rails. It brings the familiarity of the Rails framework to Elixir. One of its modules is LiveView. It flips the traditional client-server architecture on its head. It uses a persistent web socket/long polling instead of client-server HTTP requests. This reduces latency and removes the network overhead of HTTP requests.

Scenic

Scenic is a client application library. Scenic provides GUIs for fixed screen connected devices. These devices are often used in the Internet of Things (IoT). Boyd Multerer, the person behind Scenic, is also responsible for Xbox Live. He founded and led the team that worked on the Xbox One operating system.

Nerves

Nerves is an open-source platform for building embedded systems with Elixir. It creates a specialized environment that runs the BEAM VM. This brings all the benefits of Elixir and the BEAM VM to the embedded system.

Nx

Nx (or Numerical Elixir) is a multi-dimensional tensor library that leverages multi-staged compilation to the CPU/GPU. It is a newer addition to the Elixir ecosystem and it is an attempt to bring AI/ML capabilities to Elixir.

Membrane

Membrane is a multimedia processing framework that supports a wide range of multimedia types. It can be used to develop real-time communication applications like Zoom.

Elixir’s Popularity

Interest in Elixir has grown over the years as the language and its ecosystem have matured. According to the Stack Overflow Developer Survey, Elixir has consistently ranked in the top three "most loved languages by developers". Phoenix has also become the most liked web framework of 2022 and 2023. 5

Elixir’s popularity has also risen among companies. Companies like Discord use Elixir to support five million concurrent users. Elixir has also seen growing use cases in areas like embedded systems and web development.

Embedded Systems with Elixir

Embedded systems programming is dominated by lower-level languages like C or C++. This is because these Internet of Things (IoT) devices need to be performant given their limited processing power. Yet, Elixir has found a niche in the embedded systems space. Elixir focuses on solving problems outside of writing performant systems.

IoT devices may be used in areas with external factors like network connectivity and physical accessibility. These factors influence the maintainability of such devices. In these cases, performance is not the only consideration when building the embedded system. In such scenarios, Elixir can help to maintain the connection between devices and the central server. This reduces the amount of manual intervention necessary for such systems.

Connor Rigby, a former embedded systems engineer at Farmbot, has mentioned how using Elixir allowed Farmbot to build lean systems that worked well in low-bandwidth areas. 6

Web Development with Elixir

Elixir has also grown in the web development space with the introduction of Phoenix. Companies like Heroku and Mozilla have adopted Elixir. They use it to develop and migrate their web applications and core services.

Using Elixir allowed Heroku's analytics service to handle 3,000 to 4,000 requests per second. The average response time was also reduced to about 1ms.7 Mozilla uses Phoenix to build REST endpoints, implement chat messaging, and create real-time avatar tracking features.

Flaws of Elixir

Elixir has a low adoption rate in industry. Languages like Javascript for web development remain the go-to language for most teams. This is likely due to the greater diversity of tools available for these languages.

The functional programming paradigm also introduces a learning curve for those learning Elixir. Elixir's module system and immutability is a departure from imperative languages like Java. This means that developers will take time adjusting to this new way of solving problems.

Elixir also has a lack of educational resources compared to other languages. This can make it trickier to learn the language for those accustomed to languages with more resources like Javascript.

Conclusion

Elixir is proof that the growth of a language relies on its community.

Individuals like Chris McCord, Frank Hunleth, and Boyd Multerer have contributed libraries, as well as their time and expertise for the community. These contributions have shaped Elixir's ecosystem.

Elixir’s development also highlights the importance of keeping high-level objectives in software development. Every feature of a project should always be met with two questions, “Why do we need it?” and “What is the best way to do it?”. This helps to keep the project lean and focused.

In this post, we trace the history of VCS, leading up to the creation of Git. 

The Earliest Forms of VCS: Manual

In the early 1970s, developers managed versions by manually storing copies of their files. If they thought an iteration was significant, they’d save a copy. There was no standard practice, and every developer had a personal technique.

As computers got more capable, software got more complex, and so did the process of creating it. Developers iterated more, and they needed dedicated tools to be able to store and retrieve past versions of their code.

The First “Proper” VCS: SCCS and RCS

The first formal VCS was SCCS2, launched in 1972 by Marc J. Rochkind at Bell Labs. It pioneered many concepts that we take for granted today. 

For example, SCCS was the first to introduce automatic revision tracking. Developers could now write a command, and trigger automatic storage of the current version of their file. They could trigger another command to retrieve a past version. Later versions of SCCS supported branching and merging as well.

SCCS was a giant leap in the developer workflow.

Most unique among its features, was its storage mechanism. Instead of saving full duplicate of the file being versioned, SCCS stored just changes. It treated the first version of a file as the base and stored it in full. For subsequent updates, it stored only the changes as “deltas” within a file internal to SCCS.

This technique was great for optimising file storage.

As the tool got more usage, it became evident that the delta storage technique SCCS employed wasn’t very ideal for performance. To reconstruct the file for any given version, it had to start with the base version, and then apply deltas sequentially. It’s also why it’s called "forward delta".

Forward delta was like trying to assemble a jigsaw puzzle from scratch each time you want to see the complete picture. For common usage patterns, it was just inefficient.

Ten years later in 1982, Walter F. Tichy of Purdue University launched RCS3 — a more performant alternative to SCCS.

Walter retained the idea of delta storage, but flipped the mechanism with its “reverse delta” method. Instead of using the first version as base, he smartly chose the latest version. RCS deltas compared changes compared to the latest version of the code.

This was a lot more efficient for common tasks, since developers were rarely going too far back in their file history. In addition to improving performance, RCS also improved on the user experience with simpler commands, and introduced a branching and merging system that was more intuitive for developers in that era. 

CVS: RCS, but better

As programs continued to get more complex, SCCS and RCS were no longer able to meet the needs of developers. Both worked best for projects on a single machine. Both could version just individual files, not entire projects. When a file was being edited by one developer, it was locked to prevent getting edited by others simultaneously on the same network.

To overcome these shortcomings, Dick Grune launched CVS4 in 1986, while working at the Dutch University Vrije Universiteit.

CVS still used RCS on the back-end, but added multi-file support, and introduced a client-server collaboration model. This meant that the codebase could now be stored on a central server and accessed by developers from different locations, facilitating collaborative work. In its heyday, CVS was a significant leap forward. 

The 1990s: The Era of Proprietary VCS

In the mid-1990s, the software world was saw many new proprietary VCS enter the scene and innovate in different areas. 

ClearCase by Atria Software introduced a robust branching model, and the ability to configure workflows to the preferences of individual teams within enterprises. SourceSafe by One Tree Software was known for its user-friendly interface, and got acquired by Microsoft. Perforce was known for its exceptional performance.

As for the open source VCS ecosystem, it was mostly quiet.

SVN and BitKeeper: Centralised vs Distributed

In 2000, BitKeeper5 arrived on the scene. Although proprietary, it would go on to be critical in the Git story. Also in 2000, work started on SVN6, which would go on to be the next major open source VCS after CVS.

SVN was created by CollabNet Inc. with key contributions from Karl Fogel and Jim Blandy. It was designed to overcome the shortcomings of CVS, and got very popular in the open-source community. Some developers use it to this day.

A key idea SVN introduced was that of atomic commits. With CVS, when a commit operation failed halfway, it would lead to data getting corrupted. Part of the files would get saved, and part of them would be lost. SVN’s commits took an all or nothing approach, ensuring reliability.

SVN also innovated in its data storage mechanism. In CVS, when you created a branch, it essentially made a full copy of all the files from the original branch at that point in time. This would consume a lot of storage space, especially for large projects. When you created a branch in SVN, it didn’t duplicate all the files. Instead, it created a new directory for the branch that initially only held references to the original files. As changes were made in the new branch, SVN would store only those changes.

SVN was centralised, like all other VCS up to that point. Developers would write their code locally, but they had to depend on a central repository for versioning information. Operations such as viewing history, committing changes, or creating branches required connectivity to the central server, and weren’t possible offline.

BitKeeper is significant for being the first popular distributed VCS. Unlike SVN, it allowed developers to have full local copies of the projects they were working on, which was a novel concept at the time. While SVN’s restrictive approach was seen as an advantage in some corporate settings, BitKeeper’s distributed model was more naturally suited for the nature of open source collaboration.

For these reasons, it enjoyed adoption from its most notable user, the Linux Kernel Project.

The Linux Kernel Controversy

Technology-wise, BitKeeper was perfect for the kernel project. However, it wasn’t open source software. While Linus Torvalds liked BitKeeper and adopted it, he couldn’t continue to use it due to backlash from the kernel core team. 

Using a proprietary system was seen as misaligned with the principles of a flagship free project. There were other VCS available at the time, but none that met the performance requirements for a project as complex as the Kernel. 

Despite not actually wanting to7, Linus decided to write his own tool, and ended up launching Git within two weeks. He described git as "the stupid content tracker". 8

The rest, as we know, is history.

Special thanks to Tyler Von Harz for his contributions to this article.