Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Road to Elm 1.0

elm-lang.org

Post reply on HN
Print view View original

141–150 of 192 posts

Re: Road to Elm 1.0

#141

Post by bmurphy1976 »

crote wrote: post #137
hombre_fatal wrote: post #107

Earlier quoted context omitted.

This really overstates the problem and situation. Synchronous interop was removed from Elm. That sucks for synchronous stuff and anything too trivial to be worth async interop. But async interop is still available. Anything networked, like websockets, is a natural fit for async interop. i.e. a Send(Req) | Recv(Res) port. It's fine to be mad that a "BDFL" decided on a different set of trade-offs than your preference,…

I'm not mad, I'm disappointed . Elm was quite promising prior to this, but 0.19 essentially killed it. And the problem isn't just that sync interop was removed. That would've been fine . It's the double-whammy of 1) killing sync interop, 2) making async interop libs impossible, 3) still allowing it for "blessed" libraries, and 4) gaslighting everyone else that they were Holding It Wrong. Breakage is totally fine, I n…

Don't fret it. Many of us were in the same boat. Evan can do whatever he wants, but we can also call it out when it's wrong.

I personally made the same decision. It became very clear to me that Elm was not the foundation for me to build a business on.

Re: Road to Elm 1.0

#142

Post by 3836293648 »

rapind wrote: post #48
auslegung wrote: post #19

About two years ago I was experimenting with ChatGPT vibecoding a snake game in the browser in elm, because elm is my favorite language. It was rough going and I concluded at the time that LLM‘s might kill elm. Today I use elm in production and LLMs are vastly better at it, and if anything I think LLM‘s might increase elm adoption because it is the ideal language for an LLM right now. It’s a simpler language than mos…

Maybe it's improved, but I was very disappointed to find agents constantly tripping over significant white space with Elm (Claude Code). Always struck me as strange since they are very proficient with python... and Elm has been one of the most stable modern languages (so stable that people complain about it never changing!). I think the last time I tried was a year ago though, so I assume it has improved.

I don't think anyone complained about the language changing, it was a lack of trust in the language due to the compiler not getting any updates. You can still improve the compiler without having to change the language.

Re: Road to Elm 1.0

#143

Post by fpoling »

hollowturtle wrote: post #128
RussianCow wrote: post #69

Earlier quoted context omitted.

That's not why Elm is an ideal language for LLMs: it's because, if it compiles, it's most likely working software. Agentic workflows have gotten significantly better over the last year, so LLMs using languages like Elm, Haskell, or even Rust have an amazing feedback loop where even lower quality models can keep trying until things compile.

can keep failing til you're tired of having the agent running in loops, as I said it doesn't matter, agent tools are more effective with models trained with a lot of elm examples

Yet Elm due to its simplicity does not need a lot of examples. Language itself is small and blessed way to architecture things consist of few patterns. Then things are composable. This is ideal for LLMs.

The price for that is verbosity. What in other languages are hidden behind async and complicated libraries in Elm has to be done explicitly resulting in boilerplate. But that is never a problem for LLMs.

Then Elm compiler has one of the best error messages. This helps agents a lot.

Then Time Machine debugger is another big help for agents as they have access to the full execution trace of the program. The trace is much smaller than would be necessary for other languages and typically fits into content window.

Re: Road to Elm 1.0

#144

Post by Aurornis »

hombre_fatal wrote: post #107
crote wrote: post #97

Earlier quoted context omitted.

On top of the already-mentioned JS interop breakage, Elm 0.19 also dropped native Websocket support[0]. The API had issues (fair), so it was dropped rather than improving it due to wanting to do it perfectly (okay, I guess), buuut due to the JS interop restrictions this meant that 3rd-party experiments or alternatives were impossible (??), which meant that any use of Websockets was in practice now completely impossib…

This really overstates the problem and situation. Synchronous interop was removed from Elm. That sucks for synchronous stuff and anything too trivial to be worth async interop. But async interop is still available. Anything networked, like websockets, is a natural fit for async interop. i.e. a Send(Req) | Recv(Res) port. It's fine to be mad that a "BDFL" decided on a different set of trade-offs than your preference,…

> It's also a learning lesson for people who thought that a tiny, pre-v1.0 ecosystem that already had breaking changes would never break again especially in a way they disagree with. I think it's time to just accept the lesson.

This gives flashbacks of the last time I discussed this 7 years ago: Even trying to bring it up would bring denial that it was a problem. It was your fault for using it wrong. If you could demonstrate the cases where it continued to be a problem, it was still your fault for using the project.

Even the pre-1.0 projects I use that have breaking changes will announce a transition period and gradually deprecate APIs over several releases. Community feedback is monitored and the deprecated API may be kept longer than originally planned until suitable alternatives can be produced. Elm wouldn't even consider any of these.

The direction of the argument also changes based on the situation. When Elm was dropping breaking changes in 0.19 the story was that it's a fast changing pre-1.0 project and it was our fault for not expecting breaking changes.

Then they went 7 years without a release and the argument became that Elm was so stable that it was our fault for expecting updates to a mature and stable project.

Re: Road to Elm 1.0

#145

Post by berns »

jacobjuul wrote: post #53
willdr wrote: post #28

Did they walk back that thing where certain language features could only be used by the Elm team? That seemed like a language-killer to me.

what?

The compiler has hard coded domains that control who can use certain features. For example, custom operators aren’t allowed, but Evan is able to use them.

Re: Road to Elm 1.0

#146

Post by rupertlssmith »

crote wrote: post #97
adastra22 wrote: post #77

Earlier quoted context omitted.

What feature is that?

On top of the already-mentioned JS interop breakage, Elm 0.19 also dropped native Websocket support[0]. The API had issues (fair), so it was dropped rather than improving it due to wanting to do it perfectly (okay, I guess), buuut due to the JS interop restrictions this meant that 3rd-party experiments or alternatives were impossible (??), which meant that any use of Websockets was in practice now completely impossib…

Elm was better without custom kernel modules and sync JS-interop.

It kept the Elm kernel small and portable. It forced the 3rd party package eco system to innovate and create things rather than just wrap existing Javscript libraries.

It has enable me to port the small kernel now to C++ for an Elm to native compiler.

Also, if you really wanted to bypass it and have your own kernel, that was always possible and not hard to do. Even in 0.18 custom effects modules could not be shared on the official package site.

Re: Road to Elm 1.0

#147

Post by rupertlssmith »

3836293648 wrote: post #142
rapind wrote: post #48

Earlier quoted context omitted.

Maybe it's improved, but I was very disappointed to find agents constantly tripping over significant white space with Elm (Claude Code). Always struck me as strange since they are very proficient with python... and Elm has been one of the most stable modern languages (so stable that people complain about it never changing!). I think the last time I tried was a year ago though, so I assume it has improved.

I don't think anyone complained about the language changing, it was a lack of trust in the language due to the compiler not getting any updates. You can still improve the compiler without having to change the language.

Yes. But that is about to change, and the compiler is now getting the updates it needs.

Mostly the compiler was fine, we could do with some bug fixes in core packages - not many, but there are a small number of long time bugs that should really be sorted.

Re: Road to Elm 1.0

#148

Post by rupertlssmith »

chipdale wrote: post #31
ale wrote: post #8

Earlier quoted context omitted.

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

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…

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.

Re: Road to Elm 1.0

#149

Post by tensegrist »

surprisetalk wrote: post #10

I wrote a thing in 2023 about why I'm still using Elm: https://taylor.town/elm-2023 It's 2026, and I'm still using Elm for all the same reasons :) As an added bonus, Claude seems to play very very nicely with Elm: https://taylor.town/diggit-000

the list numbering in that first link is a bit surprising

Re: Road to Elm 1.0

#150

Post by dminik »

wk_end wrote: post #127
auslegung wrote: post #60

Earlier quoted context omitted.

How does that bear on my comment?

Well, you're suggesting a reason to choose Elm is stability - a lack of breaking changes. But Elm is actually notorious for its wildly unpopular, dramatic, community-fracturing breaking changes. Backwards compatibility is not a concern for them. It's a little tricky though, because the comment you were replying to was talking about the lack of updates. And in that sense, Elm is now very stable - no breaking changes (…

Dont worry, if breaking changes start happening, people will magically have always been saying it's good, actually.
Post reply on HN