Elm 0.19 released!

Elm just have been released a few hours ago, there are a lot of new cool things like smaller assets, death code elimination and faster compiler times, check the links for more info

Blog: http://elm-lang.org/blog/small-assets-without-the-headache
Release Notes: https://github.com/elm/compiler/blob/master/upgrade-docs/0.19.md


Is anyone still using Elm with Phoenix? We used to get a lot of posts about it but it seems to be mentioned less these days?

Elm is interesting but it is so limiting compared to bucklescript or purescript or so that I think most people have realized that and moved on… >.>

/me is one such person

Plus here we now have the awesomeness of things like Drab. ^.^


Me too! I still prefer ReasonML over Ocaml, just for personal preferences (Now ReasonML with less semicolons!), I just think was relevant to share the news ^^, in overall it was a really good update for Elm but still lacking on libraries and SSR IMO, I get tempted with the small app size, but ReasonReact is easier to go (At least for my project)

I think the “hype” of Elm have past after all this time


I don’t mind the elm language as such. I also think that bucklescript is much nicer to work in. But what puts me off elm is how it is being maintained.

This release took ~18 months, during which there were no bug fixes or anything done with the 0.18 release. A number of concerns about the system were referred to the new 0.19 release. Then when 0.19 release is finally out I find it quite underwhelming.

Yes, small assets and faster compile times was a must to be competitive. These optimizations could have been worked on in the background while doing ongoing work on other parts of the ecosystem separately. Nothing is mentioned about issues opened up against 0.18. Are they fixed? No longer there?

I don’t feel confident I know where the language is heading. Will they have bug releases? What will be in the next release?

I acquired the “Elm in Action” book which was due last December. It is not finished and has now (actually a while back) been delayed to Spring 2019.

Their recommended SPA example (https://github.com/rtfeldman/elm-spa-example) has this as a commit message: “Upgrade to 0.19, rearchitect everything!”. The commit itself touches 80 files. This means (assuming they have actually included any outstanding bug fixes in the 0.19 release) you would have to do lots and lots of work to take advantage of this. And then there are no guarantees that we won’t be in the same situation again where they abandon work on 0.19 to focus on something in the future which you do not get told what is going to be included.


I thought as much - definitely less mention of it recently.

ODL - you have done a great job of evangelising Bucklescript :lol: (I’m still going to check it out at some point!)


:heart_decoration: :003: :heart_decoration:

Go @grych!


As in discussion so far - development/release process is concerning. Moved on to PureScript, halogen is as capable as Elm and you get full Haskell power.

1 Like

Well, I’m still using Elm and I like it! So there’s at least one :grinning:

I suspect there might be a bit more Elm-related activity around here in the near future, as people who are using Elm + Phoenix come back out of the woodwork.

One important issue for people who want to upgrade to 0.19 is that there’s currently no direct way to use Phoenix Channels in Elm. It seems like the library that most people were using will no longer work in 0.19 because it relied on undocumented “native code”. It sounds like an official update to the Elm websockets package should be coming soon, but people will need a pragmatic solution in the meantime. So I’m guessing there may be some discussion about how best to handle this via Elm’s “ports” interface and Phoenix Channels’ JS client.

I hope everyone will be nice and supportive if Elm people come here for some advice, even if you do have some misgivings about the language itself.


Elm is different, and I think variety is all too lacking in the dev community.

Elm gives you things which could could only dream of elsewhere - and it refrains from giving you things which are everywhere.

I can understand why some don’t like it, but I love it.


What are those things? Genuinely interested :slight_smile:

1 Like

One thing that springs to mind that I haven’t seen in other languages (although maybe Haskell and OCaml can do this too, I don’t know) is the compiler-led refactoring. For example, when I read this:

I just thought “I bet it wasn’t a big deal at all”. Refactors that would be horrendous in most languages are really straightforward in Elm. You just change something in one file and the compiler walks you through all the things you need to fix, with friendly error messages that make it obvious what to do. You don’t really even need to pay much attention… you can be reasonably confident that once it compiles again, it works.

I think people hear about Elm’s “friendly error messages” and think well, that’s a nice-to-have but I’m not going to go crazy over it. But the real advantage of the error messages + the compiler + the strong type system (IMO) is that you can make big changes to your code without worrying about subtly breaking things.


I would really like to dive into a good functional replacement for JS, and for a while I’ve been eyeing Elm, but I must admit that most of what I read about it in this forum specifically is making me reconsider :smiley:

But what to pick? ReasonML seems to be picking up popularity but it’s still pretty new. OvermindDL1 swears by OCaml and Bucklescript, but it would mean diving into that ecosystem. Purescript seems very cool, but my Haskell is still not that great, and I’ve seen some code samples… there’s no way I can ever hope of introducing something that obtuse into a team environment.

So I’m really torn about just saying Elm is good enough or picking something else :slight_smile:

1 Like

Just try it and come to your own conclusions. Even if you’ll never use it “in anger” it’s worth experiencing. Elm has a way of enforcing a certain discipline on you that feels like it’s getting in the way at first but eventually you’ll see that they are “good constraints”, i.e. they make your code better for the most part - that is until you are ready to grow beyond them.

The takeaway tends to be that there are constraints that improve your code even if they are inconvenient in the short term. So one can benefit by adopting these constraints voluntarily in a more lax (or differently structured) environment - where it is possible to bypass them when it is necessary (rather than simply convenient).

According to Building a Graphical IDE in Elm/Purescript, PureScript (Halogen) can be pretty demanding even if it is less constraining than Elm - interestingly the same group of people dropped down to HTML5, CSS, SVG, JavaScript with D3.js for their most recent venture.

The difference between ReasonML and Bucklescript (i.e. it is the same language underneath) is simply one of syntax and as we should know by now, syntax is utterly irrelevant. That being said over the short term one should expect more ReasonML content to be published - and while I think the “proximity to JavaScript” argument is bogus (to attract JS devs) I do think ReasonML has a positive effect on your ESnext code.

The big question is whether there is enough momentum in the ReasonReact community to carry on should Facebook decide to drop it (e.g. https://reasonml.chat/ isn’t that busy yet). And more importantly, what is Bloomberg going to do with Bucklescript if Facebook looses interest in ReasonML?


Yeah that’s a standard strongly-typed language (even not so strong) feature and is why I like type systems so much and is easily the biggest thing that Elixir lacks for me. But yeah, anything from OCaml to Haskell to even weaker typed like C and C++ all do that far far better than something like elixir.

Perhaps in dynamic languages, but doing that in ‘most’ static languages gets you many compiler errors showing you all the places that you need to update. Even Elixir ‘kind of’ helps via dialyzer with that and it’s a dynamic language as well. Compared to only experiencing javascript and ruby and elixir and such in comparison then definitely missing out on the massive amount of static languages out there and all the benefits they give, it is definitely not a uniquely Elm feature by any stretch but is actually fairly common among languages. ^.^

It’s been a big thing in languages over the past 10 years to make errors better. Like the horrors of C++ template errors have been pushing Concepts since easily the mid-2000’s, clang’s awesome errors pushed gcc’s error forward, OCaml has a whole better-errors package that is just awesome, etc… etc…

None of what was listed is Elm specific or even fairly uncommon among static modern languages?

There is one big feature Elm has that most languages don’t, and I’m surprised no one has mentioned it yet… Let me finish reading thread before I mention it in case someone else does. ^.^

ReasonML is OCaml. Bucklescript is just a back-end for OCaml.

The OCaml compiler supports front-end syntax change languages, of which ReasonML is one. ReasonML adds no features on OCaml, just a more javascript’y syntax for those programmers that havn’t learned much about better designed languages (although I like a couple of the syntax changes it made, overall I’m not a fan at all). Bucklescript is just a backend for the OCaml compiler to export Javascript. OCaml has backends for readable-javascript but requires special annotations in code (bucklescript), it supports unreadable javascript but can handle everything (js_of_ocaml), it supports an interpreter (ocamlc), it supports native machine code compilation (ocamlc.opt), there is an older C backend but it’s pretty unused since the native code compilation is better than it now, there is a wasm backend that is mostly done now, etc… etc…

But yeah, ReasonML is not a language, it’s just a syntax plugin for the ocaml compiler, it is still ocaml just with less existing help out there and a javascript’y syntax. ^.^

Both purescript and Haskell are less inferencing than OCaml, they are… interesting in form, OCaml almost looks like a near-parenthesis-less elixir with some slight renamings. ^.^

And yeah, no one mentioned the one big thing about Elm that is actually cool and unique, the fact it uses the exported types to determine and force semver increases. :slight_smile:

Though it’s not hard to make for OCaml and Rust has things popping up for it too, and it may not catch ‘logical’ semver changes, but it is still really useful. :slight_smile:

It would actually be quite easy (comparatively) to make such a library for Elixir to do the same all things considered…

Even if ReasonML and Bucklescript both died (I don’t foresee bucklescript dying though, it makes very readable javascript code, though it still can’t compile all code like js_of_ocaml (jsoo) can), OCaml and jsoo would still continue on. :slight_smile:

Plus you can trivially convert your ReasonML to OCaml (and vice-versa) via the reasonml tool, so it’s not like you are stuck at any point.


That does sound quite alarming… I checked elm/core and there are 26 issues open, of which 1 is labeled as “bug”, few as “problem” and most are requests/discussions. I haven’t looked at the other repos yet, but I’m just wondering — were there any high priority bugs that weren’t fixed during these 18 months? To me it seems that majority of Elm users were doing just fine with 0.18

Note that I’m not super familiar with Elm or the Elm community.

@peerreynders and @OvermindDL1 thank you for your thoughts! If one thing is clear to me, it’s to stop with analysis and just dive into one of these options :slight_smile:

Until then, I’ll continue trying to at least introduce TypeScript at my work. At least to have some typing. Baby steps… :smiley:

Oh there is quite a few bugs! They just aren’t marked as open on the repo because they close those issues as ‘fixed internally’ kind of things. I have quite a sizeable list of just type-related bugs (ignoring a lot of non-typing bugs) somewhere in my email. ^.^;

Yeah typescript is well worth adding! That would be a great introduction for them! :slight_smile:


I’m sure there are bugs, just in like in any software, but I was referring to high priority bugs specifically. For example, I wouldn’t be bothered if the bugs in question are edge cases that would be against the normal practice and with easy workarounds. On the other hand — if there were some fundamental flaws or security issues that weren’t fixed for 18 months, then that would definitely be very concerning…

P.S. I’m not trying to defend Elm, just want to understand why would they abandon maintenance completely for such a long period of time…

I took a quick peek at Elm a few days ago and thought it looked interesting enough to warrant further exploration, but I haven’t actually tried it out yet.

I’m focusing on learning Elixir and Phoenix right now, but perhaps I’ll try to use Elm to develop the front-end of a Phoenix app at some point, if only just for fun and learning.


In any strongly/statically typed language I’ve seen from OCaml to Haskell to Rust such typing errors ARE absolutely high priority if not absolutely Critical, Elm is really really weird that it’s not…

And these are not edge case bugs, these are typing system failures coming from just naming things ways that you would normally name things causing runtime crashes to integers coercing into NaN’s and floats to being able to pass any types, like strings, to a ‘number’ type in certain conditions, and none of it makes sense, I don’t even know how those occur given any HM-based typing system I’ve ever seen… o.O

Because the author likes to retain absolute control, no PR’s of anything more than spelling fixes, not making the code public until the release is actually made, etc… etc… It has all the hallmarks of a proprietary language in the making.

1 Like