Yes, I think this is correct. People committed to using Elm worked around a number of issues because to them it is still a net benefit, but I’ve seen a number of people moving ahead with other platforms because of it or partly because of it. They call it production ready but I would say it is production ready only if your use case is supported and you are happy to not have any fixes (But as mentioned they say this is going to change with 0.19)
Another point is that elm/core is just one part of it. Because elm is a sort of mixed language/framework this changes the dynamic a little bit. For pure language and compiler work I agree that things need to be well designed and I understand if new versions take time. This is also used as a defense for the “long” release that other languages have had long release cycles as well. On the other hand, there hasn’t been a single update to the framework/library side of things either and as @OvermindDL1 mentions, a number of bugs and pull requests have been directly closed because they will refactor/rewrite to 0.19.
It depends. I think Elm is fine but I don’t like uncertainty. There are things I need which are not in Elm which makes it easier for me to use other solutions. But I also prefer to know where things are heading, when releases are coming, so that I can plan resources for it.
To some degree I think developers are like the stock-market. If they are uncertain about a product most will not invest. Some will make a gamble which may or may not pay off. Most of us like the index funds that just slowly keep improving without surprises. Currently I have no idea where Elm is going or what is happening and I am not prepared to gamble.
I don’t know if it was a big deal or not but the wording of the commit message and the large number of additions/removal seems big. They repository added 2k lines of code for the migration. At a glance it hard to see what has changed as a large number of files have been renamed. And there may have been more files added than just to upgrade to 0.19 but it looked big.
I know it is not 1.0 yet so breaking changes are part of the game but if you need to take advantage of any fixes/features in 0.19 you must do the work. And it is going to be more work than just updating a single library to a imaginary 0.18.1 package with only a few bug fixes but still full compatibility.
Very good points… there is definitely a risk here. By this measure ( elm vs purescript vs reason-react | npm trends ) elm still has over 3x the npm downloads as reason-react. That said, for me, the power of the inferred typing for refactoring is too great and worst case scenario if FB/Bloomberg shuts it down you can take all the compiled .bs.js react components and use them as part of your React.js app. Elm is cool but the interop story is much more arduous and the reliance on one BDFL seems riskier long-term.
Actually, you’re right, I have no real grounds for saying that it wasn’t a big deal - I apologise for the way I phrased that. 2k lines does seem like a lot to add, since as far as I’m aware, there haven’t been all that many big changes to the language from a user’s perspective. Unless I’ve missed something, a few bits of syntax have been removed and a few packages have changed, but nothing that would really require massive architectural changes. Unless you are relying on a lot of native code, I guess.
For previous releases, I think the core team provided an upgrade script or tool that could handle some?/all? of the syntax changes automatically. I’m not sure if this is planned for the 0.19 transition too.
I don’t know either It is hard to say because they have renamed, moved and reversioned most libraries I don’t know what is required. It doesn’t help that their spa example probably did a lot of non migration related work in that commit. There will be a blog on that repo on how to upgrade but it still not there.
I think they already have an alpha (or even beta) version of an automatic code upgrade.
The focus on functional purity and safety (no exceptions etc) means that 99% of the time everything built with Elm can rely on very strong foundations.
This results in v good error messages, easy refactoring, v few run time crashes and performance (see latest release).
IMO, immutability is Elixir / Erlang’s biggest plus over functional language eco systems - including Clojure, OCaml / F# etc. Mainly by reducing the amount of side effects and not compromising.
Elm just pushes this to the extreme, it’s more strict than languages like Haskell / PureScript etc.
This is why Elm is special, and will be harder to match in the coming years - it’s fundamentally more functional.
If you are already doing TypeScript then ReasonML is worth a look - just to get a sense of what you are missing out on. TypeScript has an air of a “doing something is better than nothing” ease your conscience type of approach that stops many people from looking for better solutions simply because it’s easier to keep doing what they are already doing.
I see… I haven’t been following Elm for that long, so I’d be interested to see what these issues are about (and how were they handled by the Elm team). I’ll try to do some digging this weekend, but if you have any links to the issues you’ve mentioned, that would be really helpful!
Oh I agree 100%. It’s just that with a team of 10+ people, none of which are into functional programming, I can’t even begin to imagine how I would push for adoption of something like Elm or OCaml. For my personal needs, I have been looking beyond TypeScript for a while now
Elm is an awesome way to get introduced to the world of pure functional programming. It’s how I got into it and I’m quite glad that I put in the time.
Having said that, I don’t consider Elm to be a suitable language for anything beyond small toy projects. As far as I’m concerned, there are too many developer pain points to use for a project in the 10^4 lines of code order of magnitude or greater, and I say that knowing there are multiple companies with Elm codebases of that size. It’s too reminiscent to me of developing in Go.
We are switching over to Elm from ‘sprinkled JQuery’ and some React for a couple of our applications.
Elm has three big advantages over PureScript/Bucklescript:
It is more simpler. Sometimes this simplicity means that you are restricted in how you are able to do things, but it does mean that there’s less of a learning cliff, and there usually really is a single way of doing things.
It is immediately meant to do front-end development. The Elm Architecture (TEA) feels a lot more natural than most effectful systems in other (functional) programming languages.
No back doors. In Elm, there is no way to use native JavaScript underneath (in 0.18 there still were some libraries that did, in 0.19 it is completely impossible). Interopting with JS is possible, but your code will have to check all inputs/outputs from/to JS-land. This means better type-checking and faster running time. In Elm 0.19 there have been many optimizations that have only been possible because Elm knows that no library- or user-code will ever invoke code with side-effects.
Of course there are some disadvantages and warts (as well as things I personally do not like about how Elm is structured), but for us Elm really is the best choice.
I’ve been using Elm to build several small personal projects for the last 2 or 3 years, and using Elixir at work for a year or so, including one experimental app with Phoenix as the backend, serving an Elm frontend bundled with Webpack. For the most part it’s been great. I really like the use of immutable variables in both languages, although the rebinding / shadowing ability in Elixir has bitten us at least once.
Although I have noticed a certain degree of dogmatism and authoritarianism in the Elm leadership, it’s not a huge concern for me. Overall I’m really happy with the helpful compiler messages (compared to other languages in the ML family) and find the “Elm way” of doing things to be a pretty nice way to build reactive programs.
My biggest dislike so far is that there doesn’t seem to be a great way for building a larger app in a modular way (i.e. broken into multiple self-contained pieces that don’t need to know about each other). I started writing an app with several tabs, and wanted each tab to be like a sub-app focusing on its own part of the problem domain, with just a small bit of shared state. In the end I settled upon having “sub-messages” that would be handled by update functions in separate modules. I’ve not looked at the 0.19 changes yet, but a quick check indicates that they haven’t thrown away the ports system for JS interop – I used this just a few weeks back to control some HTML5 audio objects for a countdown timer app and it was reeeeeeally easy (although also frustrating that there was no built-in audio API in Elm).
Working with Elixir has been a pleasure too, but I really do miss good static typing there. It’s so easy to start sending tuples around the app, then adding something to the tuple which then doesn’t match up elsewhere, causing runtime errors. Recently (like… yesterday) I started looking at Ur/web again, having abandoned it due to its rather inaccessible documentation a couple of years ago.
I’m also loving elm personally.
Especially since I used to develop a lightweight wrapper around jquery and followed the frameworks like angularjs/aurelia and ended up having to program in them due to company decisions but never ever ever had the feeling that any of them offered me something, in the contrary… everything was less performant than how I would have written it without it and less readable.
Elm on the contrary, I see the point, it’s well designed, it’s pretty efficient most of the times and offers a nice framework. For now I haven’t seen that much that I can’t do with it (of course I will use ports as well).
But I’m very interested to hear how frontend would work in the other OCaml like options and what they offer in terms of framework for single page apps. Maybe some of the people who don’t like Elm can point us to some skeleton repositories that we can look into to get started? Since Elm is quite well documented as well, I’m afraid that I would have no idea how to get started with something else.
Well if you like the Elm model there is always bucklescript-tea (TEA == The Elm Architecture). But OCaml/ReasonML have first class React support as well (using React’s immutable/functional API).
Ah yes! I spent a week or two trying to learn me some Ur/web, and it is very impressive. You can call a server-side function from the front-end by passing something to the rpc function, which is quite amazing because it automatically figures out how to represent the data being transferred, at compile-time. There are a couple of rough spots that make it quite difficult to get into the language:
Very long compile errors that are difficult to understand. This probably gets easier over time with exposure to the language and programming style, but I wish it was more user-friendly like with Elm.
(apparently) no way to access the filesystem without writing some kind of FFI code with C and/or SML. Believe it or not, when files are uploaded, they are stored as blobs in the database. I really dislike this, and would much rather store files separately to the rest of my data for several reasons.
Again, documentation that isn’t very accessible, replete with intimidating mathematical equations and Greek symbols. That said, there is a series of demo programs with well-written commentary explaining key points in the source code. This has been by far the most useful resource I’ve found, and I’d advise newcomers to the language to start there and walk through the programs sequentially.
Although database access is a core part of the language, there’s no built-in support for migrations, so external tools would need to be used. In fact there isn’t really much tool support, compared to Elm’s package ecosystem.
While its performance for read queries is incredible, it falls down under heavy write loads due to its enforced transactional semantics.
I’d love to see some of the lower hanging fruit fixed (e.g. helpful compiler error messages and killer docs, both something Elm does right), since it would lead to more community involvement, bringing with it better tools and libraries and a healthier ecosystem. That’s one of the real sweet spots languages like Elixir and, more recently, Crystal have hit: powerful and expressive, but easy to learn without being cumbersome to use, so we end up with a really active community. I’m taking a little break from Ur/web to look at Idris out of curiosity… but I’ll probably come back to it very soon to carry on a small side project.
(But as mentioned they say this is going to change with 0.19)
