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 
(Iām still going to check it out at some point!)
Plusā¦
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.
Well, Iām still using Elm and I like it! So thereās at least one 
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 
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 
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 
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.
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.
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.
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
Until then, Iāll continue trying to at least introduce TypeScript at my work. At least to have some typing. Baby stepsā¦
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!
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.
Ā© Copyright Elixir Forum | Terms | Privacy & Cookies
