Putting Down Elm (opens in new tab)

Not the author but I've had similar experiences. I haven't used Haskell or OCaml in my day job (though I would like to if given the opportunity). I have written some trivial and slightly serious programs in both of these languages. I've even worked up a few small programs in Agda.

Elm, IMHO, is in a class of its own. There's a strong focus in the design of the language to be usable and friendly to the developer. The focus on structural typing, the error messages, and the tooling all go a long way to bring the developer from beginner to expert with as little friction as possible.

In contrast I find this is the biggest hurdle for Haskell and OCaml. It's simple enough in either language to get started but there's a steep learning curve to becoming productive and the tooling, documentation, and even the design of the prelude libraries are the largest stumbling blocks for transitioning from an intermediate developer to an advanced one.

update: grammar

> Is there something special about Elm that gives you this kind of benefit

Evan cares about compiler messages, and as a result Elm's compiler errors are the most friendly, readable, helpful and actionable messages I know of, even compared with projects with good error messages like Clang or Rust.

Most other typed functional languages don't come even remotely close, best case scenario is they're fairly complete once you've learned to decrypt them, Elm's compiler error messages have almost no learning curve. Though it may help that Elm is wilfully limited abstraction-wise.

I've used typed languages, and pure ones, but what I've found to be really special about Elm is that the compiler is super helpful. This also makes learning the language really enjoyable, as you've got someone helping you along. :)

Haskell does the same thing.

EDIT: I didn't mean to say that Haskell is as easy, or that the error messages are as good. I just mean that the error messages can give you a nice reminder of what you were working on, which I believe was the point of this post.

Without having used Elm that much myself: One of its features is its very user friendly error messages. I imagine the author is comparing with more dynamically typed languages, where when you leave your work in the middle of something, there's usually a bit of digging when reopening it and continuing work, which he contrasts with Elm, where the compiler is quite excellent at reporting your unfinished work (in the form of helpful type errors), allowing you to quickly grasp at what point in your program you were at.

Exactly what I wanted to ask. Can we mere developers have some context to it?

It's just "Elm is good and other languages are bad/not as good". I try to be live-and-let-live about such things.

I'm not sure this is a fair criticism. The nice thing about this tiny chunk of code is that there is only one aspect of this example program that needs to manipulate the already instantiated DOM, and that tiny chunk is explicitly brought up to the top level and separated and connected back to the program via the port mechanism. It would certainly be worse if this magic happen behind the scenes.

Of course it could be better, and that's probably what you are getting at. Ideally the machinery provided for building web applications would be more aware of the nature of web applications and have something in the box (still explicit and obvious, but in the box) to do something like setting focus.

This is certainly annoying at the moment (although there are workable hacky solutions). However it's a well known issue and there is movement at https://github.com/elm-lang/html/issues/19 so hopefully it will be addressed in the near future.

Elm gives you the ability to hook into requestAnimationFrame, which allows you to execute some native js through a port when a piece of html first renders.

I have the same issue on React components as well. Had to implement setTimeout in componentDidMount.

I think "gradual typing" like Flow might be a nice middle-ground.

You're still free to quickly sketch out ideas without worrying about type checking, but you can solidify things by just adding /* @flow */ to the top of a file and fixing the errors.

I haven't actually tried Elm though, so maybe a "middle-ground" isn't necessary.

I think this is a case where the topic is something that enough people want to discuss so the post generates discussion regardless of the content.

I agree with the basic gist of your comment, there isn't much content here to discuss (no offense to the author, it doesn't seem like it was meant for a site like HN). Though I think you might be over-reacting a bit with the tone of your comment.

In the time it took you to write your content-free comment, you could've googled Elm and seen the error messages yourself.

The error messages in Elm really are outstanding. I've never used a language that has such clear, concise, and human-friendly error messages. It's a high water mark, and I hope other programming languages are inspired to try to equal what Elm has accomplished.

I literally had to read it 5 times before realizing it's not a dismissal of Elm.

I guess the only new addition is that a side-effect of the very helpful errors is that it's easy to eventually come back to your work later on.

There's also a lot less state to keep in your head, as it's usually a lot more transparent.

It makes other people (like me) interested in Elm