Elm is kind

Why is Elm good? Is it because:

• It’s delightful?
• It creates no runtime exceptions?
• You can refactor fearlessly?
• It has friendly error messages?

These are all true. But I think more than anything, it’s because Elm is kind.

When I read a function annotation in Elm, I know, at a glance, exactly what that function can and can’t change in my program state.

And I know it will always behave the same way with the same inputs.

So my Elm code is easy to think about.

I can refactor huge parts of my application’s design confidently and it still works.

And the design of the Elm package system means I can upgrade my dependencies and be sure they will still work.

So the foundation of my Elm application is stable.

Elm’s technical innovation was to bring ideas from the ML family of languages to front-end web dev, which had mostly just seen various elaborations on JavaScript.

But I think the real innovation is in the considerate spirit of its design.

As projects get complicated, they get harder. There are more and more things to think about.

That’s hard enough—writing code shouldn’t be any harder than it needs to be.

All of these design choices in Elm follow logically from that idea.

Being smart is a big expectation of the job of writing code.

And we as programmers are sometimes reluctant to admit that there’s only so smart we can be.

But we all have our mental limits, and Elm is considerate of them.

Using Elm gives me the feeling that i’m working with someone patient, smart, and sympathetic.

So more than any other design feature, I like that Elm’s designed with an understanding that software is hard.

And it’s designed to do all it can to make it as easy as it can be.

This post was originally a Twitter thread as part of Ship 30 for 30.