Elm 0.19 nuked any good thoughts I had towards the language. Limiting native modules to a small group of people was a bad design decision, and the lack of leadership has imo doomed the language. elm-janitor is a project that exists to cleanup the mess, and they link a useful but sad spreadsheet of all the fixes that have yet to be merged.
If I were to stick to a functional language today, I would bet on Roc succeeding where Elm couldn’t.
I think ReScript has pretty much taken that niche already. It did what Elm didn’t–provide a pragmatic, interoperable integration with the rest of the JS ecosystem while also providing type safety and fast compiles.
mm this does look like a proper replacement, whereas my Roc evangelism is probably premature. my first question would be how it differs from reason ml which also fills the functional-web niche
ReScript is a continuation of the ReasonML functional-web effort. It split off from the ‘ReasonML’ branding to create a more integrated, turnkey experience for typed functional web dev.
This may sound nit-picky or unreasonable, but the immediate blocker for me adopting ReScript is its take on Option/undefined/null.
I actually do use undefined and null to mean semantically different things in my JavaScipt/TypeScript code. For example, if I’m sending a POST request to my backend API, it will treat a missing field (undefined) as unset and needing the default value (if it is intended to be optional), and it will treat a present null to mean that the client is explicitly denoting “emptiness” for the value and it will NOT be overwritten with a default value.
Likewise, in languages with a generic Option type (Swift, Rust, Kotlin-when-I-write-it), I do sometimes represent the above semantics similarly by having an Option<Option<T>> (or Option<T?> in Kotlin) for an “optional nullable” value.
I realize that ReScript has escape hatches for these things, but I feel like “escape hatches” are for uncommon situations; I don’t want to have these “escape hatches” all over my code and have to fight against the grain of the language.
As much as I loathe TypeScript, I feel like I’m stuck with it.
Right, I know. It’s just that the standard library functions all use option<'a>, so I worry about needing to do a bunch of fiddling between three kinds of “maybe present” types instead of the usual two. Maybe in practice it isn’t bad, but I’ve dug myself into plenty of holes before while trying to go against the grain of the language I was using.
I don’t see any big problems, you just define your form fields with strong types like myField: option<string> and convert the weaker-typed values received over the network into strongly-typed internal values with checks and converter functions. It’s conceptually very similar to TypeScript except it doesn’t suffer from the ‘wrapping’ problem because the option type has special compiler support.
Somebody on the orange site always reposts the same compiler bug as an example of why Elm is not worth using. It’s certainly a good discussion, emblematic of why I and others don’t use Elm: we all have use cases, the core team refuses to appreciate those cases, and things slowly get worse over time as our cases are broken.
tl;dr: Elm can’t pattern match on negative numbers. When someone raised this as an issue, the bdfl asked
Why are you doing this? Instead of fake examples, can you explain how this comes up?
Cue about six people listing their different specific use cases where they need to pattern match on negative numbers. There’s been no dev response since.
I still find Elm inspiring even all these years after I first discovered it. It influenced my ideas about how to program and what a programming language ought to be. I would still consider using it for small personal projects or teaching someone programming, especially functional programming concepts.
This article posted previously and written by someone at Culture Amp (one of Elm’s last major corporate boosters to leave it) does an excellent job of summing up both the appeal of the language and its practical limitations in a professional context. Thus I upvote, but with this caveat.
Honestly if I had to do any frontend work, “you don’t have to use npm” would be a hell of a sales pitch. I know Elm has problems, but that factor alone would be enough for me to overlook a lot of them.
Elm is great and all, but bugs piling up /by design/ for years doesn’t appeal to me. Look at any other language repo, the last commit will be a few hours old at most. With Elm it is measured in months. I have a hard time believing that the core is so pure and perfect that it doesn’t need touching for years on. In fact the various issues reported tend to prove the contrary. There are bugs, but they are ignored, on purpose. Apparently, some people are okay with that. I am not one of these people.
I think at this point Elm is just abandonware. It’s less that bugs are “ignored on purpose”, more that no-one who maintained the codebase is even paying attention anymore.
I find it bizarre that despite the constant discourse on tech forums bemoaning the state of Elm (lack of updates / support) the leadership has done absolutely nothing to quell concerns, completely radio silence. Really speaks volumes that language contributors have jumped ship and are trying to build their own alternatives (see Gren / Roc etc.)
Elm is beautiful, but it lacks momentum for me to adopt it. But I love the language. I don’t criticize Evan for how the project was conducted - amazing chap and amazing code. But it does not inspire confidence enough to use it at work.
That said, ChatGPT is a hell of an Elm programmer :)
Elm 0.19 nuked any good thoughts I had towards the language. Limiting native modules to a small group of people was a bad design decision, and the lack of leadership has imo doomed the language. elm-janitor is a project that exists to cleanup the mess, and they link a useful but sad spreadsheet of all the fixes that have yet to be merged.
If I were to stick to a functional language today, I would bet on Roc succeeding where Elm couldn’t.
I think ReScript has pretty much taken that niche already. It did what Elm didn’t–provide a pragmatic, interoperable integration with the rest of the JS ecosystem while also providing type safety and fast compiles.
mm this does look like a proper replacement, whereas my Roc evangelism is probably premature. my first question would be how it differs from reason ml which also fills the functional-web niche
My understanding is that ReScript is essentially a rebranding of ReasonML which has mostly been abandoned.
ReScript is a continuation of the ReasonML functional-web effort. It split off from the ‘ReasonML’ branding to create a more integrated, turnkey experience for typed functional web dev.
This may sound nit-picky or unreasonable, but the immediate blocker for me adopting ReScript is its take on
Option/undefined/null.I actually do use
undefinedandnullto mean semantically different things in my JavaScipt/TypeScript code. For example, if I’m sending a POST request to my backend API, it will treat a missing field (undefined) as unset and needing the default value (if it is intended to be optional), and it will treat a presentnullto mean that the client is explicitly denoting “emptiness” for the value and it will NOT be overwritten with a default value.Likewise, in languages with a generic Option type (Swift, Rust, Kotlin-when-I-write-it), I do sometimes represent the above semantics similarly by having an
Option<Option<T>>(orOption<T?>in Kotlin) for an “optional nullable” value.I realize that ReScript has escape hatches for these things, but I feel like “escape hatches” are for uncommon situations; I don’t want to have these “escape hatches” all over my code and have to fight against the grain of the language.
As much as I loathe TypeScript, I feel like I’m stuck with it.
ReScript can deal with
nullandundefinedseparately using its provided APIs:Right, I know. It’s just that the standard library functions all use
option<'a>, so I worry about needing to do a bunch of fiddling between three kinds of “maybe present” types instead of the usual two. Maybe in practice it isn’t bad, but I’ve dug myself into plenty of holes before while trying to go against the grain of the language I was using.I don’t see any big problems, you just define your form fields with strong types like
myField: option<string>and convert the weaker-typed values received over the network into strongly-typed internal values with checks and converter functions. It’s conceptually very similar to TypeScript except it doesn’t suffer from the ‘wrapping’ problem because the option type has special compiler support.Wow that spreadsheet is really depressing.
Somebody on the orange site always reposts the same compiler bug as an example of why Elm is not worth using. It’s certainly a good discussion, emblematic of why I and others don’t use Elm: we all have use cases, the core team refuses to appreciate those cases, and things slowly get worse over time as our cases are broken.
tl;dr: Elm can’t pattern match on negative numbers. When someone raised this as an issue, the bdfl asked
Cue about six people listing their different specific use cases where they need to pattern match on negative numbers. There’s been no dev response since.
I find it quite amazing that Elm’s parser library is held up as exemplary given this situation.
I still find Elm inspiring even all these years after I first discovered it. It influenced my ideas about how to program and what a programming language ought to be. I would still consider using it for small personal projects or teaching someone programming, especially functional programming concepts.
This article posted previously and written by someone at Culture Amp (one of Elm’s last major corporate boosters to leave it) does an excellent job of summing up both the appeal of the language and its practical limitations in a professional context. Thus I upvote, but with this caveat.
Honestly if I had to do any frontend work, “you don’t have to use npm” would be a hell of a sales pitch. I know Elm has problems, but that factor alone would be enough for me to overlook a lot of them.
Like, you don’t use any third-party code from the NPM registry? Or you don’t have to use the
npmprogram?I meant the whole ecosystem; I’m aware there already exist workarounds to let you avoid the specific
npmprogram.Elm is great and all, but bugs piling up /by design/ for years doesn’t appeal to me. Look at any other language repo, the last commit will be a few hours old at most. With Elm it is measured in months. I have a hard time believing that the core is so pure and perfect that it doesn’t need touching for years on. In fact the various issues reported tend to prove the contrary. There are bugs, but they are ignored, on purpose. Apparently, some people are okay with that. I am not one of these people.
I think at this point Elm is just abandonware. It’s less that bugs are “ignored on purpose”, more that no-one who maintained the codebase is even paying attention anymore.
No apparently the dev is doing “exploratory work”, and has been for 3 years now :p
https://github.com/elm/compiler/blob/master/roadmap.md
So if you wait a few more years there might or might not be a new version coming up! ;)
I find it bizarre that despite the constant discourse on tech forums bemoaning the state of Elm (lack of updates / support) the leadership has done absolutely nothing to quell concerns, completely radio silence. Really speaks volumes that language contributors have jumped ship and are trying to build their own alternatives (see Gren / Roc etc.)
Don’t forget Derw on your list
I knew I was missing something!
Elm is beautiful, but it lacks momentum for me to adopt it. But I love the language. I don’t criticize Evan for how the project was conducted - amazing chap and amazing code. But it does not inspire confidence enough to use it at work.
That said, ChatGPT is a hell of an Elm programmer :)