[dd82]

Elm as a language is really nice, and I do like the goals of the project. I tried it out a bit, its a mind-bending paradigm for someone coming from OOP/prototype (Python, Java, JS) and I enjoyed the challenge.

The community, on the other hand, is what turned me off. It does seem very unfriendly to newcomers. In addition, https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/ amongst others, is an entire turnoff. And seems like this perception isn't isolated and has been discussed at https://news.ycombinator.com/item?id=22821447

I hope things work out well for you in this project with Elm, now and in the future. But it doesn't seem like any of the issues with the community have been even attempted at being addressed, so I don't think I will give Elm another try.

[bwanab]

I had a comment on that HN thread in which I mentioned how I liked elm, but probably wouldn’t use it again for many of the reason given in that post.

I’ve made a liar out of myself. I needed a GUI for a project I’ve been working on using Elixir. After looking at native Elixir alternatives (I even coded up a prototype using Scenic), I decided to give Elm another shot and I’ve had a great experience both with it and with the community.

[zhengyi13]

What changed? The community? You? Something else?

[kbd]

Why not use Phoenix LiveView?

[antew]

That "Why I'm Leaving Elm" post comes up on most Elm discussions, and I would implore anyone to give it a try for themselves before deciding against it. I've been working in Elm professionally for a few years now and I think Luke's experience in that blog post is certainly atypical.

For writing web applications Elm is an excellent language to work in, the compiler is friendly and fast, there are basically zero runtime exceptions, refactoring is a breeze, and it really shines on larger code bases. Web-components are discounted pretty quickly in that post, but they really fill an important gap where ports are awkward.

In the years I've been using it I haven't run across a problem that I couldn't solve in a nice way. That is not to say my experience is universal, but the negative posts tend to garner a lot more attention than positive posts, and I'd feel bad if someone were to skip over what is an awesome project due to them!

[dhucerbin]

> I think Luke's experience in that blog post is certainly atypical.

> the negative posts tend to garner a lot more attention than positive posts

On the other hand, my team was very unsatisfied with Elm and when we bring those issues to community we were quickly asked to leave. Of course it is fair but please note that negative opinions are discouraged and thus not common. We just disengaged from community and started elsewhere.

[antew]

Sorry, I didn't mean to say that nobody has negative experiences with it, but that "X considered harmful" style posts tend to get more attention on sites than positive experiences generally do.

What was something that left you unsatisfied with Elm? The biggest one for me until relatively recently was handling state updating state from leaf components, it was fairly cumbersome to have `(Model, Cmd, ExternalMsg)` in lots of places. At work we recently switched to the Effect pattern (https://sporto.github.io/elm-patterns/architecture/effects.h...) which has alleviated a lot of the overhead.

[dwohnitmok]

FWIW the creator of the Effect pattern has some pretty deep reservations about Elm (http://reasonableapproximation.net/2019/10/20/the-effect-pat...). His reservations end up being the same ones that get hashed out all the time over HN (JS interop and the development model).

[leshow]

It's not just luke, here's a couple more, two of these I remember in particular the others are just from a google search

https://reasonablypolymorphic.com/blog/elm-is-wrong/

https://dev.to/kspeakman/elm-019-broke-us--khn

https://blog.bitsrc.io/elm-and-why-its-not-quite-ready-yet-2...

https://medium.com/@cscalfani/the-biggest-problem-with-elm-4...

I've come to view Elm as someones personal compiler project. If you are good with the decisions made then you're going to have a fine time, otherwise you probably won't

[antew]

I think we are somewhat in agreement, Elm is certainly Evan's language and framework, and if you live within the boundaries of it you'll have a pleasant experience.

I have read all of the bad experience posts on Elm because I've spent a while working with it now and it is always valuable to see someone else's perspective on it. In practice the pain points either haven't really been a problem for me, or I've found a satisfactory way around them using web components, ports, code generation, or other ways.

My experience is just more anec-data and I know it won't represent everyone's experience. I'd encourage anyone hesitant about Elm to give it a go, it's been a joy to work with.

[dsiegel2275]

Maybe you've had direct interactions with community members, but it is very unfair for you to characterize the Elm community as "unfriendly" based off of your reading of a few posts.

My actual experience has been exactly the opposite: I've interacted with many members of the community (at multiple Elm conferences, in the Slack, and even twice met members of the community for in-person meetings when they were visiting near my office). All of these interactions have been the entirely opposite of "unfriendly".

[boxed]

Of course the community is friendly: all dissent is ruthlessly crushed and removed. It feels very friendly and nice until you start to dissent, then it turns on you hard.

I posted an article saying I now recommended elm and was a part of the reason we chose it for our product. But I also said some things I disliked about elm.

So I was banned.

No warning.

[razze]

Banned from where the discourse?

[boxed]

Reddit

[prophesi]

Sounds like Elm is run by a benevolent dictator, as is common with open source, and ended up making a difficult design choice that a lot of people didn't like.

As a newcomer to the language, I've had a pleasant experience with the community (r/elm and the Slack channel). But I can imagine drama could quickly arise if you were to debate design choices with the team behind the language.

[jlengrand]

I have read those, and have built a few side-projects in Elm. There is a large difference between 'the community' as in the folks deciding of the future of the language, and 'the community' aka the huge majority of the users of the language. Elm has one of the most welcoming communities I've ever seen. They are ready to explain the same concepts again and again in their slack and many of them (quite a few being here in the comments actually) are not only helpful in Elm, but wholesome humans as well.

Elm is IMHO extremely friendly, especially to newcomers. The leadership style however is up for debate but that's another story.

I wouldn't bet my company on Elm personally, but I can't recommend it enough for side projects and folks interested in learning more FP or simply for fun.

[tabtab]

Why should UI's and their API's be tied to specific programming languages? What's needed is an an interactive stateful GUI markup language that supports the common GUI idioms. (At least in the domain of business CRUD.)

Rather than start from scratch, perhaps the "GUI browser" can be based on the Tk or Qt ui kits, since they are road-tested and exist.

[G4BB3R]

Using elm-ui instead of html/css has many advantages: 1) Tree shaking will remove every component/style that is not being used, so asset size will be smaller 2) It is type safe and avoid many mistakes possible in html/css 3) Predictable views and easy to debug, there is no weird css selector or a new imported spreadsheet that will affect the style of your entire app.

[smaddox]

That's an interesting idea. There could be a sort of markup language for describing the text and other elements. A sort of hyper-text markup language. And then there could be a separate declaritive language for styling. Of course, you'll need something less declaritive to implement advanced interactivity, but that could just be a small, simple scripting language.

:-)

[riwsky]

But if you did that, TCP/IP would no longer be a great fit. You’d want some sort of hypertext-specific transport protocol, I think.

[pharmakom]

Elm is a language but also a design pattern. You can implement it in most languages, but Elm makes it particularly nice.