10 ms·

My Elm Experience

114 points by lawik 5y ago

valyagolev 5y ago
any minute now there will be a language that would learn and steal the good parts from elm but with a more open and industrious evolution process. it’s not going to be as good but it’s going to be very-very useful for quite a while, until the next iteration of PL design
- G4BB3R 5y ago
  Roc, but in a few years https://www.roc-lang.org https://www.roc-lang.org
  - valyagolev 5y ago
    seems like a good approach to monads, but still hard to judge without a decent textual explanation. thank you for the link
- savanaly 5y ago
  My worry is that a lot what I like about Elm is just not compatible with the normal JS library ownership model. What I like is a) Very few features, just enough so you can get your work done and there's just one good way to do it. If you don't have a grumpy BDFL then feature creep is inevitable and your language won't be lean and beautiful like Elm (arguably) is. b) Infrequent releases so that you don't have to reinvent the wheel every few weeks. Elm gets like one release every two years and I very much like it that way. With a big community all helping to develop it rather than (again) one grumpy BDFL who drags their feet all the time there's no way they would be able to have that level of restraint.
  - valyagolev 5y ago
    but what don't you like about Elm then?
- idoubtit 5y ago
  I believe that Derw is a good candidate for this. It was announced last month. The creator intends to deliver a better interop with TypeScript/JS, and promises a more open mind (public development of the core language, allow private repositories, etc). https://derw.substack.com/p/why-derw-an-elm-like-language-that https://derw.substack.com/p/why-derw-an-elm-like-language-th...
  - valyagolev 5y ago
    thank you, looks interesting. however, the stated goal (elm but easier interop with JS) is for me a bit hard to relate, as I think the boundary will always be more pronounced. but we’ll see where this one goes my dream not-elm would start with a verbatim fork of elm, an RFC process for changing it, and a safe and powerful language extensions system inspired by Haskell
- deleted 5y ago
  [deleted]
githubholobeat 5y ago
This exactly matches my experience with Elm. You wrote "..how resistant it was to me hacking my way to success"; the same here, I tried to do things my way, and Elm would resist (thankfully) those efforts. It resulted in an easy to maintain, much cleaner code. Initially, I went through a 3 month mental grind to learn FP in Elm to be somewhat productive. Then it suddenly started to flow. A while ago I wrote a variation of Snake game [0], using elm-ui to render the simple graphics. The coding experience was fantastic. [0]: https://github.com/holobeat/elm-snake https://github.com/holobeat/elm-snake
jokethrowaway 5y ago
Elm is great but the authoritarian style of its leadership make things that should be trivial - like installing a custom package - very hard. When react was immature (aka before hooks) I used elm a fair bit. Nowadays in the age of front-end copy-pasta I just use the framework of the day and sign when I see how slow and patchy TS is.
JaggerJo 5y ago
Try F# + Fable instead.
- hurril 5y ago
  We do this at work and _everybody_ is very happy with it. Works extremely well!
  - quickthrower2 5y ago
    Nice that you had the freedom to choose a great setup
    - hurril 5y ago
      Yes - a sign of a competent management imho. We're already an F# and C# shop, however, so Fable wasn't such a big leap.
    - JaggerJo 5y ago
      We also use it at our startup (and a few projects before that) and it works great. We don’t use elmish tho, but the React bindings. Elmish never worked fir us prior little demos.
- christophilus 5y ago
  It’s been a hot minute since I did anything in F# (or .NET, for that matter). How’s the compilation speed these days? And how’s the tooling on Linux? The last time I looked, both were painful.
  - JaggerJo 5y ago
    Improved quite a bit, but still isn’t the fastest compiler ever. Fabel (the F# to JS/Python) compiler is also ok speed wise. I’m developing on a Mac but have team colleges using linux. Can’t complain. JetBrains Rider is years ahead of Visual Studio IMHO.
yakshaving_jgt 5y ago
It’s amazing how many developers are personally offended (and I’m not suggesting the author is) when a technology resists them trying to be “clever”. Those same developers might also pay lip service to the idea of writing simple code, because that’s the most mature thing to do, and yet one of the most common criticisms of Elm is that it doesn’t let you try to be clever and do synchronous IO. That’s a good thing. A very good thing. You can trust the code you write [to a reasonable extent]. You can trust the code your colleagues write [to a reasonable extent], even if they’re relatively junior. Not every change needs to be interrogated like you might have to in the foot-gun factory that is JavaScript. This level of predictability is amazing for a business, and consequently amazing for a developer’s circadian rhythm if only they could see further than their nose.
- davnn 5y ago
  Simplicity is extremely undervalued in my opinion. I was previously an evangelist for functional programming with Scala et al., but as my experience grows I become more and more utilitarian. The saying „ With great power comes great responsibility“ fits pretty well in the context of programming languages imho.
  - dnautics 5y ago
    That's surprising to me because I would think of scala (and Erlang, elixir etc) as utilitarian fp languages, I refer to them as "working persons languages".
- mhitza 5y ago
  When prototyping I prefer dynamic languages because they allow partial/"sloppy" programs, as generally you type code along the happy path first. Personally I think it wouldn't hurt if more strongly/statically typed languages took a note from the GHC compiler and had an option like -fdefer-type-errors[1]. That way one can write the sloppy/clever/prototype code, then disable the flag and make the program sturdy in the presence of failure. [1] https://downloads.haskell.org/~ghc/7.8.1/docs/html/users_guide/defer-type-errors.html https://downloads.haskell.org/~ghc/7.8.1/docs/html/users_gui...
chungus 5y ago
A few months back I started a feature in an Elm project. I did a few hours of programming and then stopped and forgot about it for two months. When I came back to it I couldn't remember what I was building, and the git branch name wasn't clear either. I decided to just follow the errors and get it to compile again and after about two hours it worked and my frontend sprung back to life with the new feature working. For me Elm is perfect for projects with frequent and extended interruption.
- savanaly 5y ago
  Agreed. I anticipate the day coming in the not too distant future where I'll have children running around and my time spent on side projects will diminish to a large extent, and become sporadic. I'm very glad to looking forward to having Elm by my side in such a time. (ever-unchanging Elm...how many years ago was it that it pushed a new release? Another bonus for my situation).
- giraffe_lady 5y ago
  Yes I always consider it and often use it for personal projects for this reason. More time spent up front but it will run forever if I don't touch it. And if I do need to I can just make the change without spending hours fighting js tooling and figuring out what upgrades I need to make etc. I do group it with clojure, another language I love and have used deeply but intermittently. If I spend a few months away from it when I see the code it's not even "who wrote this and what does it does it do" it's "is this even code what the fuck man."
marcus_cemes 5y ago
I was initialy excited to try learning Elm, until I saw some of the drama on the GitHub issues and a blog post about leaving the Elm ecosystem after having a bad experience with the project leads (I think [1] was the post). I've since put it in my little red box of "hot but you'll be better off staying away from", depsite the numerous podcasts praising the incredible effort and design that went into the language. Has anyone got any thoughts on this? [1]: https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/ https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/
- deleted 5y ago
  [deleted]
- matsemann 5y ago
  How much does any drama in any language you use actually effect you? Wouldn't base my choice on that at all. Learn it to learn something new and expand your horizon if you want to. Or learn it if you think it's valuable to use in its current state (it is). What some people quab about is irrelevant.
  - agumonkey 5y ago
    When you choose to invest time into something that might end after a flamewar, it grinds your motivation a bit. It's not life critical, but it's in your mind.
    - linspace 5y ago
      There is drama everywhere: on the Linux kernel, on Github, Python, Systemd,... People are getting annoyed all the time
      - OtomotO 5y ago
        There is different levels of drama and amount of contributors plus funding though. Do I fear that the Linux kernel, which is used by pretty much all Fortune 500 companies and has a huge amount of paid devs, will die in a huge flamewar? No! The same doesn't hold true for someones hobby project though. And I am well aware, that Linux was a hobby project once, doesn't change a thing about current state though.
jmtucu 5y ago
I used elm in my company for more than two years and is not designed for enterprise apps, is great for tiny apps or POC but I, and my entire team, don't recommend this language.
- cdaringe 5y ago
  I’m on a team with hundreds sharing the same code base is TS. Few things would make me happier than going back in time and picking a much stricter type system like Elm’s or rescript.
- matsemann 5y ago
  I almost feel the opposite. Even typescript can't stop you from breaking a huge app. With elm it's virtually impossible. I feel much safer in making changes in a big enterprise elm app than a similar js/ts app. Biggest problem in enterprise context is you need a team that's on board on learning elm. If someone just needs to stop by and make some small changes, it's a bigger hurdle than doing it in a language "everyone" knows.
  - mrweasel 5y ago
    What makes Elm appealing to me is that is allows me to completely avoid the whole JavaScript ecosystem. There’s no dealing with npm, webpack and all the rest of that confusing mess.
    - napsterbr 5y ago
      I use Clojurescript for the same reason. I will take any opportunity to stay away from the JS ecosystem.
    - cies 5y ago
      Sure that's great. But the real advantage is ending up with a repo full of pure-FP code that you can improve/refactor with confidence, right? Strict compilers make sure my repo only contains code over a certain level of quality. Elm is strict. Code produced in Elm is usually of stellar quality, even by beginners; and if not it's very easy to shape it up later on.
pharmakom 5y ago
Two areas where F# might be preferable: - You can use reflection to generate encoders and decoders. These can be mixed and matched with hand written encoders and decoders. - You can just throw an exception when unpacking a result or maybe into a value - You can use “?” and “!!” operators to tell the compiler that the type is correct when working with dynamic objects
- cies 5y ago
  > F# might be preferable For getting something live quick: yes. But the learning experience of writing some pure-FP code is destroyed by "just throw an exception" and "use “?” and “!!” operators to tell the compiler that the type is correct"
  - nagasadhu 5y ago
    You don't have to use exceptions and other operators with side effects if you don't want to. You can have a pure FP experience with fable and F#. The OP was just mentioning that these escape hatches are available if you need them.
    - pharmakom 5y ago
      Yes I think they can be removed with linting rules once you are ready to hit production.
d13 5y ago
I programmed with Elm for 3 years and love it - best programming experience I’ve ever had. I had to stop because I started working on some educational game projects that had incredibly short timelines and frequent, large change requests and depended on some WebGL 3D and game libraries. Nothing beats the super productivity of JS for hacking something together fast, and despite JS being far less reliable, the productivity and flexibility made up for that. Yes, there were run-time errors, but they were really a minor problem. JS, whatever it’s many faults may be, is fast and fun. What slowed me down with Elm was JSON parsing, which needs to be done manually and can take hours or days whereas the same thing in JS takes about 2 seconds to type an import statement. And the other thing was using BabaylonJS and Phaser - you can certainly use them with Elm but you’ll need to commit to months of extra work to build port-based interfaces to them. And, games live in the world of side-effects, which is a chore in Elm. I needed to get finished games out in days - which I was able to hacking my way through with JS. Having used Elm for such a long time, I’m baffled by the success of Typescript - it’s hardly more reliable than JS while adding another dependency and much more complexity. For anyone sincerely interested in writing reliable code, not just wanting another toy to play with (Typescript) I can’t image writing front end code in anything other than Elm.
- cercatrova 5y ago
  > I’m baffled by the success of Typescript You're baffled, really? The core pitch is that JS developers don't have to learn a whole new language or paradigm such as in the case of other compile-to-JS languages. They can write JS, sprinkle on some TS, and gradually migrate to full TS while learning it along the way. The amount of developer friction is much lower, so that's why it succeeds to a much higher extent (in terms of usage) than other compile-to-JS languages like Elm, PureScript, ReasonML/ReScript, etc.
- skrebbel 5y ago
  Reliability isn't really part of Typescript's pitch though. It's maintainability.
  - yakshaving_jgt 5y ago
jb1991 5y ago
This is an insightful read that gives genuine real-world experience on both the good and frustrating of Elm.
brabel 5y ago
> many libraries don’t change much. If it worked three months ago odds are it still works. LOL when 3 months is considered a long time for a library to not break users, you know something is messed up. I guess the author is referring to the JavaScript ecosystem. As a Java/Lisp developer, I expect things to keep working essentially forever! Why the hell would they break users every 3 months?!
- spicyusername 5y ago
  The unfortunate reality for some of these languages is that the ecosystem moves so fast seeing no git activity for more than a few months is a red flag to find another library. JavaScript is obviously the elephant in the room here. I usually guard myself against this by implementing more niche features myself rather than importing them through third party libraries that might get abandoned.
- cies 5y ago
  Pin versions and it works forever in Elm too. It's not a really point in favour or against Elm, and the dep specification is good enough to tackle it. And "having no new versions" is not considered a good thing in my book.
AlchemistCamp 5y ago
I was also sucked into Elm in 2015]/2016 and found it great in some ways but broken in others. If I were to start a new project and wanted that kind of front-end, I'd use Mint: https://www.mint-lang.com/ https://www.mint-lang.com/
- rpastuszak 5y ago
  Why?
  - AlchemistCamp 5y ago
    JS interop.
    - yakshaving_jgt 5y ago
      Elm’s JS interop isn’t broken.
      - AlchemistCamp 5y ago
        It's not technically broken, but it's a far cry from this: https://www.mint-lang.com/guide/reference/javascript-interop/inlining https://www.mint-lang.com/guide/reference/javascript-interop...
        yakshaving_jgt 5y ago
        From reading that document, I would say Mint’s JS interop is broken, and Elm’s isn’t. Being able to write inline JavaScript is certainly not what I want. Perhaps I’m missing something, but inline JavaScript is the kind of thing that will inevitably result in uncaught runtime failure, which is exactly the kind of thing I am trying to avoid by using a language like Elm.
eweise 5y ago
Been a while since I coded in Elm but I found the Intellij plugin to be pretty good. Better at least than the VSCode trouble mentioned in the post.
jtwebman 5y ago
I wonder if Elm had typeclasses if it would help with the verbose code a little. Not having them just means more code but also maybe more someone needs to understand to use the language.
- yakshaving_jgt 5y ago
  As a Haskell programmer, I am happier that developers who would otherwise be writing JavaScript can more quickly get productive with Elm than I am upset that I don't have the utility of type classes at my fingertips. I think it was a wise compromise.
- 1-more 5y ago
  You'd lose a fair bit of the verbose and helpful error messages for one thing. I think elm seeks to always have the error messages tell you what to do next, and that might be too tough with type classes. Also typeclasses make me act a little too clever. I have a better time when I'm a little more verbose.

114 points by lawik 5y ago

any minute now there will be a language that would learn and steal the good parts from elm but with a more open and industrious evolution process. it’s not going to be as good but it’s going to be very-very useful for quite a while, until the next iteration of PL design

G4BB3R 5y ago
Roc, but in a few years https://www.roc-lang.org https://www.roc-lang.org
- valyagolev 5y ago
  seems like a good approach to monads, but still hard to judge without a decent textual explanation. thank you for the link
savanaly 5y ago
My worry is that a lot what I like about Elm is just not compatible with the normal JS library ownership model. What I like is a) Very few features, just enough so you can get your work done and there's just one good way to do it. If you don't have a grumpy BDFL then feature creep is inevitable and your language won't be lean and beautiful like Elm (arguably) is. b) Infrequent releases so that you don't have to reinvent the wheel every few weeks. Elm gets like one release every two years and I very much like it that way. With a big community all helping to develop it rather than (again) one grumpy BDFL who drags their feet all the time there's no way they would be able to have that level of restraint.
- valyagolev 5y ago
  but what don't you like about Elm then?
idoubtit 5y ago
I believe that Derw is a good candidate for this. It was announced last month. The creator intends to deliver a better interop with TypeScript/JS, and promises a more open mind (public development of the core language, allow private repositories, etc). https://derw.substack.com/p/why-derw-an-elm-like-language-that https://derw.substack.com/p/why-derw-an-elm-like-language-th...
- valyagolev 5y ago
  thank you, looks interesting. however, the stated goal (elm but easier interop with JS) is for me a bit hard to relate, as I think the boundary will always be more pronounced. but we’ll see where this one goes my dream not-elm would start with a verbatim fork of elm, an RFC process for changing it, and a safe and powerful language extensions system inspired by Haskell
deleted 5y ago
[deleted]

githubholobeat 5y ago

This exactly matches my experience with Elm. You wrote "..how resistant it was to me hacking my way to success"; the same here, I tried to do things my way, and Elm would resist (thankfully) those efforts. It resulted in an easy to maintain, much cleaner code. Initially, I went through a 3 month mental grind to learn FP in Elm to be somewhat productive. Then it suddenly started to flow. A while ago I wrote a variation of Snake game [0], using elm-ui to render the simple graphics. The coding experience was fantastic. [0]: https://github.com/holobeat/elm-snake https://github.com/holobeat/elm-snake

jokethrowaway 5y ago

Elm is great but the authoritarian style of its leadership make things that should be trivial - like installing a custom package - very hard. When react was immature (aka before hooks) I used elm a fair bit. Nowadays in the age of front-end copy-pasta I just use the framework of the day and sign when I see how slow and patchy TS is.

JaggerJo 5y ago

Try F# + Fable instead.

hurril 5y ago
We do this at work and _everybody_ is very happy with it. Works extremely well!
- quickthrower2 5y ago
  Nice that you had the freedom to choose a great setup
  - hurril 5y ago
    Yes - a sign of a competent management imho. We're already an F# and C# shop, however, so Fable wasn't such a big leap.
  - JaggerJo 5y ago
    We also use it at our startup (and a few projects before that) and it works great. We don’t use elmish tho, but the React bindings. Elmish never worked fir us prior little demos.
christophilus 5y ago
It’s been a hot minute since I did anything in F# (or .NET, for that matter). How’s the compilation speed these days? And how’s the tooling on Linux? The last time I looked, both were painful.
- JaggerJo 5y ago
  Improved quite a bit, but still isn’t the fastest compiler ever. Fabel (the F# to JS/Python) compiler is also ok speed wise. I’m developing on a Mac but have team colleges using linux. Can’t complain. JetBrains Rider is years ahead of Visual Studio IMHO.

yakshaving_jgt 5y ago

It’s amazing how many developers are personally offended (and I’m not suggesting the author is) when a technology resists them trying to be “clever”. Those same developers might also pay lip service to the idea of writing simple code, because that’s the most mature thing to do, and yet one of the most common criticisms of Elm is that it doesn’t let you try to be clever and do synchronous IO. That’s a good thing. A very good thing. You can trust the code you write [to a reasonable extent]. You can trust the code your colleagues write [to a reasonable extent], even if they’re relatively junior. Not every change needs to be interrogated like you might have to in the foot-gun factory that is JavaScript. This level of predictability is amazing for a business, and consequently amazing for a developer’s circadian rhythm if only they could see further than their nose.

davnn 5y ago
Simplicity is extremely undervalued in my opinion. I was previously an evangelist for functional programming with Scala et al., but as my experience grows I become more and more utilitarian. The saying „ With great power comes great responsibility“ fits pretty well in the context of programming languages imho.
- dnautics 5y ago
  That's surprising to me because I would think of scala (and Erlang, elixir etc) as utilitarian fp languages, I refer to them as "working persons languages".
mhitza 5y ago
When prototyping I prefer dynamic languages because they allow partial/"sloppy" programs, as generally you type code along the happy path first. Personally I think it wouldn't hurt if more strongly/statically typed languages took a note from the GHC compiler and had an option like -fdefer-type-errors[1]. That way one can write the sloppy/clever/prototype code, then disable the flag and make the program sturdy in the presence of failure. [1] https://downloads.haskell.org/~ghc/7.8.1/docs/html/users_guide/defer-type-errors.html https://downloads.haskell.org/~ghc/7.8.1/docs/html/users_gui...

chungus 5y ago

A few months back I started a feature in an Elm project. I did a few hours of programming and then stopped and forgot about it for two months. When I came back to it I couldn't remember what I was building, and the git branch name wasn't clear either. I decided to just follow the errors and get it to compile again and after about two hours it worked and my frontend sprung back to life with the new feature working. For me Elm is perfect for projects with frequent and extended interruption.

savanaly 5y ago
Agreed. I anticipate the day coming in the not too distant future where I'll have children running around and my time spent on side projects will diminish to a large extent, and become sporadic. I'm very glad to looking forward to having Elm by my side in such a time. (ever-unchanging Elm...how many years ago was it that it pushed a new release? Another bonus for my situation).
giraffe_lady 5y ago
Yes I always consider it and often use it for personal projects for this reason. More time spent up front but it will run forever if I don't touch it. And if I do need to I can just make the change without spending hours fighting js tooling and figuring out what upgrades I need to make etc. I do group it with clojure, another language I love and have used deeply but intermittently. If I spend a few months away from it when I see the code it's not even "who wrote this and what does it does it do" it's "is this even code what the fuck man."

marcus_cemes 5y ago

I was initialy excited to try learning Elm, until I saw some of the drama on the GitHub issues and a blog post about leaving the Elm ecosystem after having a bad experience with the project leads (I think [1] was the post). I've since put it in my little red box of "hot but you'll be better off staying away from", depsite the numerous podcasts praising the incredible effort and design that went into the language. Has anyone got any thoughts on this? [1]: https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/ https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/

deleted 5y ago
[deleted]
matsemann 5y ago
How much does any drama in any language you use actually effect you? Wouldn't base my choice on that at all. Learn it to learn something new and expand your horizon if you want to. Or learn it if you think it's valuable to use in its current state (it is). What some people quab about is irrelevant.
- agumonkey 5y ago
  When you choose to invest time into something that might end after a flamewar, it grinds your motivation a bit. It's not life critical, but it's in your mind.
  - linspace 5y ago
    There is drama everywhere: on the Linux kernel, on Github, Python, Systemd,... People are getting annoyed all the time
    - OtomotO 5y ago
      There is different levels of drama and amount of contributors plus funding though. Do I fear that the Linux kernel, which is used by pretty much all Fortune 500 companies and has a huge amount of paid devs, will die in a huge flamewar? No! The same doesn't hold true for someones hobby project though. And I am well aware, that Linux was a hobby project once, doesn't change a thing about current state though.

jmtucu 5y ago

I used elm in my company for more than two years and is not designed for enterprise apps, is great for tiny apps or POC but I, and my entire team, don't recommend this language.

cdaringe 5y ago
I’m on a team with hundreds sharing the same code base is TS. Few things would make me happier than going back in time and picking a much stricter type system like Elm’s or rescript.
matsemann 5y ago
I almost feel the opposite. Even typescript can't stop you from breaking a huge app. With elm it's virtually impossible. I feel much safer in making changes in a big enterprise elm app than a similar js/ts app. Biggest problem in enterprise context is you need a team that's on board on learning elm. If someone just needs to stop by and make some small changes, it's a bigger hurdle than doing it in a language "everyone" knows.
- mrweasel 5y ago
  What makes Elm appealing to me is that is allows me to completely avoid the whole JavaScript ecosystem. There’s no dealing with npm, webpack and all the rest of that confusing mess.
  - napsterbr 5y ago
    I use Clojurescript for the same reason. I will take any opportunity to stay away from the JS ecosystem.
  - cies 5y ago
    Sure that's great. But the real advantage is ending up with a repo full of pure-FP code that you can improve/refactor with confidence, right? Strict compilers make sure my repo only contains code over a certain level of quality. Elm is strict. Code produced in Elm is usually of stellar quality, even by beginners; and if not it's very easy to shape it up later on.

pharmakom 5y ago

Two areas where F# might be preferable: - You can use reflection to generate encoders and decoders. These can be mixed and matched with hand written encoders and decoders. - You can just throw an exception when unpacking a result or maybe into a value - You can use “?” and “!!” operators to tell the compiler that the type is correct when working with dynamic objects

cies 5y ago
> F# might be preferable For getting something live quick: yes. But the learning experience of writing some pure-FP code is destroyed by "just throw an exception" and "use “?” and “!!” operators to tell the compiler that the type is correct"
- nagasadhu 5y ago
  You don't have to use exceptions and other operators with side effects if you don't want to. You can have a pure FP experience with fable and F#. The OP was just mentioning that these escape hatches are available if you need them.
  - pharmakom 5y ago
    Yes I think they can be removed with linting rules once you are ready to hit production.

d13 5y ago

I programmed with Elm for 3 years and love it - best programming experience I’ve ever had. I had to stop because I started working on some educational game projects that had incredibly short timelines and frequent, large change requests and depended on some WebGL 3D and game libraries. Nothing beats the super productivity of JS for hacking something together fast, and despite JS being far less reliable, the productivity and flexibility made up for that. Yes, there were run-time errors, but they were really a minor problem. JS, whatever it’s many faults may be, is fast and fun. What slowed me down with Elm was JSON parsing, which needs to be done manually and can take hours or days whereas the same thing in JS takes about 2 seconds to type an import statement. And the other thing was using BabaylonJS and Phaser - you can certainly use them with Elm but you’ll need to commit to months of extra work to build port-based interfaces to them. And, games live in the world of side-effects, which is a chore in Elm. I needed to get finished games out in days - which I was able to hacking my way through with JS. Having used Elm for such a long time, I’m baffled by the success of Typescript - it’s hardly more reliable than JS while adding another dependency and much more complexity. For anyone sincerely interested in writing reliable code, not just wanting another toy to play with (Typescript) I can’t image writing front end code in anything other than Elm.

cercatrova 5y ago
> I’m baffled by the success of Typescript You're baffled, really? The core pitch is that JS developers don't have to learn a whole new language or paradigm such as in the case of other compile-to-JS languages. They can write JS, sprinkle on some TS, and gradually migrate to full TS while learning it along the way. The amount of developer friction is much lower, so that's why it succeeds to a much higher extent (in terms of usage) than other compile-to-JS languages like Elm, PureScript, ReasonML/ReScript, etc.
skrebbel 5y ago
Reliability isn't really part of Typescript's pitch though. It's maintainability.
- yakshaving_jgt 5y ago

jb1991 5y ago

This is an insightful read that gives genuine real-world experience on both the good and frustrating of Elm.

brabel 5y ago

> many libraries don’t change much. If it worked three months ago odds are it still works. LOL when 3 months is considered a long time for a library to not break users, you know something is messed up. I guess the author is referring to the JavaScript ecosystem. As a Java/Lisp developer, I expect things to keep working essentially forever! Why the hell would they break users every 3 months?!

spicyusername 5y ago
The unfortunate reality for some of these languages is that the ecosystem moves so fast seeing no git activity for more than a few months is a red flag to find another library. JavaScript is obviously the elephant in the room here. I usually guard myself against this by implementing more niche features myself rather than importing them through third party libraries that might get abandoned.
cies 5y ago
Pin versions and it works forever in Elm too. It's not a really point in favour or against Elm, and the dep specification is good enough to tackle it. And "having no new versions" is not considered a good thing in my book.

AlchemistCamp 5y ago

I was also sucked into Elm in 2015]/2016 and found it great in some ways but broken in others. If I were to start a new project and wanted that kind of front-end, I'd use Mint: https://www.mint-lang.com/ https://www.mint-lang.com/

rpastuszak 5y ago
Why?
- AlchemistCamp 5y ago
  JS interop.
  - yakshaving_jgt 5y ago
    Elm’s JS interop isn’t broken.
    - AlchemistCamp 5y ago
      It's not technically broken, but it's a far cry from this: https://www.mint-lang.com/guide/reference/javascript-interop/inlining https://www.mint-lang.com/guide/reference/javascript-interop...
      - yakshaving_jgt 5y ago
        From reading that document, I would say Mint’s JS interop is broken, and Elm’s isn’t. Being able to write inline JavaScript is certainly not what I want. Perhaps I’m missing something, but inline JavaScript is the kind of thing that will inevitably result in uncaught runtime failure, which is exactly the kind of thing I am trying to avoid by using a language like Elm.

eweise 5y ago

Been a while since I coded in Elm but I found the Intellij plugin to be pretty good. Better at least than the VSCode trouble mentioned in the post.

jtwebman 5y ago

I wonder if Elm had typeclasses if it would help with the verbose code a little. Not having them just means more code but also maybe more someone needs to understand to use the language.

yakshaving_jgt 5y ago
As a Haskell programmer, I am happier that developers who would otherwise be writing JavaScript can more quickly get productive with Elm than I am upset that I don't have the utility of type classes at my fingertips. I think it was a wise compromise.
1-more 5y ago
You'd lose a fair bit of the verbose and helpful error messages for one thing. I think elm seeks to always have the error messages tell you what to do next, and that might be too tough with type classes. Also typeclasses make me act a little too clever. I have a better time when I'm a little more verbose.