Elm's Value Proposition

Many developers who try out programming in a functional programming language describe it as an “a-ha” moment and begin to look for and make opportunities to use functional languages. However, CTOs and other technical leaders often approach these languages with trepidation or dismissal. Are the benefits of functional languages truly worth the investment in increased training and costlier hiring?

Fortunately, the creator of the Elm programming language, Evan Czaplicki, has spent many years thinking deeply about these questions, most recently in a series of keynote addresses, A Decision-Maker’s Guide to Typed Functional Languages, Rethinking Our Adoption Strategy, and How to Grow Functional Programmers. This article will be a summary of some of the ideas presented in those talks.

The Trade-Offs of Choosing an Esoteric Language

When choosing a language like Elm, OCaml, F#, or Haskell, the amount of time spent on bug fixes and testing generally goes down. One additional benefit of adopting functional languages that is often overlooked is an improvement in retention. Developers who have a strong preference for working with a particular language will be much more likely to stay with a team using that language, given the relatively low number of other functional programming jobs available.

Benefits

• Fewer bugs
• Less time on testing
• Increased retention

For some scenarios, these benefits may not be compelling. When teams choose the same tools as everyone else, they get the same error rate, performance, and hiring pool as everyone else. Some businesses will see significant value from improving their error rate, but others do not hold the quality of their software as their business’ limiting factor. Breaking out from the norm makes sense when the specific benefits outweigh the risks. Elm is a great choice for frontends where quality and productivity are significant drivers.

Concerns

• More hiring difficulties
• Higher onboarding costs

One of the biggest concerns with choosing a less-popular language is the cost of hiring experienced developers and the cost of training inexperienced developers. Some companies will develop hiring relationships with universities that teach functional programming (e.g. Jane Street recruits heavily from Harvard, Princeton, Cornell, and Brown).

However, this is an area where Elm, in particular, shines. Companies using Elm report that developers without Elm experience get fully onboarded in about four weeks. When compared to the ramp-up time required to learn the ins and outs of the peculiarities of any team’s approach to their React stack, it seems that the simplicity of Elm almost eliminates this major objection to using a functional language. In fact, multiple of the business interviewed for A Decision-Maker’s Guide to Typed Functional Languages mentioned non-engineers being able to interact with Elm code (e.g. writing custom interactive visualizations for Brilliant).

Why is Elm quick to learn?

Elm is intentionally a simple language, only taking the “greatest hits” of features from its ancestors. In addition to making it a great target for tooling, it also means that the learning curve is small. There’s also a pragmatic focus in both the official training materials and throughout the Elm community.

Elm also set the standard for friendly compiler errors, pioneering the idea of compilers as assistants. These error messages teach syntax and provide wider guidance (in a way that continues to be helpful even to experienced developers).

What if I want to use a more complicated language?

So, that’s great for teams taking a bet on Elm, but, since Elm is a frontend focused language, that doesn’t seem to help teams that want to use functional programming on the server (notwithstanding the existence of Lamdera and elm-pages as options for full-stack Elm applications).

The trick, as Evan discusses in How to Grow Functional Programmers, is to use Elm as a bridge to these other languages. It’s a tall order to ask a JavaScript or Ruby developer to adopt Haskell, but the path from those languages to Elm is much easier, and then the path from Elm to Haskell (or OCaml, F#, Scala, etc.) is much more manageable. It may seem counterintuitive, but choosing a more niche collection of technologies can provide more success than just adding in a functional language to an otherwise standard stack.

How to Adopt Elm

Elm is designed to make it easy to experiment with incremental adoption. Start with a small project as an experiment and embed it within your React (or whatever) application. Measure the upfront and maintenance costs in comparison with similar projects. Identify a champion to lead the effort (maybe as a carrot to engage the Elm fan on the team). If there’s not an obvious champion, consider adding Elm experience as a nice-to-have when interviewing for React skills. Notice how long it takes inexperienced developers to become effective on the new Elm experimental team. Expand as success becomes clear.

Conclusion

To get the benefits of functional programming on a development team (examples could include 20% faster feature delivery, 60% less time on tests and bug fixes, 15% longer developer retention), experiment with adding Elm. Be willing to hire inexperienced developers and keep track of the onboarding and training investment. When the benefits become obvious, use Elm as a bridge to getting those same benefits on the server from a similar language.

At Engage, we’ve used Elm to deliver many successful projects and products over 10+ years via a variety of developers at different knowledge and skill levels. We’d love to be the expert in your corner to get your team experiencing the unique benefits of pure, typed, functional programming on the frontend.