Field Report: Elm

A few years ago I took Elm for a spin.

Elm?

In brief, Elm is a functional language from the ML-family that compiles to javascript to run in the browser. It is at creating scalable web applications. Elm inspired parts of Redux. The mental models are similar.

The community does a great job explaining itself at http://elm-lang.org/

My experience is brief, but I liked what I saw.

I spent a couple days with Elm building the game ‘snake’. I find the game to be a good exercise for learning user input and events in a new language or tool. So I gave it a shot:

Success, sort of! I’m still working on it, but the code is available here.

Elm is an exciting project. It has a lot of things going for it. Many of the technical aspects have been laid out by Mr. Rishi Goomar in his post “Why I think Elm is the Future of Front End Development”.

I also see a lot of promise with Elm.

Developer experience is a first class citizen

My experience was that of fast feedback and minimal context switching. I was either looking at a compiler error or I was playing my game. Even though, I just picked it up, I felt like I could make meaningful progress at each step.

I was shocked that the claim of “no runtime exceptions” was actually true. When I introduced behaviors I wasn’t expecting, it was because my mental model was wrong (row, column vs column, row etc). There wasn’t side-effect-y bugs.

Because of the bold claim, I skipped writing tests. I wanted to see how it held up. No regressions. Each time I added a feature it stayed there.

Compiler messages are detailed and accurate. The only times I felt lost, I wasn’t reading the compiler message correctly. That’s the truth.

Shoutout to vscode and its elm plugin. Without configuration, these compiler messages start showing up as you write code without having to run a command or context switch to another window.

Elm has a stated goal to bring the benefits of functional programming to the masses. Which _requires d_eveloper user experience is a first class citizen. Elm delivers on that.

In the real world?

Is Elm academic (yes) or can it be used in the real world? Great question! Here are some of my thoughts.

Some companies are reporting big wins

Futurice reports their switch here. No Red Ink has been loud about their use since adoption. The topic is discussed in the beginning of the following Q&A Panel:

Limits talent pool?

A concern that I had was limiting the number of candidates to hire. Engineering teams need to grow, and if the pool of workers is small that can be a business problem. You have to either train or hire competitively. Interestingly enough, No Red Ink (in the video posted above) reports that after ‘being loud with their use of Elm’ the quality of candidates skyrocketed.

Isn’t that incredible? Limiting your candidate pool and the number of people you want to hire increases?

I find that fascinating. Paul Graham talked about this in his article, The Python Paradox. To me, it makes some clown sense. Great engineers want to work with great tooling, so they go to places where they can.

But /this is only true for a limited window of time./ In reference to the article, on a long enough timeline, python is the new java.

Similar to React/Redux

Since Elm is essentially React/Redux enforced at the language level, I can see a team gaining a lot of productivity. It is the same tool with better and faster feedback that prevents anti-patterns, without limiting what you can build.

The cost of switching could be pretty low. I have built a few apps in react and redux so I had a few hours of ‘oh this is that’ and then I was off to the races. I’d imagine that would be similar for a team used to react/redux.

Of course, rewriting an app from react/redux to elm would make little business sense. There’s a number of tools to piece-meal change over a react app, including a React component that runs an Elm app. (Or vice versa) So you can work in chunks.

Young language and has limited tooling

Elm is still figuring itself out. For example, in the v0.17 they changed the naming of a central concept from ‘Action’ to ‘Msg’ (Message). A small change, but a main part of the mental model (of the Html.App part of the language). It’s good to get that stuff right, of course, but reveals youth.

The tooling is great but since the project is only 4 years old, tooling can be sparse. For example, I used VSCode which was a nice experience, but lacked proper syntax grammar files so I stared at lots of white text with blue variable names. That will get better with time.

Getting stuck with Elm

My biggest concern would be adopting Elm and it being ‘over’. And now you have a codebase in a language that nobody uses.

Now it’s open source and the spec exists, so you can always write your own toolchain. But for very sound reasons, most web application shops don’t want to support a language. So, let’s say that adoption would depend on continued community or big-facebook-style-company support.

So let’s just count this one as an all around risk. While the community is vibrant and active (5k chatting away in the slack, active meetups, a conference), it is young and small so there’s a chance this all goes away.

That said, I think there’s /significant/ /competitive advantage/ to a business whose engineering team can reliably deploy web apps without errors or regressions. And Elm promises that.

Active friendly community

I mentioned the community above, but I want to highlight how big of an asset this is. Communities are great indicators of adoption + success.

I found the community to be warm, helpful and active. The documentation and tutorials are thorough, the modules to choose are (mostly) obvious. Help on the slack channel was fruitful and supportive. Answers to technical and design questions came quickly. Thanks, everyone!

(PS If you’re in SF there is a regular hack night this Wednesday. I’ll be there! Say hi!)

(PPS There is also remote meet up happening on Oct, 24th.)

Conclusion

I would like to try Elm out in a small app with a team to test these claims.

Currently, there’s not much incentive to move away from React/Redux. It works pretty well and we sorta, uh, just got here, man. There’s non-trivial risk in choosing Elm. So it doesn’t make sense to move to Elm wholesale. The push/pull thing doesn’t equal out. So that puts me in the camp of early adopter, and I’m okay with that. The benefits that are next-level.

With most of my time with Elm, I felt directed toward solutions and never stuck on problems. Feedback was instant, I never felt stuck. When I wanted to change the structure to fit the new problem, I just did it and returned the program to a working state.

Can you imagine the productivity of a whole team working with no runtime exceptions, minimal regressions and defect-free refactoring?

Happy building!