9 ms·

In version 0.19, the core team hardcoded a whitelist into the compiler of which projects are allowed to use native code (which happened to basically be the core

In version 0.19, the core team hardcoded a whitelist into the compiler of which projects are allowed to use native code (which happened to basically be the core team's pet projects). This basically crippled the language beyond usability for everyone else. https://news.ycombinator.com/item?id=22821447 https://news.ycombinator.com/item?id=22821447 https://news.ycombinator.com/item?id=17842400 https://news.ycombinator.com/item?id=17842400 https://news.ycombinator.com/item?id=16510267 https://news.ycombinator.com/item?id=16510267 As for a replacement, I'd look towards Haskell. At a language level, it looks really similar to Elm, and it's been having a lot of work done towards being more practical on the Web lately, e.g., GHC 9.6 getting a WASM backend merged.

satvikpendem 4y ago
FYI use double newlines between paragraphs/links, otherwise it shows up as one line. I completely agree with you, the way the Elm team handled it was not conducive to collaborate usage of their language, it was more like only they wanted to use it fully.
matsemann 4y ago
[flagged]
- PragmaticPulp 4y ago
  > This is FUD. For any normal web app you don't need that functionality, just use the built in "ports" concept to interface with JS stuff. The change was handled extremely poorly. I only knew one team using Elm in production at the time. They went from being huge proponents of Elm to recommending against it after the 0.18/0.19 changes and drama upended a lot of their work. There may have been a "right" way to do things under the new version, but breaking major functionality in a minor release without warning is a sign that you don't really care about your users. Changes like this require discussion, warning, and long transition periods. It was bad enough that they got it wrong, but then Evan doubled down by dedicating the opening of his next conference talk to mocking the users who were unhappy about the changes: https://www.youtube.com/watch?v=uGlzRt-FYto https://www.youtube.com/watch?v=uGlzRt-FYto The part where he mocks a commenter for asking "Is Evan killing Elm's momentum?" is weirdly prescient, given that these events ultimately did mark the slowdown of the Elm community. Elm development came to a near halt about a year later. > And it being open source means nothing stops you from forking it and adding your own native modules. Reason no one has done it is it's no need, and doing thinga that way would break the promises the compiler makes about no runtime bugs. I disagree. Maintaining an in-house fork of a compiler just to accomplish what could be done with past versions isn't a reasonable suggestion. The reason people weren't maintaining in-house forks of the compiler just to keep their projects going was because that's a silly thing to do when you could just use any number of more reasonable mainstream projects that don't require such extreme lengths. It's weird to see people casually suggest "Just maintain a fork of the compiler" as a reasonable solution.
  - henearkr 4y ago
    If it's really just a "hardcoded whitelist" that causes trouble, said fork would truly be easy to maintain.
    - kadoban 4y ago
      Until they do some other halfbaked thing that's harder to follow along with. When people show you who they are, believe them the first time. Compilers are supposed to be boring, especially when your language has ~exactly 1. If you can't trust the people maintaining it, it's too much risk to take. Having to do an entire rewrite in a different language can easily kill a company or a project.
    - peteradio 4y ago
      Would you need to maintain a fork at all? Couldn't you obliterate the rule when building the compiler?
      - josephcsible 4y ago
        What's the difference between that and a fork?
        peteradio 4y ago
        One doesn't require a "community of maintainers", its an adhoc tool you use to get your own stuff done, every project has them what is one more?
    - Volundr 4y ago
      Until another change against the community interest comes along. You only trust the "benevolent dictator" for as long as they remain benevolent.
    - bitmapper 4y ago
      It would be, if the code wasn't so horrifically bitrotted at this point. GHC has changed a lot since Elm last got any meaningful update, and they decided to use unsafe GHC primitives everywhere that have no support guarantee. You have to fix a bunch of issues with the compiler source before it will even compile on a relatively new version of GHC.
- nirvdrum 4y ago
  Forking a compiler is a gigantic pain. None but the most hardcore would bother. It's far easier to give up pushing the boulder and go use something else, which I hazard to say many have done. Or, they see the difficulty in using ports for stuff and never even start using the language.
- zem 4y ago
  not sure if FUD or not, but i distinctly remember people saying that they feared to fork the compiler because they were threatened with being banned from all the official channels and fora if they did.
  - henearkr 4y ago
    How hard could it be to spin an anonymous fork though.
    - zem 4y ago
      if you're going through all the trouble of forking you want to build a community around your fork, so you're not the only one maintaining it.
      - henearkr 4y ago
        C'mon, it's forking a whitelist.
        Volundr 4y ago
        Once the maintainer has ignored all community feedback on said whitelist and then threatened said members of community for considering removing the whitelist, why in the world would you assume it'll remain "just a whitelist"?
        zem 4y ago
        no, i was around in the elm community at the time, and what people wanted to fork for was a better way to support native js code in their own projects. there was a bit more to it than just adding filenames to a whitelist.
- dhucerbin 4y ago
  Ports are not really a solution for rendering code. Obvious example is internationalization API. It’s not feasible to communicate back and forth through port every time you want to format a date. Some folks propose web components but that’s another can of worms. Increase in complexity and still no help from compiler.
  - madsbuch 4y ago
    > It’s not feasible to communicate back and forth through port every time you want to format a date. Why not? Is it code complexity or runtime inefficiency you are referring to?
    - dhucerbin 4y ago
      Actually both. Let's say that on desired page, you have three components with dates somewhere - date of article, dates of comments below and date of last login in the header. After some user action, you navigate to this page. In Elm terms that mean your Model updates and then your rendering functions will run. Only then you can see that you need to format dates - your rendering function should be responsible for formatting. Rendering function should be synchronous - so you need to return some string for date - "loading state" or default format. So user gets "flash of unformatted date". Now, you should somehow communicate with Port - that mean, send asynchronous message "format this date for me". (And sending messages in render function is not something really supported out of the box in Elm) Then Port comes back with response, you need to put this formatted value in your global Model (some kind of Dict from unformatted to formatted dates?) and that triggers another render with formatted value. In summary: - you have multiple render loops where one would be enough - you pollute your global Model with junk that could be easily derived - you introduce latency in rendering because Ports are asynchronous Ports are great for interaction - user clicks something, you can send command and wait for response and update your model. But there are a lot of cases where you want use synchronous, pure function from Javascript like Intl API.
      - madsbuch 4y ago
        So, the elegant way to solve this would be to use an Elm i18n library and just use ports to get the users region instead of formatting every single string. I understand that it is hard for a software developer to accept that these things need to be reimplemented, but it also seems to be a natural consequence of "up-typing" an entire eco system. I studied formal techniques for PL. A large portion of the work was in reimplementing existing things in Coq, HOL, etc. Not particularly interesting, but necessary to reach a mature ecosystem. I do undestand that this makes it a no-go for a lot of people until these things have been implemented. This is also natural.
- josephcsible 4y ago
  > And it being open source means nothing stops you from forking it and adding your own native modules. Reason no one has done it is it's no need, and doing thinga that way would break the promises the compiler makes about no runtime bugs. No, it's because one of the core team members made threats against everyone who said they were thinking of forking it: https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/#forkability https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/#forka...
  - satvikpendem 4y ago
    I've never seen such an openly hostile OSS maintainer team as Elm's.
    - ikiris 4y ago
      sveasoft
      - josephcsible 4y ago
        Sveasoft wasn't OSS.
        ikiris 4y ago
        Sure they were, they just didn't want to admit all their code was GPL.
  - wpietri 4y ago
    Wow, that is wild! And yes, that kind of thing can totally drive off contributors. Long ago I went to a local Scala unconference. At the time there were at least two popular web frameworks, and one of the authors was in attendance. [1] Chatting during one of the breaks, I asked him some question about his framework, something about testability of apps. He quickly grew enraged and shouted at me. I slunk off, wondering what I had done wrong. At the bar after the conference, a few different people apologized to me for his outburst. Not him, mind you, just other people. I was like, "Aha, I recognize this. He's a missing stair." [2] He was clearly an asshole to people on the regular, but the community just put up with it. That was the last time I went to a Scala event. Life's too short to put up with bullies, or people who accommodate them. [1] I no longer remember which framework or which author. [2] https://en.wikipedia.org/wiki/Missing_stair https://en.wikipedia.org/wiki/Missing_stair
- shp0ngle 4y ago
  Why do you even need to care about this as a user? And mind you this is a front end tool. They did a big change of stuff that people depend on, without consulting the community, and then doubled down, threatened people that wanted to fork, all with a weird passive-aggresive tome.
  - matsemann 4y ago
    You don't need to care about this as a user. That's my point. People at HN complain about elm things that won't affect you.
deleted 4y ago
[deleted]
EdSchouten 4y ago
Also the fact that their package manager is strongly coupled against https://package.elm-lang.org/ https://package.elm-lang.org/. There is no way to override it. This means that if that package site ever goes down, you will be left with an unbuildable project. Seems pretty risky to me.
- Pet_Ant 4y ago
  I mean you should be proxying/caching your repo anyway, non? Even just to save on bandwidth.
  - lmm 4y ago
    It's a lot more fiddly to do that if the package manager doesn't support you doing it. (In fact it might be impossible if it's using HTTPS)
  - Throw999999 4y ago
    No.
the_gipsy 4y ago
> This basically crippled the language beyond usability for everyone else. This is not true. You can argue that it was perhaps the downfall in terms of contributions and popularity. But you don't need native code for writing apps in Elm.
- imustbeevil 4y ago
  You don't need a hammer to hit a nail, but if you hand me a screwdriver I'm going back to Node.
- matsemann 4y ago
  [flagged]
  - the_gipsy 4y ago
    Yea, exactly. I have written a complete functional game in Elm, with multiplayer over websockets, push notifications and whatnot. It has daily users to this day. I never needed "native" code. Maybe some decisions were wrong, as I said. Elm is not popular today. But they are also right in some aspect: I don't need another TypeScript (but with weird syntax).
    - JoeyJoJoJr 4y ago
      Would you mind sharing a link to you game :)
  - danabrams 4y ago
    I’ve written quite a bit of elm professionally and it was an issue for me and was a contributing factor (but not sole factor) to leaving Elm behind. A viable solution to my problem in professional contexts would have been private packages, which I believe Gren supports, so perhaps Gren would be a solution today, but I’ve moved on. That said, what’s happening with Gren is interesting and I applaud it.
- fyzix 4y ago
  The fact that the maintainers made a whitelist for their projects disproves your point.
scottwick 4y ago
I've never used Elm or interacted with the community but reading some of those posts remind me that the B in BDFL is quite important.
- carapace 4y ago
  Evan's hella nice. Some folks just really really don't like being told "No." (There are comments upthread calling the Elm community "happy cult" because they said "no" so nicely!) The complaints you hear about Elm are pretty much all of the "Evan said no" ilk. What you don't hear is are actual bug reports, eh? People aren't kvetching about how their Elm apps broke, eh? That silence is deafening, once you listen for it. Elm works. It may be the Easy-Bake Oven of web dev, but the things it cooks are perfectly edible! (Following that metaphor, most JS frameworks, etc. produce muffins with bits of broken glass in them.)
  - edflsafoiewq 4y ago
    "Nice" and "benevolent" are not the same thing.
    - carapace 4y ago
      Do you have an actual point to make, or are you just being pedantic for fun?
      - xtian 4y ago
        Some of the most manipulative and self-serving people you’ll ever meet are “nice”.
        carapace 4y ago
        So, is that a claim you're seriously making about Evan? - - - - Not to be arch, but this whole line of discussion is uninteresting to me. I'm glad to discuss Elm, but I don't want to hear unfounded character assassination of a kid who's only guilty of being willing to say "no" to people who want to change his language in ways that he's not into. From my POV Elm stands as a serious challenge to the entire JS ecosystem. I keep asking, "What's the business value argument for not using Elm?" and no one has a good answer.
ambrozk 4y ago
Yep. And the core team has that "happy cult" vibe where they think that if they're (passive-aggressively) polite enough, they don't have to worry about anyone's opinion outside their insular little group. I tried to use it for a little project about a year ago, ran into some problems, and, searching around, found my problems were 1. not unique to me, and 2. were definitely not going to be solved by the language designers, despite a lot of people having the same suggestions. Their attitude is "either you design your app how we'd prefer you to or you don't use Elm at all." This doesn't work in any other technical project, but they think it's going to work for them for some reason.
- hitekker 4y ago
  "Happy cult" vibe is exactly how describe that faux-niceness they throw around. Thanks for coining that phrase.
- jopsen 4y ago
  Honestly, the boldness of the opinions is also what makes elm well designed. I never really used it, but I see plenty of other languages that are perhaps too much driven by consensus rather than vision.
  - mst 4y ago
    Opinionation is often useful but it's best implemented with an escape hatch of some sort for when you run into a sufficiently weird situation there's not actually a sensible way to deal with it. I don't particularly mind if a project holds their opinions sufficiently strongly that they mark the escape match big red letters with "BY USING THIS YOU ARE VOIDING YOUR WARRANTY, IF IT BREAKS YOU GET TO KEEP BOTH HALVES" and then tapping the sign any time somebody asks for support with using it, but it should still -exist-.
    - hgsgm 4y ago
      The escape hatch is Haskell. The only reason Elm exists is to remove escape hatches from Haskell.
    - 4y ago
dividedbyzero 4y ago
Does this still assume a separate TypeScript/React frontend or the like, or can you actually do the whole frontend in Haskell?
Chadtech_ 4y ago
You don't need native code to be productive in Elm. Elm is perfectly useable without it. Use of native code was not widespread before 0.19 anyway. I would know. I was working on a large native code project that was killed by 0.19. It sucked for me that my project could not continue, but, I can't say that it has made much of a practical difference when it comes to making software applications. My project was called "elm-canvas" and it was about providing canvas support. Since 0.19, other people have found implementations of the HTML canvas element that do not rely on native code (Like Joakin's great 'elm-canvas' https://github.com/joakin/elm-canvas https://github.com/joakin/elm-canvas). For my own HTML canvas based software projects, I have been able to find my own non-native code implementations that work pretty well. So, I think I faced a disproportionate amount of this problem, and I can't even say it has made much of a difference to my own productivity in Elm (and I have written a lot of Elm).

satvikpendem 4y ago

FYI use double newlines between paragraphs/links, otherwise it shows up as one line. I completely agree with you, the way the Elm team handled it was not conducive to collaborate usage of their language, it was more like only they wanted to use it fully.

matsemann 4y ago

[flagged]

PragmaticPulp 4y ago
> This is FUD. For any normal web app you don't need that functionality, just use the built in "ports" concept to interface with JS stuff. The change was handled extremely poorly. I only knew one team using Elm in production at the time. They went from being huge proponents of Elm to recommending against it after the 0.18/0.19 changes and drama upended a lot of their work. There may have been a "right" way to do things under the new version, but breaking major functionality in a minor release without warning is a sign that you don't really care about your users. Changes like this require discussion, warning, and long transition periods. It was bad enough that they got it wrong, but then Evan doubled down by dedicating the opening of his next conference talk to mocking the users who were unhappy about the changes: https://www.youtube.com/watch?v=uGlzRt-FYto https://www.youtube.com/watch?v=uGlzRt-FYto The part where he mocks a commenter for asking "Is Evan killing Elm's momentum?" is weirdly prescient, given that these events ultimately did mark the slowdown of the Elm community. Elm development came to a near halt about a year later. > And it being open source means nothing stops you from forking it and adding your own native modules. Reason no one has done it is it's no need, and doing thinga that way would break the promises the compiler makes about no runtime bugs. I disagree. Maintaining an in-house fork of a compiler just to accomplish what could be done with past versions isn't a reasonable suggestion. The reason people weren't maintaining in-house forks of the compiler just to keep their projects going was because that's a silly thing to do when you could just use any number of more reasonable mainstream projects that don't require such extreme lengths. It's weird to see people casually suggest "Just maintain a fork of the compiler" as a reasonable solution.
- henearkr 4y ago
  If it's really just a "hardcoded whitelist" that causes trouble, said fork would truly be easy to maintain.
  - kadoban 4y ago
    Until they do some other halfbaked thing that's harder to follow along with. When people show you who they are, believe them the first time. Compilers are supposed to be boring, especially when your language has ~exactly 1. If you can't trust the people maintaining it, it's too much risk to take. Having to do an entire rewrite in a different language can easily kill a company or a project.
  - peteradio 4y ago
    Would you need to maintain a fork at all? Couldn't you obliterate the rule when building the compiler?
    - josephcsible 4y ago
      What's the difference between that and a fork?
      - peteradio 4y ago
        One doesn't require a "community of maintainers", its an adhoc tool you use to get your own stuff done, every project has them what is one more?
  - Volundr 4y ago
    Until another change against the community interest comes along. You only trust the "benevolent dictator" for as long as they remain benevolent.
  - bitmapper 4y ago
    It would be, if the code wasn't so horrifically bitrotted at this point. GHC has changed a lot since Elm last got any meaningful update, and they decided to use unsafe GHC primitives everywhere that have no support guarantee. You have to fix a bunch of issues with the compiler source before it will even compile on a relatively new version of GHC.
nirvdrum 4y ago
Forking a compiler is a gigantic pain. None but the most hardcore would bother. It's far easier to give up pushing the boulder and go use something else, which I hazard to say many have done. Or, they see the difficulty in using ports for stuff and never even start using the language.
zem 4y ago
not sure if FUD or not, but i distinctly remember people saying that they feared to fork the compiler because they were threatened with being banned from all the official channels and fora if they did.
- henearkr 4y ago
  How hard could it be to spin an anonymous fork though.
  - zem 4y ago
    if you're going through all the trouble of forking you want to build a community around your fork, so you're not the only one maintaining it.
    - henearkr 4y ago
      C'mon, it's forking a whitelist.
      - Volundr 4y ago
        Once the maintainer has ignored all community feedback on said whitelist and then threatened said members of community for considering removing the whitelist, why in the world would you assume it'll remain "just a whitelist"?
      - zem 4y ago
        no, i was around in the elm community at the time, and what people wanted to fork for was a better way to support native js code in their own projects. there was a bit more to it than just adding filenames to a whitelist.
dhucerbin 4y ago
Ports are not really a solution for rendering code. Obvious example is internationalization API. It’s not feasible to communicate back and forth through port every time you want to format a date. Some folks propose web components but that’s another can of worms. Increase in complexity and still no help from compiler.
- madsbuch 4y ago
  > It’s not feasible to communicate back and forth through port every time you want to format a date. Why not? Is it code complexity or runtime inefficiency you are referring to?
  - dhucerbin 4y ago
    Actually both. Let's say that on desired page, you have three components with dates somewhere - date of article, dates of comments below and date of last login in the header. After some user action, you navigate to this page. In Elm terms that mean your Model updates and then your rendering functions will run. Only then you can see that you need to format dates - your rendering function should be responsible for formatting. Rendering function should be synchronous - so you need to return some string for date - "loading state" or default format. So user gets "flash of unformatted date". Now, you should somehow communicate with Port - that mean, send asynchronous message "format this date for me". (And sending messages in render function is not something really supported out of the box in Elm) Then Port comes back with response, you need to put this formatted value in your global Model (some kind of Dict from unformatted to formatted dates?) and that triggers another render with formatted value. In summary: - you have multiple render loops where one would be enough - you pollute your global Model with junk that could be easily derived - you introduce latency in rendering because Ports are asynchronous Ports are great for interaction - user clicks something, you can send command and wait for response and update your model. But there are a lot of cases where you want use synchronous, pure function from Javascript like Intl API.
    - madsbuch 4y ago
      So, the elegant way to solve this would be to use an Elm i18n library and just use ports to get the users region instead of formatting every single string. I understand that it is hard for a software developer to accept that these things need to be reimplemented, but it also seems to be a natural consequence of "up-typing" an entire eco system. I studied formal techniques for PL. A large portion of the work was in reimplementing existing things in Coq, HOL, etc. Not particularly interesting, but necessary to reach a mature ecosystem. I do undestand that this makes it a no-go for a lot of people until these things have been implemented. This is also natural.
josephcsible 4y ago
> And it being open source means nothing stops you from forking it and adding your own native modules. Reason no one has done it is it's no need, and doing thinga that way would break the promises the compiler makes about no runtime bugs. No, it's because one of the core team members made threats against everyone who said they were thinking of forking it: https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/#forkability https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/#forka...
- satvikpendem 4y ago
  I've never seen such an openly hostile OSS maintainer team as Elm's.
  - ikiris 4y ago
    sveasoft
    - josephcsible 4y ago
      Sveasoft wasn't OSS.
      - ikiris 4y ago
        Sure they were, they just didn't want to admit all their code was GPL.
- wpietri 4y ago
  Wow, that is wild! And yes, that kind of thing can totally drive off contributors. Long ago I went to a local Scala unconference. At the time there were at least two popular web frameworks, and one of the authors was in attendance. [1] Chatting during one of the breaks, I asked him some question about his framework, something about testability of apps. He quickly grew enraged and shouted at me. I slunk off, wondering what I had done wrong. At the bar after the conference, a few different people apologized to me for his outburst. Not him, mind you, just other people. I was like, "Aha, I recognize this. He's a missing stair." [2] He was clearly an asshole to people on the regular, but the community just put up with it. That was the last time I went to a Scala event. Life's too short to put up with bullies, or people who accommodate them. [1] I no longer remember which framework or which author. [2] https://en.wikipedia.org/wiki/Missing_stair https://en.wikipedia.org/wiki/Missing_stair
shp0ngle 4y ago
Why do you even need to care about this as a user? And mind you this is a front end tool. They did a big change of stuff that people depend on, without consulting the community, and then doubled down, threatened people that wanted to fork, all with a weird passive-aggresive tome.
- matsemann 4y ago
  You don't need to care about this as a user. That's my point. People at HN complain about elm things that won't affect you.

deleted 4y ago

[deleted]

EdSchouten 4y ago

Also the fact that their package manager is strongly coupled against https://package.elm-lang.org/ https://package.elm-lang.org/. There is no way to override it. This means that if that package site ever goes down, you will be left with an unbuildable project. Seems pretty risky to me.

Pet_Ant 4y ago
I mean you should be proxying/caching your repo anyway, non? Even just to save on bandwidth.
- lmm 4y ago
  It's a lot more fiddly to do that if the package manager doesn't support you doing it. (In fact it might be impossible if it's using HTTPS)
- Throw999999 4y ago
  No.

the_gipsy 4y ago

> This basically crippled the language beyond usability for everyone else. This is not true. You can argue that it was perhaps the downfall in terms of contributions and popularity. But you don't need native code for writing apps in Elm.

imustbeevil 4y ago
You don't need a hammer to hit a nail, but if you hand me a screwdriver I'm going back to Node.
matsemann 4y ago
[flagged]
- the_gipsy 4y ago
  Yea, exactly. I have written a complete functional game in Elm, with multiplayer over websockets, push notifications and whatnot. It has daily users to this day. I never needed "native" code. Maybe some decisions were wrong, as I said. Elm is not popular today. But they are also right in some aspect: I don't need another TypeScript (but with weird syntax).
  - JoeyJoJoJr 4y ago
    Would you mind sharing a link to you game :)
- danabrams 4y ago
  I’ve written quite a bit of elm professionally and it was an issue for me and was a contributing factor (but not sole factor) to leaving Elm behind. A viable solution to my problem in professional contexts would have been private packages, which I believe Gren supports, so perhaps Gren would be a solution today, but I’ve moved on. That said, what’s happening with Gren is interesting and I applaud it.
fyzix 4y ago
The fact that the maintainers made a whitelist for their projects disproves your point.

scottwick 4y ago

I've never used Elm or interacted with the community but reading some of those posts remind me that the B in BDFL is quite important.

carapace 4y ago
Evan's hella nice. Some folks just really really don't like being told "No." (There are comments upthread calling the Elm community "happy cult" because they said "no" so nicely!) The complaints you hear about Elm are pretty much all of the "Evan said no" ilk. What you don't hear is are actual bug reports, eh? People aren't kvetching about how their Elm apps broke, eh? That silence is deafening, once you listen for it. Elm works. It may be the Easy-Bake Oven of web dev, but the things it cooks are perfectly edible! (Following that metaphor, most JS frameworks, etc. produce muffins with bits of broken glass in them.)
- edflsafoiewq 4y ago
  "Nice" and "benevolent" are not the same thing.
  - carapace 4y ago
    Do you have an actual point to make, or are you just being pedantic for fun?
    - xtian 4y ago
      Some of the most manipulative and self-serving people you’ll ever meet are “nice”.
      - carapace 4y ago
        So, is that a claim you're seriously making about Evan? - - - - Not to be arch, but this whole line of discussion is uninteresting to me. I'm glad to discuss Elm, but I don't want to hear unfounded character assassination of a kid who's only guilty of being willing to say "no" to people who want to change his language in ways that he's not into. From my POV Elm stands as a serious challenge to the entire JS ecosystem. I keep asking, "What's the business value argument for not using Elm?" and no one has a good answer.

ambrozk 4y ago

Yep. And the core team has that "happy cult" vibe where they think that if they're (passive-aggressively) polite enough, they don't have to worry about anyone's opinion outside their insular little group. I tried to use it for a little project about a year ago, ran into some problems, and, searching around, found my problems were 1. not unique to me, and 2. were definitely not going to be solved by the language designers, despite a lot of people having the same suggestions. Their attitude is "either you design your app how we'd prefer you to or you don't use Elm at all." This doesn't work in any other technical project, but they think it's going to work for them for some reason.

hitekker 4y ago
"Happy cult" vibe is exactly how describe that faux-niceness they throw around. Thanks for coining that phrase.
jopsen 4y ago
Honestly, the boldness of the opinions is also what makes elm well designed. I never really used it, but I see plenty of other languages that are perhaps too much driven by consensus rather than vision.
- mst 4y ago
  Opinionation is often useful but it's best implemented with an escape hatch of some sort for when you run into a sufficiently weird situation there's not actually a sensible way to deal with it. I don't particularly mind if a project holds their opinions sufficiently strongly that they mark the escape match big red letters with "BY USING THIS YOU ARE VOIDING YOUR WARRANTY, IF IT BREAKS YOU GET TO KEEP BOTH HALVES" and then tapping the sign any time somebody asks for support with using it, but it should still -exist-.
  - hgsgm 4y ago
    The escape hatch is Haskell. The only reason Elm exists is to remove escape hatches from Haskell.
  - 4y ago

dividedbyzero 4y ago

Does this still assume a separate TypeScript/React frontend or the like, or can you actually do the whole frontend in Haskell?

Chadtech_ 4y ago

You don't need native code to be productive in Elm. Elm is perfectly useable without it. Use of native code was not widespread before 0.19 anyway. I would know. I was working on a large native code project that was killed by 0.19. It sucked for me that my project could not continue, but, I can't say that it has made much of a practical difference when it comes to making software applications. My project was called "elm-canvas" and it was about providing canvas support. Since 0.19, other people have found implementations of the HTML canvas element that do not rely on native code (Like Joakin's great 'elm-canvas' https://github.com/joakin/elm-canvas https://github.com/joakin/elm-canvas). For my own HTML canvas based software projects, I have been able to find my own non-native code implementations that work pretty well. So, I think I faced a disproportionate amount of this problem, and I can't even say it has made much of a difference to my own productivity in Elm (and I have written a lot of Elm).