One year of Elm in production

About a year ago, I started a new job where I build tools aimed at helping others provide a better user experience. As is common in the software industry, I inherited lots of poor vanilla JavaScript code. There were no tests, very little code structure or code re-use, mixed coding styles and as expected, a full menagerie of bugs, which frequently cropped up resulting in very poor user experience. With such a sorry state of things, it only made sense to try to take a wholly different approach - stop writing JavaScript and instead pick a higher level language that would make sure all the things are kept in check.

As a functional programming enthusiast, I’ve been a keen user of Elm for some time and although I conceptually liked it better before version 0.17 with its higher-level abstraction of rendering visual elements contained in elm-graphics library, the inclusion of HTML library made it possible to integrate it into existing front-end ecosystem with much less friction to the point where it actually became one of the top choices.

If Elm code looks terrifyingly unfamiliar to you, fear not. It builds on top of very mature ML (Meta Language) family of programming languages. Elm itself is written in Haskell, which is as old as programming itself, but you can find a plethora of languages in this family:

As processors scaling predicted by Moore’s law is close to reaching its hard physical limits (as Herb Sutter famously put it the free lunch is over¹), the software industry will have to reach to tools that are better suited for dealing with concurrency. And these tools are functional programming languages. The interesting thing is that even if your application has no need to deal with concurrency, it can still benefit from FP, its foundation in mathematical concepts scares a lot people off, but it is its strong point. If the word mathematical puts you off, know that you don’t actually have to know about this to take advantage of it, just like you won’t fly off a rollercoaster if you don’t know its physics (anecdotally, it will probably be your last ride if the rollercoaster has been built with complete ignorance of physics).

As most of software development education and training focuses on OOP, there are lots of developers who get the impression that thinking about things in terms of objects is somehow natural. But the limitation of this mindset becomes very apparent in a very popular OOP topic - Gang of Four’s design patterns². It also becomes apparent when implementation becomes so complex that no one can or even wants to work with it anymore. But where does this complexity come from, is it intrinsic to the problem domain? Most programmers know that tight coupling between unrelated concepts creates problems, in the same spirit I would say that the interleaving of data with behavior inside classes can create more problems than it solves. The declarative nature of FP languages removes much of the incidental complexity, the elephant we’re dragging around³, introduced by imperative programs because we don’t need to think about execution to understand what is going on. In more conceptual words of professor Philip Wadler, some languages were discovered while others were invented⁴ and you can tell.

The nice thing about Elm is that the community that has formed around it is very inclusive and welcoming. The language itself is very beginner friendly, to the point where some mistake its simplicity for a toy language. Don’t make the same mistake though, because Elm is up there with big names such as React, in fact, it is much more a complete solution than React. The simplicity of Elm is rooted in hard work that has been put into its design.

Once you familiarize yourself with it, the Elm compiler will be your best friend. Its error messages are so clear and helpful that they’ve influenced other languages, such as Rust. The language comes with a package manager elm-package and the libraries released in Elm automatically adhere to semantic versioning. You can even use it to check what has changed between different versions of a given package. For interactive coding, there is elm-repl and elm-reactor. The performance of Elm generated code is great and when needed optimization is a simple function call away.

So far, Elm’s simple yet powerful design has helped us to stay focused on our goal of building a great product and we expect that the payoff will be even greater in the long run. At the moment, we have about 16k Elm lines of code in production, steadily translating pleasant development experience into pleasant user experience and we have more on their way.