Elm 0.19 Broke Us

I think there’s a very weird mismatch between the way the core language people are pushing for the adoption of the language, and then at the same time they will turn around and say “we’ll, it’s not even 1.0, yet, so what’d you expect”.<p>The way Elm is developed is fit for a language that has little to no users, and can take going so long between updates, that remove escape hatches needed to fill out the immaturity of the language.<p>It really saddens me to see it go like this, because I once had high hopes for Elm. Nowadays I see it purely as a stepping-stone into more advanced languages like PureScript and Haskell. Elm is there to hold your hand, but it seems it has no intention of ever taking you further than the basics.

I&#x27;ve heard of a few people discontent with Elm for the reasons mentioned in the article make a very successful jump to ClojureScript and being much happier about it.<p>It offers an MVU framework: re-frame. There are others too. Its community is very friendly and helpful, it loves to discuss the language itself. No one seems to think of themselves as more knowing. It has never ever broken backward compatibility. It&#x27;s a core tenet of the language to never break anyone ever. Finally, it has very good interop with JavaScript. And its getting better and better every release.<p>It&#x27;s also ran by a BDFL, actually more like two. Rich Hickey as the BDFL of the standard language design, and David Nolen as current implementer and main maintainer of ClojureScript. But they&#x27;re loved and admired. And if you disagree with their direction, you&#x27;re free to add your own features as a macro, that&#x27;s why they made the language a Lisp.<p>The language design prioritizes pragmatism. All discussion starts with: What exact problem are you facing for which there are no simple way to solve. And working backwards from real problems, solutions are added and new constructs are built.<p>The only thing is, it comes from a different school of thought opposite to strong static types. But it shares a lot in common, emphasis on pure functional code, immutability of variable and values. No OOP, everything is a function with support for higher order functions, closures and partial application. And the same focus on interactive live development.<p>If you don&#x27;t mind losing the strong static types, I highly recommend giving it a try. You&#x27;ll only miss the nice Elm error messages.

I think Elm can learn a lot from Rust before 1.0 here. Rust made some &quot;insane&quot; decisions that should have pissed off the community but did not mostly because of the way the communication was handled. There were obviously some disagreements along the way which caused some valuable community members to jump ship, but overall it was really well handled and the language became better as a result.

The reddit discussion for this post is a telling confirmation of the articles complaints about the community forums&#x2F;interaction: <a href="https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;elm&#x2F;comments&#x2F;9a0hc6&#x2F;elm_019_broke_us&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;elm&#x2F;comments&#x2F;9a0hc6&#x2F;elm_019_broke_u...</a>

I&#x27;m torn about this. I&#x27;m rooting for Elm and I think it currently might be the best frontend solution. I really like Evan&#x27;s focus on developer UX and simplicity. This means removing things, making the language smaller and simpler. And to do that you need to maintain a certain amount of control.<p>However this seems to have backfired. Too many in the community want this or that and&#x2F;or don&#x27;t feel their opinion is heard. Then they switch to something else. Unfortunatley I think something like ReasonML will win in the end. JS interoperability and just enough Algol syntax to staisfy the masses.<p>Evan is between a rock and a hard place here and it&#x27;s due to the current sentiment in frontend dev.

I agree that community management and handling of issues could be better in Elm, but I’m willing to overlook that due to the terrific quality and innovation of the end result. Elm has benefited greatly from vision and the willingness to take risks, which is much easier to do with less communication overhead and fewer contributors.<p>Maybe someday Elm will adopt a more community-oriented approach, but I don’t think that is necessary right now.

I looked at Elm a couple years back and decided on Purescript instead: <a href="http:&#x2F;&#x2F;www.purescript.org&#x2F;" rel="nofollow">http:&#x2F;&#x2F;www.purescript.org&#x2F;</a><p>Has a much better FFI story with JavaScript than Elm, and has a more powerful type system (higher kinder types, etc). Row polymorphism makes writing pure code a joy, the effects system is unobtrusive. I actually enjoy programming purescript more than Haskell.

I recently took on a contract to fix a busted elm project. There were no runtime exceptions but it was such a Frankenstein monster I couldn’t believe it.<p>If you’re doing any real work on the web, you’re going to have to use external libraries and code and such. You’re not going to have time to recreate an entire mapping framework in Elm or whatever and the minute you need to commingle in such a way you loose a major benefit of such system.<p>Also “no runtime exceptions” does not mean the application isn’t broken, does not absolve your developers from real testing and QA their changes.<p>Also it says a lot when someone wants to call their framework a kernel and patterns their behavior off you know who.

I would have liked to have seen custom operators stay around in 19, but I understand the motivations. I think it was in 18 they removed back-ticks for the same reason. Just makes it way easier for newcomers to learn the language.<p>As far as I understand it, the native modules lockdown had to take place. Period. The one thing that most attracts myself (and many others, I&#x27;m sure) to Elm is the guarantees that the compiler gives you towards ensuring no run-time errors. Give folks the ability to author and publish Elm native modules and the entire platform loses that guarantee.

I love Elm. Discovered it last year and loved the language so much that I went on a conference later in the year on my own budget.<p>I love how low the cognitive load of adding features is. Having a small baby, it helps a lot.<p>That being said, some things really confuse me, and especially the way the governance model is accepted and cherished. We have a `almighty god` deciding what will and not be done, the accepted reason being that it&#x27;s not 1.0 yet.<p>I mean, with 0.19 coming out, all IDE support went out the window and the answer from the author of the language is basically : &#x27;changes are known since last May, things should have been done already. I don&#x27;t even know what the status is&#x27;. Communication is at the minimum lacking tact. Others could say straight offensive for not-core users.<p>I understand PR is hard and not fun. But then find someone to do it for you, or act as to minimize it.<p>At the moment, the advantages of elm far outweight the issues for my personal use. But I really wonder about the long run, but I&#x27;m really afraid someone gets really pissed and forks the language in the long run, fragmenting and ending up destroying this great community. That would really be a waste.

I only briefly dabbled in Elm and I&#x27;m not terribly qualified to comment on specifics, but I had a similar, negative impression of the way the project is managed. Especially in comparison to many other open source projects.

I would be totally on board with these changes if an alternative way of doing things had been offered.<p>From the philosophical point of view they are exactly what is needed to allow Elm give as much guarantees as possible.<p>The sad reality is that very little pragmatism went into this release and now stuff like web-sockets won&#x27;t work [1]. This is very surprising because web-sockets are an use case where the Elm-architecture really shines.<p>Things like this reinforces my idea that while Elm is a very nice language I wouldn&#x27;t want to have it in production, or even in a side project, at least till it reaches 1.0 and becomes more stable.<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;elm-lang&#x2F;websocket&#x2F;issues&#x2F;27" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;elm-lang&#x2F;websocket&#x2F;issues&#x2F;27</a>

I was experimenting with Elm around .14 or .15 if I remember correctly. At the moment the language allowed you to use prime(‘) to name variables, and that was the suggested way if I had to guess by the tutorials and examples.<p>During next release they decided that primes as part of a name were not their cup of tea and removed it. Just like that. When I asked why was prime no longer allowed, since I couldn’t see any good reason behind it, I got the usual: “it’s pre-1 release you should expect things to change, etc.”<p>What left a bitter taste in my mouth was that this change had nothing to do with the language itself. It seemed as if they decided that using prime is not good style, so they forbid it.<p>I haven’t touched Elm since.

For those of us who desperately want to put javascript (the entire language) behind us, many of the &quot;problems&quot; this article mentions are features.<p>Refusing, on principle, to be inter-operable with unchecked javascript code is a <i>defining virtue</i> of Elm.<p>edit: grammar

Whilst I get the point about the community leadership being more autocratic than others, the Elm language itself has always been opinionated - thus it&#x27;s difficult to empathise with the rest of the sentiment of this post. An 0.x release, two years in the making, drops two features such that it can further fulfil its design goals and everything is ruined?

I really enjoy the fable-elmish philosophy, I think that the community is great compared to what the author of this post experienced, but..BUT, the platform on the whole is just too immature. I remember trying to compile jquery using the otherwise great ts2fable.. and it was, and probably still is, pretty much impossible. Or trying to use fable-elmish and getting “undefined behaviour” in a “hello world” test page. Luckily I discovered pretty soon these limitations, but I think that when a platform is not battle tested by millions of people you’ll always get this kind of grief. So just test if elm or fable-elmish or whatever framework work well for you before committing head first into it..

One of Elm’s main focuses is code that is not possible to crash. Once I groked that, native modules going away in favor of ports made much more sense.

In the end I think it&#x27;s a good thing to be strict in language design and openly reject many ideas and suggestions. I guess it&#x27;s a case of &quot;too many cooks spoil the broth&quot;.<p>Most languages have too many features anyway so removing them can be a positive thing.

And this is why I love TypeScript: It&#x27;s just JavaScript, with a type system. If it&#x27;s not in the standard then it&#x27;s not in TypeScript (by default). There&#x27;s no risk to adoption.

Custom operators make code <i>more</i> readable when used appropriately; and any aspiring general purpose language that refuses to support them is cutting off the nose to spite the face.

I just wanted to let you know that a possible alternative functional MVU is Mithril&#x2F;Meiosis<p><a href="http:&#x2F;&#x2F;mithril.js.org" rel="nofollow">http:&#x2F;&#x2F;mithril.js.org</a> - vdom lib - for the V <a href="http:&#x2F;&#x2F;meiosis.js.org" rel="nofollow">http:&#x2F;&#x2F;meiosis.js.org</a> - state pattern in conjunction with streams to give you the M&#x2F;U<p>Check out the gitter chatrooms, the communities for both are very FP oriented, and working on making it easier to do FP all the time.<p>this guy came from elm: <a href="https:&#x2F;&#x2F;github.com&#x2F;pakx&#x2F;the-mithril-diaries&#x2F;wiki&#x2F;Coming-From-Elm" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;pakx&#x2F;the-mithril-diaries&#x2F;wiki&#x2F;Coming-From...</a>

Wow: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=17843149" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=17843149</a>

Can somebody take pity on me and explain why the ports system that&#x27;s supposed to be used for JS integration can&#x27;t replace the native modules?

Another proof that sticking with platform languages is a better option for productivity, even if the languages might miss a few shinny features.

Sounds like reasonable removes to me, custom operators are a pain.

had to realize for a sec that they weren&#x27;t talking about the mail client

Article aside, the HN and Reddit comments really reflect our toxic entitlement culture. How many comments here seem to exist for no other reason but to get in a negative jab of their own?<p>I&#x27;m reminded of Rich Hickey&#x27;s great response (<a href="https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;Clojure&#x2F;comments&#x2F;73yznc&#x2F;on_whose_authority&#x2F;do1olag&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;Clojure&#x2F;comments&#x2F;73yznc&#x2F;on_whose_au...</a>) to a similar situation.

And that, in short, is why I prefer <i>really</i> freakin&#x27; old languages for doing real work.

These kind of stories make me value Go&#x27;s approach a lot more. You just have to worry about making your product better.

This was confusing to read if you only knew about the email client Elm. In general I wish people spent more time naming things better, and reducing naming clashes.