I'm going to check out Zig because of your response.
I love coming across comments like this one on HN.
I wrote about cross-compiling to a raspberry-pi and writing a barebones driver for an OLED display[^1]
That was a lot of fun despite the fact the code was incredibly basic. The interop with C was effortless.
[^1] https://www.kamelasa.dev/posts/gettin-ziggy-with-it-pi-zero....
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
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.
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.
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.
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_...