6 ms·

Ok, exaggerations about elm's safety aside, there's the huge issue of it's readiness for production. It's not just a fledgling project, it's a project that's b

Ok, exaggerations about elm's safety aside, there's the huge issue of it's readiness for production. It's not just a fledgling project, it's a project that's being carried by one person for a very broad scope, and it's been going for a very long time now. Contrast that with something like vue, where Evan You has a fair amount of corporate sponsorship, has a much smaller scope (i.e. not an entire new language), big following, and has other frameworks to develop in tandem with (i.e. get inspired by react). Not to mention that it's very similar to other frameworks, so it's easy to pick up, so easy to hire for. I would shitting bricks if I had 200k lines of code in a completely different language with a heavily different paradigm, that's not really battle tested.

jfmengels1 6y ago
With regards to Elm being battle-tested, I'd argue that we've had that battle, and we won it. Elm may not be a good fit for every project out there, like when you need tight integrations with specific JS projects, but it will work well for most projects. At this point, I'd personally be more interested in hearing about cases where Elm was NOT a good fit (and why) rather than where it is.
matsemann 6y ago
The safety isn't an exaggeration, though I can understand it can be hard to believe when not experienced first hand just how hard it is to introduce bugs in elm. Like type safety eliminates one type of bugs, elm's stricter safety eliminates even more. When there is only one place in the whole code base that is allowed to have side effects, that removes lots of the bugs normally seen in frontend. Can't recall we ever having a runtime bug. And most logical bugs are also eliminated since they are harder to actually make. It's ready for production. We've been using it for years without issues or bugs. It works as it is right now, and has done for years. It's not like it would stop working out of the blue.
- lyu07282 6y ago
  a true believer I can tell. But you could easily say the same thing about a well architected typescript/react frontend app, its just that it has several orders of magnitude more experienced developers and billions in corporate sponsorship behind it. Which is significantly more important than any cool feature the hip esoteric language of the week may have.
  - jfmengels1 6y ago
    I couldn't say the same thing for even well-architected TS apps. There are important escape hatches that TS gives that make it unreliable, as summarized in this article: https://incrementalelm.com/tips/typescript-blind-spots/ https://incrementalelm.com/tips/typescript-blind-spots/ Refactoring code or updating dependencies is and feels a lot safer in Elm than in TS, and doesn't require asking for every npm package author to add TS type definitions. I'd also argue that TS/JS have the esoteric/cool features. Elm is a very simple language, complete enough to be able to write most programs, but small enough to give you a lot of guarantees about how the code will behave.
    - heterodoxxed 6y ago
      | There are important escape hatches that TS gives that make it unreliable This is one way to mitigate those escape hatches: https://github.com/cyrilletuzi/typescript-strictly-typed https://github.com/cyrilletuzi/typescript-strictly-typed But in my experience, you had better be starting a new project. They aren't joking when they say laying it on an existing codebase is a nightmare.
      - razze 6y ago
        Do you know if that somehow fixes https://github.com/microsoft/TypeScript/issues/8677 https://github.com/microsoft/TypeScript/issues/8677 ? That's still the most annoying thing about typescript for me.
  - neonological 6y ago
    You need to try elm. Elm is better despite not having everything you mentioned. I’m not a fanboy either. I just used elm for one project, but from that it’s already enough to know.
  - matsemann 6y ago
    > a true believer I can tell Just fuck off with that kind of comment. I provided a well reasoned post, dismissing my views like that just because they don't align with yours is dishonest on your part and no way to have a discussion. To answer your claims: No, I couldn't easily say the same about TS/react. In elm the language forces the architecture and safety. In react it can be whatever you want with leaks and unsafe modifications all over the place.
- idoubtit 6y ago
  > It's not like it would stop working out of the blue. Unless the benevolent dictator pushes out a new Elm version that is not backward compatible. And, if the process is the same it was a few years ago, it could happen next month and only a happy few know it. The development is done behind closed doors. It happened to a project of mine, from version 0.17 to 0.18 IIRC. The choice was between letting the code slowly rot, rewriting a large part of it still in Elm but with the new paradigm, or switching to some stable JS framework. I had overall enjoyed working with Elm until that.
  - durbat 6y ago
    Same here. Still on 0.18, no upgrade path as 70% of my deps never upgraded. Awaiting rewrite in vue/react/etc
    - razze 6y ago
      You can just vendor those dependencies, that's what I did, but I only had one that didn't update. And that one was trivial to fix.
  - SupremumLimit 6y ago
    FWIW, no significant changes to the language are expected in the next couple of years. Another side of this argument is that the rate of Elm ecosystem change is far more manageable than for JS. A "stable JS framework" is an oxymoron, I'm afraid. My JS tools and NPM packages continuously change from under me, but somehow that's considered normal and not a problem. I've just looked up a project I have with a mere 9 dependencies, and 7 of them have gone through multiple major version changes since the end of 2019. The other two have had minor releases. None are unchanged, even though all were already "stable" when I added them! Will the code still work if I update them? I don't know. Do I want to spend the time continuously tracking the changes to these dependencies, testing, making new releases of my project? Not really. Perhaps I could continue deferring dependency updates, but that might make my job that much more painful when I have a legitimate reason to update (eg. for some new features I need) as half the package APIs will have changed beyond recognition by then. I have so much less trouble with going back to Elm projects and picking up where I left off. That should be taken into consideration too.
GiorgioG 6y ago
The bus-factor of one is too high a risk for me unless I'm creating a throw-away project.
- razze 6y ago
  I'm pretty sure if your honest all you projects end up having this bus factor (check all your dependencies). If you really care to look, most projects are run by a small group of people.
  - GiorgioG 6y ago
    I’m pretty sure you’d be wrong. I would never build a software product or service that uses a compiler written and maintained by a single person.
    - razze 6y ago
      Interesting, why are compilers special in your POV? Why do they need regular maintenance and why don't they allow extension via some kind interfaces, thus allowing for less maintenance?
- cardanome 6y ago
  Elm is not something that needs regular security updates or something. It is super stable and has a relatively slow release cycle. Even if the creator died or lost interest you would be still fine to use it. The community could still provide critical patches if their was a need. Feature development might slow down but if it is already offering everything you need that is not really an issue, no?
  - 1-more 6y ago
    To add a little: the core features of the language are pretty well baked in at this point. Evan even said "If you like what you see now, that’s pretty much what Elm is going to be for a while."[0] The `eq` typeclass is I guess the missing feature[1] that stands out the most right now—in brief: don't allow equality check on functions, regexes, or JS objects at compile time. [0] https://discourse.elm-lang.org/t/where-can-we-find-the-roadmap-of-elm/6038 https://discourse.elm-lang.org/t/where-can-we-find-the-roadm... [1] https://package.elm-lang.org/packages/elm/core/latest/Basics#equality https://package.elm-lang.org/packages/elm/core/latest/Basics...
k_bx 6y ago
I’ve batte-tested Elm on many projects at this point. It has its quirks, but it’s great. The language is so simple and its compilers so small that I’m not really afraid of the bus-factor. Worst case — I’d fork the compiler and apply the fixes I need.
rtfeldman 6y ago
For what it's worth, Elm is extremely battle tested. We have over 400K lines of Elm in production, and have been using it since 2015. We've been super happy with it, and have no interest in going back to JS or TS. (To be totally honest, at this point I can't imagine even a hypothetical JS/TS framework that could bring enough benefits for us as a business to justify giving up Elm's compiler and package ecosystem. I'd be super impressed if someone managed that though!)
- hitekker 6y ago
  Is Evan still working for NoRedInk? It looks like he vanished sometime around May last year.
  - jfmengels1 6y ago
    He is not, but he's still actively working on Elm. You can find his latest interview here: https://elm-radio.com/episode/open-source-funding https://elm-radio.com/episode/open-source-funding
    - hitekker 6y ago
      Oh nice, thanks for the context. NoRedInk published a big blog post about him joining a few years ago https://blog.noredink.com/post/136615783598/welcome-evan https://blog.noredink.com/post/136615783598/welcome-evan so I thought he'd get a "fond farewell" for leaving too
  - throwaway32141 6y ago
    He's not. It wasn't exactly a happy separation. The company had some internal strife last year and I'm not sure if the CTO and the head of tech want to work together anymore
    - rtfeldman 5y ago
      Head of tech here. We had COVID-induced layoffs, like many companies, not internal strife. Our CTO is one of my favorite coworkers I've ever had. What a cruel thing to make up and then say.
1-more 6y ago
> that's not really battle tested. What is the criterion for battle tested?

jfmengels1 6y ago

With regards to Elm being battle-tested, I'd argue that we've had that battle, and we won it. Elm may not be a good fit for every project out there, like when you need tight integrations with specific JS projects, but it will work well for most projects. At this point, I'd personally be more interested in hearing about cases where Elm was NOT a good fit (and why) rather than where it is.

matsemann 6y ago

The safety isn't an exaggeration, though I can understand it can be hard to believe when not experienced first hand just how hard it is to introduce bugs in elm. Like type safety eliminates one type of bugs, elm's stricter safety eliminates even more. When there is only one place in the whole code base that is allowed to have side effects, that removes lots of the bugs normally seen in frontend. Can't recall we ever having a runtime bug. And most logical bugs are also eliminated since they are harder to actually make. It's ready for production. We've been using it for years without issues or bugs. It works as it is right now, and has done for years. It's not like it would stop working out of the blue.

lyu07282 6y ago
a true believer I can tell. But you could easily say the same thing about a well architected typescript/react frontend app, its just that it has several orders of magnitude more experienced developers and billions in corporate sponsorship behind it. Which is significantly more important than any cool feature the hip esoteric language of the week may have.
- jfmengels1 6y ago
  I couldn't say the same thing for even well-architected TS apps. There are important escape hatches that TS gives that make it unreliable, as summarized in this article: https://incrementalelm.com/tips/typescript-blind-spots/ https://incrementalelm.com/tips/typescript-blind-spots/ Refactoring code or updating dependencies is and feels a lot safer in Elm than in TS, and doesn't require asking for every npm package author to add TS type definitions. I'd also argue that TS/JS have the esoteric/cool features. Elm is a very simple language, complete enough to be able to write most programs, but small enough to give you a lot of guarantees about how the code will behave.
  - heterodoxxed 6y ago
    | There are important escape hatches that TS gives that make it unreliable This is one way to mitigate those escape hatches: https://github.com/cyrilletuzi/typescript-strictly-typed https://github.com/cyrilletuzi/typescript-strictly-typed But in my experience, you had better be starting a new project. They aren't joking when they say laying it on an existing codebase is a nightmare.
    - razze 6y ago
      Do you know if that somehow fixes https://github.com/microsoft/TypeScript/issues/8677 https://github.com/microsoft/TypeScript/issues/8677 ? That's still the most annoying thing about typescript for me.
- neonological 6y ago
  You need to try elm. Elm is better despite not having everything you mentioned. I’m not a fanboy either. I just used elm for one project, but from that it’s already enough to know.
- matsemann 6y ago
  > a true believer I can tell Just fuck off with that kind of comment. I provided a well reasoned post, dismissing my views like that just because they don't align with yours is dishonest on your part and no way to have a discussion. To answer your claims: No, I couldn't easily say the same about TS/react. In elm the language forces the architecture and safety. In react it can be whatever you want with leaks and unsafe modifications all over the place.
idoubtit 6y ago
> It's not like it would stop working out of the blue. Unless the benevolent dictator pushes out a new Elm version that is not backward compatible. And, if the process is the same it was a few years ago, it could happen next month and only a happy few know it. The development is done behind closed doors. It happened to a project of mine, from version 0.17 to 0.18 IIRC. The choice was between letting the code slowly rot, rewriting a large part of it still in Elm but with the new paradigm, or switching to some stable JS framework. I had overall enjoyed working with Elm until that.
- durbat 6y ago
  Same here. Still on 0.18, no upgrade path as 70% of my deps never upgraded. Awaiting rewrite in vue/react/etc
  - razze 6y ago
    You can just vendor those dependencies, that's what I did, but I only had one that didn't update. And that one was trivial to fix.
- SupremumLimit 6y ago
  FWIW, no significant changes to the language are expected in the next couple of years. Another side of this argument is that the rate of Elm ecosystem change is far more manageable than for JS. A "stable JS framework" is an oxymoron, I'm afraid. My JS tools and NPM packages continuously change from under me, but somehow that's considered normal and not a problem. I've just looked up a project I have with a mere 9 dependencies, and 7 of them have gone through multiple major version changes since the end of 2019. The other two have had minor releases. None are unchanged, even though all were already "stable" when I added them! Will the code still work if I update them? I don't know. Do I want to spend the time continuously tracking the changes to these dependencies, testing, making new releases of my project? Not really. Perhaps I could continue deferring dependency updates, but that might make my job that much more painful when I have a legitimate reason to update (eg. for some new features I need) as half the package APIs will have changed beyond recognition by then. I have so much less trouble with going back to Elm projects and picking up where I left off. That should be taken into consideration too.

GiorgioG 6y ago

The bus-factor of one is too high a risk for me unless I'm creating a throw-away project.

razze 6y ago
I'm pretty sure if your honest all you projects end up having this bus factor (check all your dependencies). If you really care to look, most projects are run by a small group of people.
- GiorgioG 6y ago
  I’m pretty sure you’d be wrong. I would never build a software product or service that uses a compiler written and maintained by a single person.
  - razze 6y ago
    Interesting, why are compilers special in your POV? Why do they need regular maintenance and why don't they allow extension via some kind interfaces, thus allowing for less maintenance?
cardanome 6y ago
Elm is not something that needs regular security updates or something. It is super stable and has a relatively slow release cycle. Even if the creator died or lost interest you would be still fine to use it. The community could still provide critical patches if their was a need. Feature development might slow down but if it is already offering everything you need that is not really an issue, no?
- 1-more 6y ago
  To add a little: the core features of the language are pretty well baked in at this point. Evan even said "If you like what you see now, that’s pretty much what Elm is going to be for a while."[0] The `eq` typeclass is I guess the missing feature[1] that stands out the most right now—in brief: don't allow equality check on functions, regexes, or JS objects at compile time. [0] https://discourse.elm-lang.org/t/where-can-we-find-the-roadmap-of-elm/6038 https://discourse.elm-lang.org/t/where-can-we-find-the-roadm... [1] https://package.elm-lang.org/packages/elm/core/latest/Basics#equality https://package.elm-lang.org/packages/elm/core/latest/Basics...

k_bx 6y ago

I’ve batte-tested Elm on many projects at this point. It has its quirks, but it’s great. The language is so simple and its compilers so small that I’m not really afraid of the bus-factor. Worst case — I’d fork the compiler and apply the fixes I need.

rtfeldman 6y ago

For what it's worth, Elm is extremely battle tested. We have over 400K lines of Elm in production, and have been using it since 2015. We've been super happy with it, and have no interest in going back to JS or TS. (To be totally honest, at this point I can't imagine even a hypothetical JS/TS framework that could bring enough benefits for us as a business to justify giving up Elm's compiler and package ecosystem. I'd be super impressed if someone managed that though!)

hitekker 6y ago
Is Evan still working for NoRedInk? It looks like he vanished sometime around May last year.
- jfmengels1 6y ago
  He is not, but he's still actively working on Elm. You can find his latest interview here: https://elm-radio.com/episode/open-source-funding https://elm-radio.com/episode/open-source-funding
  - hitekker 6y ago
    Oh nice, thanks for the context. NoRedInk published a big blog post about him joining a few years ago https://blog.noredink.com/post/136615783598/welcome-evan https://blog.noredink.com/post/136615783598/welcome-evan so I thought he'd get a "fond farewell" for leaving too
- throwaway32141 6y ago
  He's not. It wasn't exactly a happy separation. The company had some internal strife last year and I'm not sure if the CTO and the head of tech want to work together anymore
  - rtfeldman 5y ago
    Head of tech here. We had COVID-induced layoffs, like many companies, not internal strife. Our CTO is one of my favorite coworkers I've ever had. What a cruel thing to make up and then say.

1-more 6y ago

> that's not really battle tested. What is the criterion for battle tested?