I think you are right, but the way decisions are communicated in Elm are frustrating. There are lots of decisions like this, which in the end are just decisions, but can be frustrating if you are expecting a more complex language.

Even without talking about type classes, the lack of applicative is weird. I know: nobody understands what applicative is for, but if you have map and you are currying parameters, you're going to run into the issue ;-) Instead, you've got map, map2, map3, map4, map5 (which also, frustratingly, don't implement applicative). There are lots of validation scenarios that are just way more complex to do in Elm than they need to be.

But to be honest, it's fine because the language is not supposed to give you everything that you might want. It's geared for people who want a subset that's easy to learn. If I'm going to write code for myself in this space (functional language that compiles down to JS), I'm going to pick Purescript because it has everything that you're ever going to want. But if I'm choosing a language for my team that doesn't know functional programming and (to be blunt) doesn't really care to learn: Elm is a much better fit. They can learn just enough to get their work done.

But I just wish it was stated in those terms clearly. The premise of the article has been played out time and time again in the Elm community: "I thought this was a fully featured functional language, but when I tried to do this completely reasonable thing I got my hand slapped".

At every turn the response to, "Why can't I do X" is "Because you don't need to do X. It's much simpler to do without X" -- which usually isn't true. It's much simpler to learn something without X, but X is there to make your life much easier as long as you can deal with the complexity of learning it. It's the old "ease of use" vs "ease of learning" issue.

On the other hand, people need to learn to take no for an answer and move on.

Instead, egos get involved and a new essay of the week appears on how Elm is doomed because it doesn't have <pet feature>. That nobody can take Elm seriously if it doesn't have type-classes, synchronous FFI, derivable JSON codecs, component state, or whatever the pyre was built on that day.

If you didn't know better, you'd think they were disgruntled paying customers.

Elm's simplicity, lack of abstraction, and resulting boilerplate have more to offer than helping beginners learn. Nothing demonstrates this better than coming back to an old Elm application and immediately making meaningful changes to the code despite a long hiatus from using Elm at all.

There are a lot of languages that continually add features in this space like PureScript, ReasonML, and even TypeScript.

Why not see where Elm ends up with its aggressive devotion to a minimal API instead of trying to turn it into a language we already have?

Some of the best aspects of Elm come from its restrictive nature. Like how every Elm application uses the same "TEA" abstraction which is a breath of fresh air for anyone who never felt particularly empowered by the paralyzing abundance of options in the JS ecosystem nor the task of webpack-plumbing them together.

Nobody can take Elm seriously because having lines of code in Elm is a liability at this point.

If Evan hadn't wanted this to happen, he shouldn't have positioned it as the "beginner-friendly" language and then pulled the petty dictator routine out as soon as people were locked into his ecosystem.

> Nothing demonstrates this better than coming back to an old Elm application and immediately making meaningful changes to the code despite a long hiatus from using Elm at all.

Or... not having it compile because the BDFL (or, realistically, DFL) has decided to remove half the features it needed to compile.

That's not the takeaway that you should have - simplicity doesn't matter if minor language versions make breaks.

While I agree about it being ok to break things at this stage, some of the words in your reply were a bit confusing - what do you mean a "private unsupported API" in an open source project? Kind of supports the notion that this is a private group project and others can use it, but are not welcome to participate.

Also, if calling this a minor release is idiotic, why was the version number then a minor increase (at least according to commonly accepted understanding, i.e. semver) and not a 0.20 or whatever else, especially if there are breaking API changes.

GP probably meant something like "an internal API that's exposed in case you need it but gives no guarantees about stability because it's still evolving"

> Kind of supports the notion that this is a private group project and others can use it, but are not welcome to participate.

Native's existence was an implementation detail. no one using it didn't know it was likely to go away if they read anything about it from core. it was undocumented, but where you could find any documentation it said very clearly not to use it. people used it anyway. I was one. but I knew going in that it would likely disappear.

> why was the version number then a minor increase (at least according to commonly accepted understanding, i.e. semver) and not a 0.20 or whatever else, especially if there are breaking API changes.

https://semver.org/#spec-item-4

you not understanding semver doesn't make elm bad

Elm doesn't seem to use semver (which requires that "A normal version number MUST take the form X.Y.Z")

Clearly the internal API existed because Evan et al. decided they needed to use it. So why did they decide it a feature that was so obviously necessary was too complicated for the hoi polloi?

I asked upthread about native versus ports and somebody was kind enough to mention ports were async only.

But I'm still curious about exactly what people were using native for and why at least some users don't feel they can rewrite easily - care to share what you used and why, and what your thoughts are about replacing it?

(the discussion around this has, so far as I've been able to see, devoid of concrete examples, and now the question's nerd sniped me :)

In semver versions before 1.0 are prerelease versions.

No, "immaturity of the language" refers to Evan's tendency to make breaking changes for absolutely no good reason.

Use custom operators? Fuck you. Now go rewrite all the libraries you contributed to the community.