4 ms·

Oh my God, I had no idea this project was still alive. I don't mean to throw any shade but I had assumed that the lid was on this turkey.

ale 2mo ago
I know right. I’m glad DSLs have fallen out of fashion. Just use the platform.
- chipdale 2mo ago
  I can understand why developers might not care for DSLs, especially when they force a choice between entirely different toolsets and toolchains. However, I feel people often miss the real value of a good DSL: it's not about the syntax, but about providing hardened semantics that can bolster or guarantee desired qualities. Elm, for instance, provides value insofar as it makes producing runtime exceptions significantly more difficult. Personally, I hope languages like Lean, which provides exceptional support for creating DSLs within the language, renew interest in semantically sound DSLs, especially if we insist on using LLMs.
  - lioeters 2mo ago
    I recently learned about that too, how Lean provides ways to create new language syntax and DSLs, which is (on the surface) similar to Lisps like Racket. It's like operator overloading but way more flexible and general purpose. I'm wary of such language features, convenient for specific purposes (like working with vectors or matrices) but I'm afraid it's too powerful for normal usage, if everyone starts building their own DSLs and syntaxes, it would likely make the typical codebase difficult to read and understand. For example, the C++ template metaprogramming madness, it can be used responsibly but in my opinion it was detrimental to the language ecosystem.
  - rupertlssmith 2mo ago
    And then there are sealed DSLs... Byte encoder/decoder in Elm are opaque, so their implementation is hidden. A smart compiler, such as the one I am writing, can take advantage of that with compiler intrinsics that replace the implementation with something that the compiler itself optimizes.
subarctic 2mo ago
Same, I basically assumed the community around it had died out. But i guess the sole maintainer/creator is still around. I never used elm except for doing a tutorial, but lately I've built a full stack gleam app (using coding agents for the most part, with a lot of control in the beginning on the structure of the code) and have found that process works quite well
shiqi_Rao 2mo ago
wow careful, this turkey still has some kick left in it!
hobofan 2mo ago
The project was dead. The previous release was 7 years ago, where it stopped because the creator (same as author of this announcement) stopped maintaining it and since the community hasn't progress beyond a BDFL-model that's where it died. So it was dead, it just now has been resurrected (and AFAIK with a whithered community in the meantime).
- G4BB3R 2mo ago
  Not dead, Evan was working on Acadia (elm on db) which is about to be released, to make Elm development and funding more sustentable.
- asgr 2mo ago
  your definition of dead is elms definition of stability, I think :D haha javascriptland really warps peoples minds on stability and project-liveness
  - jlengrand 2mo ago
    This, 200 times. No weekly news does not mean dead. In some specific places like this one, it means stable. (And also arguably, for good or bad reasons, why it will never become mainstream).
  - kccqzy 2mo ago
    You are not entirely wrong, but there’s still a difference between being dead and very stable. Among the languages that compile to JS, I would look at ClojureScript as the prime example of stability rather than Elm. I mean Elm has removed features breaking compat; ClojureScript doesn’t do that.
    - hobofan 2mo ago
      > I mean Elm has removed features breaking compat To be fair, Elm hasn't made it to 1.0 (yet). That's where languages should make breaking changes before being stuck with the flaws forever.
kayo_20211030 2mo ago
I'm glad it's back. Elm had such a remarkable elegance I was always rooting for it.
donatj 2mo ago
I'm not deeply involved in the community, but I know people who were, and my understanding is the removal of custom infix operators lost a lot of community support. Very popular feature removed specifically because the creator of the language didn't like it, and despite large community cries for it to remain. In my eyes, it was probably the right decision technically, but deeply unpopular and probably the wrong decision socially.
- dunham 2mo ago
  Not exactly removed, the feature was still there, but could be used only if your module was in Elm namespace (the compiler checked). It was kind of a "no soup for you" situation, which bothered me. Elm served its purpose for me - an example of a small language with great tooling and error messages. And the strictness was helpful in learning to do things the "proper" way in the Elm model, even if I did reach for escape hatches in later projects. E.g. writing a notion-like application in Elm, I had to walk through my data twice - once to render it and another time to collect cache misses. With hyperapp, I broke purity a little and accumulated the information on the side.
pseudocomposer 2mo ago
I’ve been using Elm professionally at a very profitable, lean company the last two years. (Didn’t know it coming in, but had enough React, Redux, and other experience to learn quickly.) The Elm community would call this a feature. How much React code you wrote 6-8 years ago will work perfectly and identically with today’s React toolchain? It’s a whole different set of values. Good React code in 2026 looks like any compiling Elm code since 2016.
- OhSoHumble 2mo ago
  Oh yeah, no shade against the language itself. I had fun learning it and using it for some toy development years ago - and the TEA still exists in multiple library implementations. Just wild to see the creator of the language emerge from the fog like that.
- dminik 2mo ago
  Any code you wrote on a React version from 6 years ago will still work the same on that React version today. Let's make that a fair comparison. I get that some people like stability, but that is quite different from going without updates for 6+ years.
  - pseudocomposer 2mo ago
    I don’t like being disagreeable, but just no. On both of these. First, the comparison is perfectly fair. Elm 0.19.1, 6 years ago/0.19.2 today, React 16.1 6 years ago/19.2 today. Literally identical conditions. What is unfair? Which required app developers to do more work? Which saw more security issues among its releases? Second, not needing updates for 6 years, and having zero security holes in that time, is the definition of stability. This isn’t really a matter of opinion or preference. I do see the appeal in other frameworks (ecosystem size, easier to find devs), but the appeal of Elm truly is stability. And it really is that much better than nearly everything else that runs in the browser, in that regard. No framework that allow you to use actual JS (or “transpiles” but gives you the full JS API, like Coffee/TypeScript), will ever offer the level of stability Elm offers (aside from maybe the web standard APIs on which Elm is narrowly built).
- 2mo ago

ale 2mo ago

I know right. I’m glad DSLs have fallen out of fashion. Just use the platform.

chipdale 2mo ago
I can understand why developers might not care for DSLs, especially when they force a choice between entirely different toolsets and toolchains. However, I feel people often miss the real value of a good DSL: it's not about the syntax, but about providing hardened semantics that can bolster or guarantee desired qualities. Elm, for instance, provides value insofar as it makes producing runtime exceptions significantly more difficult. Personally, I hope languages like Lean, which provides exceptional support for creating DSLs within the language, renew interest in semantically sound DSLs, especially if we insist on using LLMs.
- lioeters 2mo ago
  I recently learned about that too, how Lean provides ways to create new language syntax and DSLs, which is (on the surface) similar to Lisps like Racket. It's like operator overloading but way more flexible and general purpose. I'm wary of such language features, convenient for specific purposes (like working with vectors or matrices) but I'm afraid it's too powerful for normal usage, if everyone starts building their own DSLs and syntaxes, it would likely make the typical codebase difficult to read and understand. For example, the C++ template metaprogramming madness, it can be used responsibly but in my opinion it was detrimental to the language ecosystem.
- rupertlssmith 2mo ago
  And then there are sealed DSLs... Byte encoder/decoder in Elm are opaque, so their implementation is hidden. A smart compiler, such as the one I am writing, can take advantage of that with compiler intrinsics that replace the implementation with something that the compiler itself optimizes.

subarctic 2mo ago

Same, I basically assumed the community around it had died out. But i guess the sole maintainer/creator is still around. I never used elm except for doing a tutorial, but lately I've built a full stack gleam app (using coding agents for the most part, with a lot of control in the beginning on the structure of the code) and have found that process works quite well

shiqi_Rao 2mo ago

wow careful, this turkey still has some kick left in it!

hobofan 2mo ago

The project was dead. The previous release was 7 years ago, where it stopped because the creator (same as author of this announcement) stopped maintaining it and since the community hasn't progress beyond a BDFL-model that's where it died. So it was dead, it just now has been resurrected (and AFAIK with a whithered community in the meantime).

G4BB3R 2mo ago
Not dead, Evan was working on Acadia (elm on db) which is about to be released, to make Elm development and funding more sustentable.
asgr 2mo ago
your definition of dead is elms definition of stability, I think :D haha javascriptland really warps peoples minds on stability and project-liveness
- jlengrand 2mo ago
  This, 200 times. No weekly news does not mean dead. In some specific places like this one, it means stable. (And also arguably, for good or bad reasons, why it will never become mainstream).
- kccqzy 2mo ago
  You are not entirely wrong, but there’s still a difference between being dead and very stable. Among the languages that compile to JS, I would look at ClojureScript as the prime example of stability rather than Elm. I mean Elm has removed features breaking compat; ClojureScript doesn’t do that.
  - hobofan 2mo ago
    > I mean Elm has removed features breaking compat To be fair, Elm hasn't made it to 1.0 (yet). That's where languages should make breaking changes before being stuck with the flaws forever.

kayo_20211030 2mo ago

I'm glad it's back. Elm had such a remarkable elegance I was always rooting for it.

donatj 2mo ago

I'm not deeply involved in the community, but I know people who were, and my understanding is the removal of custom infix operators lost a lot of community support. Very popular feature removed specifically because the creator of the language didn't like it, and despite large community cries for it to remain. In my eyes, it was probably the right decision technically, but deeply unpopular and probably the wrong decision socially.

dunham 2mo ago
Not exactly removed, the feature was still there, but could be used only if your module was in Elm namespace (the compiler checked). It was kind of a "no soup for you" situation, which bothered me. Elm served its purpose for me - an example of a small language with great tooling and error messages. And the strictness was helpful in learning to do things the "proper" way in the Elm model, even if I did reach for escape hatches in later projects. E.g. writing a notion-like application in Elm, I had to walk through my data twice - once to render it and another time to collect cache misses. With hyperapp, I broke purity a little and accumulated the information on the side.

pseudocomposer 2mo ago

I’ve been using Elm professionally at a very profitable, lean company the last two years. (Didn’t know it coming in, but had enough React, Redux, and other experience to learn quickly.) The Elm community would call this a feature. How much React code you wrote 6-8 years ago will work perfectly and identically with today’s React toolchain? It’s a whole different set of values. Good React code in 2026 looks like any compiling Elm code since 2016.

OhSoHumble 2mo ago
Oh yeah, no shade against the language itself. I had fun learning it and using it for some toy development years ago - and the TEA still exists in multiple library implementations. Just wild to see the creator of the language emerge from the fog like that.
dminik 2mo ago
Any code you wrote on a React version from 6 years ago will still work the same on that React version today. Let's make that a fair comparison. I get that some people like stability, but that is quite different from going without updates for 6+ years.
- pseudocomposer 2mo ago
  I don’t like being disagreeable, but just no. On both of these. First, the comparison is perfectly fair. Elm 0.19.1, 6 years ago/0.19.2 today, React 16.1 6 years ago/19.2 today. Literally identical conditions. What is unfair? Which required app developers to do more work? Which saw more security issues among its releases? Second, not needing updates for 6 years, and having zero security holes in that time, is the definition of stability. This isn’t really a matter of opinion or preference. I do see the appeal in other frameworks (ecosystem size, easier to find devs), but the appeal of Elm truly is stability. And it really is that much better than nearly everything else that runs in the browser, in that regard. No framework that allow you to use actual JS (or “transpiles” but gives you the full JS API, like Coffee/TypeScript), will ever offer the level of stability Elm offers (aside from maybe the web standard APIs on which Elm is narrowly built).
2mo ago