8 ms·

The year in this link is very important. In the following year, the Elm team decided to not pay attention to the maxim "perfect is the enemy of good" and crippl

The year in this link is very important. In the following year, the Elm team decided to not pay attention to the maxim "perfect is the enemy of good" and crippled their FFI story, making it impossible to actually use the language in production[1]. I would recommend to steer clear of a language that makes these sorts of decisions -- that certain features are off-limits to the regular developer because they can't be trusted to use them correctly -- because if you find yourself in a situation where you need that to solve your problem, you're trapped. I included Go in the set of languages I would recommend steering clear of for years, due to their decision to allow their own `map` type be a generic[2] type but no user-defined types could be[3], leading to ridiculously over-verbose codebases, but they have finally corrected course there. If you're looking for something kinda like Elm but not likely to break your own work in the future, I'd recommend checking out ReasonML[4] instead. [1]: https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/ https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/ [2]: https://go.dev/blog/maps https://go.dev/blog/maps [3]: https://go.dev/doc/faq#beginning_generics https://go.dev/doc/faq#beginning_generics [4]: https://reasonml.github.io/ https://reasonml.github.io/

hombre_fatal 3y ago
I have to agree that this is FUD. So, it’s impossible to use the language in production because FFI is async (ports)? lol, come on guys.
ambrozk 3y ago
It's incredible that on just about every piece I've ever read about Elm since they made that decision, this has been the first, second, and third comment. Wanting to try Elm for myself, I disregarded this advice, and.... immediately ran into the exact same problem! I've never seen such a promising project so conclusively killed by pure developer pigheadedness. And, amazingly, they've never backed down at all. They don't seem to mind that they maimed themselves.
- pavlov 3y ago
  A purity pledge is very typical of cults. It's both a filter and an enforcement mechanism. This may not apply to Elm. But I imagine it can feel easier and more rewarding to manage a community that's more like a cult than a typical free-for-all open source project.
  - truculent 3y ago
    I think it’s probably harder and less rewarding to manage a community where you’re constantly taking flak for a technical decision people don’t like (and which those people generally don’t engage with the pros and cons of said decision!)
- savanaly 3y ago
  Out of curiosity, what did you try to do that you hit that issue right away? I've been writing Elm apps as side projects for years, and never even come close to the kernel thing being a problem. My apps are mostly graphically undemanding games and helper tools. What are the types of applications where this becomes an issue right away?
  - matsemann 3y ago
    Most likely they didn't understand Ports and immediately wanted to reach for kernel stuff.
    - ghusbands 3y ago
      It's odd and rude to declare someone incompetent from so little information. Especially when the same problem is widely reported by other developers.
  - lolc 3y ago
    In my case, it was a regex supplied by the user. Elm 0.18 had no support for constructing a regex at run-time. So I made a package that wraps native RegExp. When 0.19 was released, I couldn't upgrade because of those 5 lines. The regex package eventually got regex.fromstring(). So I could've upgraded. But at the time I was bumping against limits accessing Intl and I really hated the prospect of begging some maintainer for access to a browser api. Elm was the most fun I ever had developing a browser app. Then they decided I shouldn't be allowed to develop a ShootMyFoot module, and it stopped being fun overnight.
    - savanaly 3y ago
      Yeah, I really feel this a good way to divide developers into two types. There are those like me, to whom the philosophy of discourage foot guns systematically sounds kind of brilliant. To put it in flattering terms, it's pay a short term cost for the long term and hard-to-perceive but very real benefits (making certain categories of errors completely extinct). To put the other side in flattering terms: they're not letting the perfect be the enemy of the good, and never compromising on their vision because the tech is holding them back. I think the latter is definitely dominant in the discipline. I'm glad that at least Elm carries the torch for the former though.
ordinaryradical 3y ago
Reason is a lovely, OCaml-esque language in the same functional vein, but I would say Gren feels like a great spiritual successor to Elm. https://gren-lang.org/ https://gren-lang.org/
- josephcsible 3y ago
  Gren is a fork, not a spiritual successor. And not only did it not fix that problem, it made it worse: https://news.ycombinator.com/item?id=36275171 https://news.ycombinator.com/item?id=36275171
  - matsemann 3y ago
    Perhaps because it's not the big problem a few people make it out to be..
  - ordinaryradical 3y ago
    Yeah, I just read this further down in this topic. Really bummed about it, Elm always seemed so promising, and I thought a healthy fork was what was needed. I just don’t understand the reasoning for this choice.
- terminatornet 3y ago
  along those lines, Zokka is a fork of elm that appears to be mostly dedicated towards bug fixes that Evan (the creator of elm) refuses to acknowledge or merge. https://github.com/Zokka-Dev/zokka-compiler https://github.com/Zokka-Dev/zokka-compiler edit: there's also Roc, https://www.roc-lang.org/ https://www.roc-lang.org/, a language started by Richard Feldman who I believe was a former elm core team member. I think Roc aims to accomplish different things than elm, but definitely feels like a spiritual successor
  - josephcsible 3y ago
    The commitment to bidirectional compatibility means that Zokka can't fix the problem that GGP was talking about.
matsemann 3y ago
> making it impossible to actually use the language in production Just FUD. I've been on a big team writing a webapp used by hundreds of thousands each day. While it's not necessarily my own first choice, it was great and the least error prone piece of software I've written in my career.
- ISV_Damocles 3y ago
  It is impossible if you're being responsible. You don't choose a technology that could potentially block you from solving problems in the future unless it brings a huge value to you. Elm's value proposition is mostly being a functional language with an opinionated MVU library baked in, so you can reproduce that value with a better functional language and selecting a similar MVU library in that other language, which means it should never actually cross the value bar above the risk it brings if you need a browser feature it doesn't support and actively prevents you from accessing.
  - matsemann 3y ago
    Now you're moving the goalpost. You said it was impossible to use in production. Which is clearly wrong.
    - ISV_Damocles 3y ago
      I am just clarifying why I consider it impossible. Production is not some place you're supposed to cowboy code, but instead have a reasonable expectation that you will be able to continue supporting it for as many years as it operates, and it's impossible for anyone to responsibly use technology with known limitations that have bitten other real engineering teams that they can find zero workarounds for. If you don't consider that an impossibility for a production environment, then I certainly wouldn't want to work with you on a team with production responsibilities.
      - matsemann 3y ago
        [flagged]
troupo 3y ago
ReasonML crippled themselves, too, by splitting the already tiny community between Reason and ReScript Here's a good (neutral!) write-up: https://ersin-akinci.medium.com/confused-about-rescript-rescript-reason-reasonml-and-bucklescript-explained-ab4230555230 https://ersin-akinci.medium.com/confused-about-rescript-resc...
klabb3 3y ago
> I would recommend steering clear of [Go] for years, due to their decision to allow their own `map` type be a generic[2] type but no user-defined types could be[3] I think this is very, very different. First because Go didn’t have a cultish purist aversion to generics, banning people, going after them even outside of community spaces. But on a technical side, maps (and slices and channels) were not gated to be used by std, they were publically available to anyone. Not having generalized a feature is not the same as banning it. There was not even Go syntax to express it. Same as arrays in C, no? That said, I’m not challenging the recommendation to stay away or not - generics was (and still is, may I add!) quite a pain point with the language. I’m personally quite invested for other reasons (concurrency, networking, std lib), but people come to different conclusions naturally.
huy-nguyen 3y ago
If you’re a front-end developer, you should checkout ReScript[1], supposedly a JS-oriented successor of ReasonML and developed by the ReasonML team. [1] https://rescript-lang.org/ https://rescript-lang.org/
kriiuuu 3y ago
If you want to try TEA, but not Elm I reccomend Scala.js with Tyrian[1]. Scala.js is a wonderful, mature project and Tyrian gives you the elm architecture in a very pragmatic way. [1]: https://tyrian.indigoengine.io/ https://tyrian.indigoengine.io/
- lf-non 3y ago
  Are you actually using this in a non-trivial application? The recurring complain I hear about scala are the bad compile times. I haven't used the language much, so not sure if this only applies to libraries that heavily use compile time metaprogramming. But I really love that with modern tooling we can get a sub-second editor->browser feedback loop even for a three year old medium-large project on modern hardware. This was primarily one of the reasons I avoided Kotlin+Gradle JS target because among other issues the feedback loop was 2-3x slower.
  - kriiuuu 3y ago
    I have a medium sized project with it and the initial compile can be slow, however every recompile usually has the page updated as I switch from my editor to it. Not as fast as TS, but worth it for the much better programming language. Tyrian also makes it trivial to set up hot-reload with preserved state.
    - lf-non 3y ago
      Ok, this is interesting. I'll try this out in a small project.
z5h 3y ago
“making it impossible to actually use the language in production” Absolutely false.
- ISV_Damocles 3y ago
  Please refer to my comment here: https://news.ycombinator.com/item?id=39551017 https://news.ycombinator.com/item?id=39551017
marc136 3y ago
If time is important to you, please correct your statement. > The year in this link is very important. In the following year, the Elm team decided to [...] The blog post was released a year after the official release of Elm 0.19 where the access to native code was further restricted in the official compiler. It was not something that happened without ample prior notice, see for instance a post [1] by the Elm language creator in March 2018 in which he explains his reasoning for the upcoming change. Or another in March 2017 where he announced that intended change [2]. Even in 2015 he actively discouraged people to rely on these undocumented features and other hacks [3]. I also was not happy with that choice and felt the pain of something being taken away that was possible before, but that didn't stop me from using Elm at work nor from using it for fun. So far I haven't found an alternative that I liked better, so I will stick to it. [1]: https://discourse.elm-lang.org/t/native-code-in-0-19/826 https://discourse.elm-lang.org/t/native-code-in-0-19/826 [2]: https://groups.google.com/g/elm-dev/c/bAHD_8PbgKE/m/X-z67wTdCAAJ https://groups.google.com/g/elm-dev/c/bAHD_8PbgKE/m/X-z67wTd... [3]: https://groups.google.com/g/elm-dev/c/1JW6wknkDIo/m/H9ZnS71BCAAJ https://groups.google.com/g/elm-dev/c/1JW6wknkDIo/m/H9ZnS71B...
abrookewood 3y ago
Sorry, but what is FFI???
- josephcsible 3y ago
  Foreign function interface
cdelsolar 3y ago
I’ve been working with Go for 10 years and I have no idea what you mean by maps being generic before generics came along, nor did maps ever cause me to have over-verbose code bases. The links didn’t seem to help.
- ghusbands 3y ago
  Trying to summarise what they were likely saying: Not having generics makes code verbose because you end up copying and pasting your library code to make it handle different types. The complaint about maps being generic was that the Go team clearly saw a need for generics (as they implemented them for maps and some other types) but decided that others wouldn't need them. So they had one rule for them and another rule for everyone else, which people don't like.
  - cdelsolar 3y ago
    How were maps generic before generics, I am not sure I understand. Didn’t you still have to declare them as map[type1]type2?
    - ghusbands 3y ago
      So when something is generic, it means it is a type parameterized by other types. So the type map[string]int is indeed generic, but no language users could create their own type btree[X]Y, for example. Essentially, the go developers saw a need for generics and then decided that only they get to create them, where most modern language developers either make them available for everyone to implement or don't add them at all.

hombre_fatal 3y ago

I have to agree that this is FUD. So, it’s impossible to use the language in production because FFI is async (ports)? lol, come on guys.

ambrozk 3y ago

It's incredible that on just about every piece I've ever read about Elm since they made that decision, this has been the first, second, and third comment. Wanting to try Elm for myself, I disregarded this advice, and.... immediately ran into the exact same problem! I've never seen such a promising project so conclusively killed by pure developer pigheadedness. And, amazingly, they've never backed down at all. They don't seem to mind that they maimed themselves.

pavlov 3y ago
A purity pledge is very typical of cults. It's both a filter and an enforcement mechanism. This may not apply to Elm. But I imagine it can feel easier and more rewarding to manage a community that's more like a cult than a typical free-for-all open source project.
- truculent 3y ago
  I think it’s probably harder and less rewarding to manage a community where you’re constantly taking flak for a technical decision people don’t like (and which those people generally don’t engage with the pros and cons of said decision!)
savanaly 3y ago
Out of curiosity, what did you try to do that you hit that issue right away? I've been writing Elm apps as side projects for years, and never even come close to the kernel thing being a problem. My apps are mostly graphically undemanding games and helper tools. What are the types of applications where this becomes an issue right away?
- matsemann 3y ago
  Most likely they didn't understand Ports and immediately wanted to reach for kernel stuff.
  - ghusbands 3y ago
    It's odd and rude to declare someone incompetent from so little information. Especially when the same problem is widely reported by other developers.
- lolc 3y ago
  In my case, it was a regex supplied by the user. Elm 0.18 had no support for constructing a regex at run-time. So I made a package that wraps native RegExp. When 0.19 was released, I couldn't upgrade because of those 5 lines. The regex package eventually got regex.fromstring(). So I could've upgraded. But at the time I was bumping against limits accessing Intl and I really hated the prospect of begging some maintainer for access to a browser api. Elm was the most fun I ever had developing a browser app. Then they decided I shouldn't be allowed to develop a ShootMyFoot module, and it stopped being fun overnight.
  - savanaly 3y ago
    Yeah, I really feel this a good way to divide developers into two types. There are those like me, to whom the philosophy of discourage foot guns systematically sounds kind of brilliant. To put it in flattering terms, it's pay a short term cost for the long term and hard-to-perceive but very real benefits (making certain categories of errors completely extinct). To put the other side in flattering terms: they're not letting the perfect be the enemy of the good, and never compromising on their vision because the tech is holding them back. I think the latter is definitely dominant in the discipline. I'm glad that at least Elm carries the torch for the former though.

ordinaryradical 3y ago

Reason is a lovely, OCaml-esque language in the same functional vein, but I would say Gren feels like a great spiritual successor to Elm. https://gren-lang.org/ https://gren-lang.org/

josephcsible 3y ago
Gren is a fork, not a spiritual successor. And not only did it not fix that problem, it made it worse: https://news.ycombinator.com/item?id=36275171 https://news.ycombinator.com/item?id=36275171
- matsemann 3y ago
  Perhaps because it's not the big problem a few people make it out to be..
- ordinaryradical 3y ago
  Yeah, I just read this further down in this topic. Really bummed about it, Elm always seemed so promising, and I thought a healthy fork was what was needed. I just don’t understand the reasoning for this choice.
terminatornet 3y ago
along those lines, Zokka is a fork of elm that appears to be mostly dedicated towards bug fixes that Evan (the creator of elm) refuses to acknowledge or merge. https://github.com/Zokka-Dev/zokka-compiler https://github.com/Zokka-Dev/zokka-compiler edit: there's also Roc, https://www.roc-lang.org/ https://www.roc-lang.org/, a language started by Richard Feldman who I believe was a former elm core team member. I think Roc aims to accomplish different things than elm, but definitely feels like a spiritual successor
- josephcsible 3y ago
  The commitment to bidirectional compatibility means that Zokka can't fix the problem that GGP was talking about.

matsemann 3y ago

> making it impossible to actually use the language in production Just FUD. I've been on a big team writing a webapp used by hundreds of thousands each day. While it's not necessarily my own first choice, it was great and the least error prone piece of software I've written in my career.

ISV_Damocles 3y ago
It is impossible if you're being responsible. You don't choose a technology that could potentially block you from solving problems in the future unless it brings a huge value to you. Elm's value proposition is mostly being a functional language with an opinionated MVU library baked in, so you can reproduce that value with a better functional language and selecting a similar MVU library in that other language, which means it should never actually cross the value bar above the risk it brings if you need a browser feature it doesn't support and actively prevents you from accessing.
- matsemann 3y ago
  Now you're moving the goalpost. You said it was impossible to use in production. Which is clearly wrong.
  - ISV_Damocles 3y ago
    I am just clarifying why I consider it impossible. Production is not some place you're supposed to cowboy code, but instead have a reasonable expectation that you will be able to continue supporting it for as many years as it operates, and it's impossible for anyone to responsibly use technology with known limitations that have bitten other real engineering teams that they can find zero workarounds for. If you don't consider that an impossibility for a production environment, then I certainly wouldn't want to work with you on a team with production responsibilities.
    - matsemann 3y ago
      [flagged]

troupo 3y ago

ReasonML crippled themselves, too, by splitting the already tiny community between Reason and ReScript Here's a good (neutral!) write-up: https://ersin-akinci.medium.com/confused-about-rescript-rescript-reason-reasonml-and-bucklescript-explained-ab4230555230 https://ersin-akinci.medium.com/confused-about-rescript-resc...

klabb3 3y ago

> I would recommend steering clear of [Go] for years, due to their decision to allow their own `map` type be a generic[2] type but no user-defined types could be[3] I think this is very, very different. First because Go didn’t have a cultish purist aversion to generics, banning people, going after them even outside of community spaces. But on a technical side, maps (and slices and channels) were not gated to be used by std, they were publically available to anyone. Not having generalized a feature is not the same as banning it. There was not even Go syntax to express it. Same as arrays in C, no? That said, I’m not challenging the recommendation to stay away or not - generics was (and still is, may I add!) quite a pain point with the language. I’m personally quite invested for other reasons (concurrency, networking, std lib), but people come to different conclusions naturally.

huy-nguyen 3y ago

If you’re a front-end developer, you should checkout ReScript[1], supposedly a JS-oriented successor of ReasonML and developed by the ReasonML team. [1] https://rescript-lang.org/ https://rescript-lang.org/

kriiuuu 3y ago

If you want to try TEA, but not Elm I reccomend Scala.js with Tyrian[1]. Scala.js is a wonderful, mature project and Tyrian gives you the elm architecture in a very pragmatic way. [1]: https://tyrian.indigoengine.io/ https://tyrian.indigoengine.io/

lf-non 3y ago
Are you actually using this in a non-trivial application? The recurring complain I hear about scala are the bad compile times. I haven't used the language much, so not sure if this only applies to libraries that heavily use compile time metaprogramming. But I really love that with modern tooling we can get a sub-second editor->browser feedback loop even for a three year old medium-large project on modern hardware. This was primarily one of the reasons I avoided Kotlin+Gradle JS target because among other issues the feedback loop was 2-3x slower.
- kriiuuu 3y ago
  I have a medium sized project with it and the initial compile can be slow, however every recompile usually has the page updated as I switch from my editor to it. Not as fast as TS, but worth it for the much better programming language. Tyrian also makes it trivial to set up hot-reload with preserved state.
  - lf-non 3y ago
    Ok, this is interesting. I'll try this out in a small project.

z5h 3y ago

“making it impossible to actually use the language in production” Absolutely false.

ISV_Damocles 3y ago
Please refer to my comment here: https://news.ycombinator.com/item?id=39551017 https://news.ycombinator.com/item?id=39551017

marc136 3y ago

If time is important to you, please correct your statement. > The year in this link is very important. In the following year, the Elm team decided to [...] The blog post was released a year after the official release of Elm 0.19 where the access to native code was further restricted in the official compiler. It was not something that happened without ample prior notice, see for instance a post [1] by the Elm language creator in March 2018 in which he explains his reasoning for the upcoming change. Or another in March 2017 where he announced that intended change [2]. Even in 2015 he actively discouraged people to rely on these undocumented features and other hacks [3]. I also was not happy with that choice and felt the pain of something being taken away that was possible before, but that didn't stop me from using Elm at work nor from using it for fun. So far I haven't found an alternative that I liked better, so I will stick to it. [1]: https://discourse.elm-lang.org/t/native-code-in-0-19/826 https://discourse.elm-lang.org/t/native-code-in-0-19/826 [2]: https://groups.google.com/g/elm-dev/c/bAHD_8PbgKE/m/X-z67wTdCAAJ https://groups.google.com/g/elm-dev/c/bAHD_8PbgKE/m/X-z67wTd... [3]: https://groups.google.com/g/elm-dev/c/1JW6wknkDIo/m/H9ZnS71BCAAJ https://groups.google.com/g/elm-dev/c/1JW6wknkDIo/m/H9ZnS71B...

abrookewood 3y ago

Sorry, but what is FFI???

josephcsible 3y ago
Foreign function interface

cdelsolar 3y ago

I’ve been working with Go for 10 years and I have no idea what you mean by maps being generic before generics came along, nor did maps ever cause me to have over-verbose code bases. The links didn’t seem to help.

ghusbands 3y ago
Trying to summarise what they were likely saying: Not having generics makes code verbose because you end up copying and pasting your library code to make it handle different types. The complaint about maps being generic was that the Go team clearly saw a need for generics (as they implemented them for maps and some other types) but decided that others wouldn't need them. So they had one rule for them and another rule for everyone else, which people don't like.
- cdelsolar 3y ago
  How were maps generic before generics, I am not sure I understand. Didn’t you still have to declare them as map[type1]type2?
  - ghusbands 3y ago
    So when something is generic, it means it is a type parameterized by other types. So the type map[string]int is indeed generic, but no language users could create their own type btree[X]Y, for example. Essentially, the go developers saw a need for generics and then decided that only they get to create them, where most modern language developers either make them available for everyone to implement or don't add them at all.