[hombre_fatal]

I don’t get what’s unhealthy about anything on that page. Elm’s trade offs are in plain sight. If you don’t want them, then you have plenty of warning.

Frankly Elm has more of a problem with negative fanboying: people who have decided it’s not for them yet have to constantly show up to neener neener every time Elm appears on HN instead of just moving on.

It’s very weird to me as someone who uses Elm daily. We get it. You don’t like it and everyone needs to know it.

That it’s some sort of cult is just HN drama begging fantasy.

[crote]

> people who have decided it’s not for them

Rather the opposite, actually. Elm had a lot of promise, and a lot of people really liked what they saw. I consider myself among them: language-wise Elm is pretty much my dream language, and I would love to use it in all my products.

But then I tried actually using it, and it turned out one of the core Javascript API wrappers was broken, and rather than accepting one of a dozen pull requests to fix it, they just nuked it instead and made it impossible to write the same wrapper yourself.

People keep talking about it not because they dislike it, but because they are grieving what could have been. Those tradeoffs and warnings weren't there when we first fell in love with the language.

[jchmbrln]

This is me 100%. I open every Elm post on HN hoping against hope to find a reason to return.

[G4BB3R]

Could custom elements help in your case? Many people quit Elm after kernel code was removed, without knowing ports are not the only FFI option.

[josephcsible]

I wouldn't use Elm anymore even if there were alternatives to kernel code for everything I wanted to do. I don't want anything to do wit a language that imposes pseudo-DRM on me.

[irfn]

100% Agree.

[lolinder]

> While the language doesn’t get frequent updates (and that’s a good thing!)

This is the part that bugs me. It confuses frequent changes with frequent updates.

A language that changes frequently is a PITA to use, and it's good for a language to find a place of stability to where there aren't breaking changes every year. However, if I'm going to use a language in production, I expect it to not go 4 years without a bugfix update. It's not like Elm doesn't have any bugs to fix [0].

I'm a PL hobbyist and don't have any problem with someone having a hobby language that they eventually abandon—I've abandoned plenty myself. I don't even have a problem with someone deciding that they're comfortable with the risk of using someone's abandoned hobby project. It's just weird to see people seriously trying to argue that a 4-year break between releases is totally normal and all according to some master plan.

[0] 290 issues and counting: https://github.com/elm/compiler/issues

[PragmaticPulp]

> Frankly Elm has more of a problem with negative fanboying: people who have decided it’s not for them yet have to constantly show up to neener neener every time Elm appears on HN instead of just moving on.

Don’t forget those of us who worked at companies that tried adopting Elm and then got burned by it. Some of the changes were show-stoppers if you were actually using it in a way they didn’t like.

I don’t understand this desire to downplay and dismiss the critics as not having valid points. This is a textbook case of an open source project making some weird decisions, then grinding to a halt. It’s so weird to see people rush in to defend everything about it rather than admitting that, yeah, it kind of fizzled out and they didn’t really listen to the community and it came back to bite them.

[quickthrower2]

I think some negative fanboyism is because Elm promises a lot, and also delivers a lot of promises but there are some choices that sort of rub against our intuitions about software. Principle of least surprise.

Example 1: No typeclasses? Fine. But why is there comparable, which quacks like a typeclass and why can only kernel code use it? Practical implication: sorting, which is a bread and butter language/library feature is messy to code and inefficient at runtime.

Example 2: Why isn’t negative number pattern matching just fixed based the principle of least surprise and as a clear bug rather than gaslighting those who found 10 seperate examples of why pattern matching (which is a sugared if/switch) should blow up at compile time with negative numbers.

None of this makes sense. So I think it is good to warn people who are about to invest a lot of time. There will be edges where you wont have fun.

Finally; whether the api gets broken next month or there will be zero releases this decade is not clear. It is not a language where you can reason about it’s future, like maybe you can with JS, Java, Python, C# etc.

Elm is an experimental language. It is also production ready. That intersection is rare and I think that is what causes issues.

Haskell spent a long time as a toy before people made it a production language. And now it is no longer experimental on the whole. No benedict is going to do a 180 on Haskell. You are just gonna get more GHC language extensions for experimenting with ideas. I think this is better/more mature approach.

[hu3]

It's totally fine to run the project (or don't run) as the owner see fits and use it however one wants.

But let's not pretend the project is actively maintained and there are no bugs. That's what klabb3 alludes to.

Elm has this "this is fine" phenomenon where people like to pretend its a one-of-a-kind software that has no bugs doesn't even need a patch with bug fixes.

[hombre_fatal]

Do people pretend that? Or is it just an HN circlejerk that reports it be so?

I'm a regular user of the Elm ecosystem, like the Slack/Discord, and everyone talks casually about Elm's bugs. In the #beginner channel it's just "Yeah oops that's def a known issue, but you can work around that with X."

It's just that Elm is still a good tool despite its warts, and its bugs aren't catastrophic. Presumably that's the smoking gun for your "this is fine" phenomenon: that people still use it and dare to even enjoy it despite unfixed bugs.

[lolinder]

People absolutely pretend that! This whole subthread spun of from a discussion of https://iselmdead.info/, which says (emphasis added):

> Elm’s release cycle is (very) slow on purpose. ...

> While the language doesn’t get frequent updates (and that’s a good thing!), ...

> Why is it a good thing that Elm doesn’t get frequent updates? First of all, it means your code will last a long time! It also means the language is very stable, because features are carefully thought out before being implemented.

I have no problem with people enjoying Elm and acknowledging the bugs. I really dislike that this site gets posted every time people point out that there hasn't been an update in four years. A four-year break between updates is not "all part of the plan". It's not a slow release cycle. It's a sign that the creator ran out of steam but didn't want to delegate to a successor.

You seem to be reasonable in your approach to Elm, and that's great. But there absolutely is a contingent that tries to pretend that this four-year hiatus is part of Evan's master plan for Elm and is "a good thing", and it's reasonable for the HN crowd to call that out as problematic.

[awestroke]

No, it's that Elm fans defend the decision to never fix those bugs

[oxnrtr]

Stockholm syndrome. You know ... normal people in normal projects would just fix the bugs?

[plazma]

This is what I don't like about it. Other then that Even is running things differently and maybe it's not for you, but some people really like it and maybe some more will.

Take a look at https://elm.studio/about.html, please read comparison there. Elm does not want to be mainstream, people should really understand that.