> ...I can assure you there is already a very large fire under my ass to get this shipped ... [followed by a short, easy-to-follow explanation as to why it's taking so long]
I'm going to check out Zig because of your response.
I love coming across comments like this one on HN.
Yeah I watched a couple of his talks, enjoyed every word. There is another interesting language (won't mention the name) but the creator won't let the public in and has a superiority complex, turned me off instantly. I believe Zig will blow up just because of the strong vision but without being a dick about it. It's next on my list for sure.
I feel Elm's growth has been stunted because the creator is actively hostile with whoever disagrees with him. I remember the infamous "leaving elm" post which was handled so poorly by Elm's author.
If they had handled it well, elm would have definitely seen a large uptick in adoption
Parent poster 99% is referring to Jai. I'm of the same general opinion: interesting language, I've spent a lot of time watching jblow talk about it on Twitch, and it would be nice if it succeeded, unfortunately I have my doubts given jblow's attitude both in terms of external communication and within the development team [0].
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.
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.
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.
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.
I'm going to check out Zig because of your response.
I love coming across comments like this one on HN.