[earth_walker]

There really isn't any call to trash Elm and its creator like this.

There's very little evidence of ongoing hostility from Evan - I pay attention to his work and writings and find he's rarely if ever hostile. In fact he's very mild-mannered, and is painstakingly detailed about explaining the reasons for why he does things the way he does, over and over again.

Perhaps that wore thin once or twice in the face of repeated criticism and demands. We've all seen way worse.

Yes, sticking to his vision has excluded ideas and contributions, and made some people very angry. There have been several high profile blogposts and twiits painting him as some kind of despot. And when other overzealous developers swooped in to defend his work, it just fed the meme, one which people on HN like to repeat every chance they get.

Well, I for one am glad he's a 'code despot' - considering how many people keep demanding that they dilute Elm's guarantees for the sake of JS library interop or marginally less boilerplate. Any bending to these demands and Elm today would be just another framework with a slightly different syntax, with none of guarantees that allow for the innovative tooling and libraries [1] we see coming out of the community.

Whether you agree with Evan's vision or not, Elm is doing just fine meeting its stated goals and is a fantastic and delightful technology and toolchain.

So please give over with trashing other people's hard work. If you don't like it, just don't use Elm.

[1] for example, the compiler's dead code elimination capabilities, elm-review's tco detection and other amazing auto-fixes, lamdera, etc.

[rk06]

Elm has done some great work, even the ones, who left elm for other tech, acknowledge elm's elegant design.

However, elm is not pragmatic. the issues mentioned in Luke plant's "leaving elm" [0] are valid. and Evan's response to that was far from satisfactory[1] and this has affected Elm's popularity.

The disagreement between BDFL and community has happened in many other cases as well. and there is a way to solve them amicably. Most recently, Vue faced it when community caused uproar over composition API RFC. and Vue solved it nicely and amicably[2]. If Elm has followed similar approach, Elm too would be praised for it, and gained even more popularity.

[0] https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/

[1] https://www.reddit.com/r/elm/comments/g070sz/evans_response_...

[2] https://dev.to/danielelkington/vue-s-darkest-day-3fgh

[ljm]

I think you're saying Evan is the BDFL (Benevolent Dictator for Life) for Elm, except it's interesting you chose the word 'despot' because many of the decisions made with Elm are far from benevolent (like preventing certain library usage and interop if the code isn't hosted on github, within the elm org).

The criticism is valid. Haskell is painfully strict and, still, it offers various ways out of its guarantees. Rust is painfully strict and gives you `unsafe`. Neither of them break your build if you don't host your code in a specific github org.

[earth_walker]

I purposely avoided 'BDFL': too much precedent as to what that means!

Limiting certain kinds of js access to vetted libraries is benevolent, if that's part of the language's goals. Likewise the lack of type classes or mutability/unsafe escape hatches.

Elm's developers do not enforce constraints to be 'hostile' or 'far from benevolant'. It's a tradeoff - language power for certain guarantees, guarantees that not even Haskell can provide.

Unfortunately, this sometimes means trying to constrain access to the completely unconstrained js library ecosystem, so the solution, at least for now, is a bit of a blunt weapon.

Note that Elm doesn't 'break your build' if you don't use github - that's a constraint on linking to official libraries only. I don't use github and my code works just fine.