I built a project using Elm last summer. Here is my quick feedback:
+ The language syntax is very nice and refreshing.
+ It's a joy to work with the compiler.
+ If it's compiling, it's working! No runtime exceptions.
+ Static typing!
+ Functional programming!
- The language doesn't have component composition (like in React or Vue) and you end up having huge chunks of spaghetti code (but to be fair, it kind of works because of the compiler).
- It's complicated to implement routing and to build a Single Page Application.
- Only pure functions in Elm, so doing API calls and generating random numbers are unnecessary hard.
- It's a pain to parse JSON.
- There is no variable shadowing, so naming your stuff is harder than it should be.
- Vue embraces HTML, Elm avoids HTML, and it's really a pain to build HTML view in Elm. <div><a href="hello">world</a></div> becomes div [] [ a [ href "hello" ] [ text 'world" ] ]
- There is a lack of leadership and community building in this project. We don't know what's going on and where the project is going. It's like a black box. No roadmap. All issues on Github, all posts on Elm Discourse get no response.
So in the end, Elm is an interesting beast, but I think it's too academical and not really practical for serious projects.
I had the same viewpoint, but something keeps me coming back to Elm for curiosity. I think if NoRedInk can use it for all their client side stuff then it must be capable and all of the advantages outweigh the annoyances enough to stick with it for a commercial setting.
My analogy there is Agile. Years ago no company would do agile and probably because no other company was doing it. Then Thoughtworks etc. started doing it, and slowly the proof that it can work spread around. I think this could happen with Elm.
But like agile I think there is some counter-intuitive ideas, sort of 'go slow to go fast' type of things that you need to get your head around.
I struggled and still struggle but I want to give Elm a fair go. My peeves were:
1. Can't component-ize like React.
2. Lots of 'boilerplate' to wire things up.
3. No promise like API for async, you need to do stuff via pub/sub and ports.
However the counter points seem to be that.
1. You don't need components - design a good model data structure and work out from there. There is a good video talk about this at an Elm conf.
2. By making us us wait and use ports for a lot of things in the meantime (and not just adding everything to the language or letting anyone use vanilla JS in their packages) the modules that you do use are "pure" and are almost guaranteed not to crash. And the API's of Elm are well thought out because there is no rush to fill in all of the web platform.
This sort of thinking sounds like the "100 year language" way of thinking that PG writes about. What sort of language will we be using in 100 years? Hopefully something well thought out, not full of baggage because it was rushed.
> - The language doesn't have component composition (like in React or Vue) and you end up having huge chunks of spaghetti code (but to be fair, it kind of works because of the compiler).
Um... yea it does. Elm makes functional composition very easy which which means it's very easy to compose "components" (which are just functions anyway).
> - Only pure functions in Elm, so doing API calls and generating random numbers are unnecessary hard.
I would say that Elm makes doing API calls and generating random #s appropriately hard. Elm strives to corral side effects into one part of the Elm architecture: "commands". By doing this, you're keeping all code that contains side effects at the fringes of the walled garden you're growing.
I think this explicitness/discipline is needed in more codebases.
> - It's complicated to implement routing and to build a Single Page Application.
I agree, it's no Ember, which comes with all the bells and whistles of a full router system, including page transitions, transition errors, data fetching, etc. Richard Feldman has an elm SPA example on github that shows how to create routes, pages, etc. The official Elm Guide also has sections on routing, etc.
> So in the end, Elm is an interesting beast, but I think it's too academical and not really practical for serious projects.
> Vue embraces HTML, Elm avoids HTML, and it's really a pain to build HTML view in Elm. <div><a href="hello">world</a></div> becomes div [] [ a [ href "hello" ] [ text 'world" ] ]
IMO, this is one of Elm's biggest strengths. The Elm HTML syntax is a million times easier to reason about and build hierarchies in, than HTML. The syntax is cleaner and easier to read.
(For the uninitiated - each HTML tag in Elm is a function that takes two arguments - a list of attributes, and a list of functions that return HTML.)
> There is a lack of leadership and community building in this project. ... All issues on Github, all posts on Elm Discourse get no response.
This is completely the opposite in my experience. There is a massively strong hierarchy of leadership, core development and active users. All willing to help at all times. There are quirks, sure - but it is by far the most accepting language community I've been a part of. The Discourse has been a fountain of information: have never had an unanswered query before, and don't see many of them around at all.
I don’t know about Elm, but regarding your point on evading html I actually see it as a pro rather than a con. If it’s the same as hiccup syntax in Clojure, it’s great decision. You build your Dom out of primitives that the language is designed to work with, that’s nice.
HAML and Pug/Jade got popular precisely because HTML/XML is harder to read and easy to make mistakes with all the closing delimiters you need. Making HTML a function with two arguments for virtual DOM is simpler than needing to make an XML parser with special rules ala JSX where people constantly get hung up on className, etc., which compiles to this same binary functions you use in Elm is API.
Pure functions are definitely a selling point. Random number generation needs to be in an isolated part of your app unless it's a toy. Because it deals with IO much like reading from disk, it should have a "hard"-ness to it.
What use is a road map that has to be abandoned? What company does even do road maps? Code talks. The rest is just marketing.
And issues: at least they are known and logged, and people discuss work-arounds, that's something.
Only pure functions: yeah, that's the point of a functional language, isn't it?
Variable shadowing: many languages don't have this, IMO it's a feature. You can always simply prefix local variables with "l_" or "a_".
Pain to build HTML in Elm? Don't get this. It looks slightly different, that's all. As soon as you start adding your templating code, it gets messy when you use HTML.
Yes but it gives you a nice guarantee that you will get a (handled) error at parse time, every time. In JS etc. you may never notice until you maybe render that one prop 4 levels deep under a certain UI combination and its a demo for your client.
The problem is it lacks these advanced features for users that already know advanced FP, AND it has features that are too advanced for people that are beginners in pure FP. Elm suffers from trying to please everyone but pleasing no one in the end.
I hate using ^ to indicate an offending position on a line. For those unfamiliar, the idea is that you display two lines, the erroneous one, and one full of spaces, with a single ^ in it, where the ^ is directly underneath the offending character. This is bad for accessibility and screen readers. They read that the ^ is here, but actually finding out what the wrong character is is problematic. Python does this, I think Rust too, and now Elm. Just provide a column number next to the line number, just like Golang does. Any decent editor will let me check what column I'm on. The ^ can, of course, be kept for the rest, but the column number would be a welcome addition.
I can’t speak for the others, but at least in Rust the column number is at the end of the first line of the error, in format file.rs:line:column, eg main.rs:5:10
You can get these infos from the json the compiler provides you on errors, that's also what all editors will use to show you errors, so they are aware where the error acually is.
I remember meeting Evan back in 2013 when we both rented rooms in the same apartment. I didn’t see him much but the first time he introduced himself, I got to see an early version of the Mario demo.
I can still remember how I didn’t understand a thing ( was just starting my internship) but still knew that he would achieve great things with Elm.
So happy to see him succeed and being able build such an amazing community just by being himself.
Finally, I love how his personality has become a part of the language, most obvious when reading error messages.
I’ve been using Elm for about a year now. It’s my go to for most UI work these days. However, my main concerns have been around:
1. How community contribution is handled. I’ve been following the compiler repo for a year now, and the number of bug reports (and PRs) that remain open is concerning. I get it - they want to move slow and be deliberate in the way it is developed. But fixing well known compiler bugs shouldn’t take a year. Makes it harder to sell to dev teams.
2. Using private packages. I know there have been workarounds (including multiple src directories tracked via git), but they feel hackish.
I’ll continue using Elm for personal projects, but it is still a hard sell.
We here at Pacific Health Dynamics, Sydney, Down Under want to give a big thanks to Evan and the core team for all your hard, free, work!
We've recently hit 100k loc for our main frontend written all in Elm. The journey from inception 2.5 yrs ago has been amazing and now we're in full production mode, reaping the rewards of purity and the type system.
I think Elm too much underestimates people who learn a programming language.
I really like the Browser module recently.., it enables people to build more things easier, that solves serious problems people trying to use Elm seriously.
I am not sure how Elm evaluates feedback from language users. Elm is too much focus on new comers, make it so new people are excited about it first week, and then get stuck on things they want to actually build, and move on.
As someone who's a recent convert to the language, I have started making several webapps with Elm lately. The biggest thing the language lacks right now IMO is solid tutorials for some concepts. I was able to make my way through but due to the young age in the language tutorials are sparse and widely varied in their effectiveness. In terms of learning the language, the error messages were a godsend. Now that I am more comfortable with the language overall (which only took a few weeks of intermittent learning), I have joined the Elm slack channel.
I can say now that the Elm community is VERY responsive to current devs, and Elm's development is not just focused on new people, but that is where the blog posts and updates focus because, frankly, it's a new concept that Elm is focusing on that many languages do not currently, so it bears mentioning and makes for better updates than normal esoteric patch notes would (which any power user CAN still find).
I had similar experience. I get the core syntax of elm, but where I run into issues is how to USE things like the browser module to do routing. That isn't a syntax problem but a larger structural one.
Did you read the survivorship bias portion of the post? Since it is making points in support of the direction taken here and you didn't respond to them I assume not, but in particular it gives an interesting exasmple of how Elm evaluates feedback from language users (it collects data on the error messages they get automatically using elm/error-message-catalog).
I would love to use elm. For me, it needs more in the standard library, but this is the language that has an unzip function and removed the zip function.
We used Elm for our web client and loved it. None of us in our company are "web people" -- we're low-level C++/CUDA folks (and Erlang for network code) -- but we needed to have a public facing web interface.
Elm worked great, and we had no problem having several developers contribute to the same project without stepping on each other, with everyone able to read each other's code.
It's been 100% stable, predictable, and reliable. And, yes, we're calling JavaScript via ports. Works well.
[+] [-] sunseb|6 years ago|reply
+ The language syntax is very nice and refreshing.
+ It's a joy to work with the compiler.
+ If it's compiling, it's working! No runtime exceptions.
+ Static typing!
+ Functional programming!
- The language doesn't have component composition (like in React or Vue) and you end up having huge chunks of spaghetti code (but to be fair, it kind of works because of the compiler).
- It's complicated to implement routing and to build a Single Page Application.
- Only pure functions in Elm, so doing API calls and generating random numbers are unnecessary hard.
- It's a pain to parse JSON.
- There is no variable shadowing, so naming your stuff is harder than it should be.
- Vue embraces HTML, Elm avoids HTML, and it's really a pain to build HTML view in Elm. <div><a href="hello">world</a></div> becomes div [] [ a [ href "hello" ] [ text 'world" ] ]
- There is a lack of leadership and community building in this project. We don't know what's going on and where the project is going. It's like a black box. No roadmap. All issues on Github, all posts on Elm Discourse get no response.
So in the end, Elm is an interesting beast, but I think it's too academical and not really practical for serious projects.
[+] [-] quickthrower2|6 years ago|reply
My analogy there is Agile. Years ago no company would do agile and probably because no other company was doing it. Then Thoughtworks etc. started doing it, and slowly the proof that it can work spread around. I think this could happen with Elm.
But like agile I think there is some counter-intuitive ideas, sort of 'go slow to go fast' type of things that you need to get your head around.
I struggled and still struggle but I want to give Elm a fair go. My peeves were:
1. Can't component-ize like React.
2. Lots of 'boilerplate' to wire things up.
3. No promise like API for async, you need to do stuff via pub/sub and ports.
However the counter points seem to be that.
1. You don't need components - design a good model data structure and work out from there. There is a good video talk about this at an Elm conf.
2. By making us us wait and use ports for a lot of things in the meantime (and not just adding everything to the language or letting anyone use vanilla JS in their packages) the modules that you do use are "pure" and are almost guaranteed not to crash. And the API's of Elm are well thought out because there is no rush to fill in all of the web platform.
This sort of thinking sounds like the "100 year language" way of thinking that PG writes about. What sort of language will we be using in 100 years? Hopefully something well thought out, not full of baggage because it was rushed.
[+] [-] KurtMueller|6 years ago|reply
Um... yea it does. Elm makes functional composition very easy which which means it's very easy to compose "components" (which are just functions anyway).
> - Only pure functions in Elm, so doing API calls and generating random numbers are unnecessary hard.
I would say that Elm makes doing API calls and generating random #s appropriately hard. Elm strives to corral side effects into one part of the Elm architecture: "commands". By doing this, you're keeping all code that contains side effects at the fringes of the walled garden you're growing.
I think this explicitness/discipline is needed in more codebases.
> - It's complicated to implement routing and to build a Single Page Application.
I agree, it's no Ember, which comes with all the bells and whistles of a full router system, including page transitions, transition errors, data fetching, etc. Richard Feldman has an elm SPA example on github that shows how to create routes, pages, etc. The official Elm Guide also has sections on routing, etc.
> So in the end, Elm is an interesting beast, but I think it's too academical and not really practical for serious projects.
Too "academical"? Tell it to these devs: https://blogg.bekk.no/using-elm-at-vy-e028b11179eb.
[+] [-] eckza|6 years ago|reply
IMO, this is one of Elm's biggest strengths. The Elm HTML syntax is a million times easier to reason about and build hierarchies in, than HTML. The syntax is cleaner and easier to read.
(For the uninitiated - each HTML tag in Elm is a function that takes two arguments - a list of attributes, and a list of functions that return HTML.)
[+] [-] Libbum|6 years ago|reply
This is completely the opposite in my experience. There is a massively strong hierarchy of leadership, core development and active users. All willing to help at all times. There are quirks, sure - but it is by far the most accepting language community I've been a part of. The Discourse has been a fountain of information: have never had an unanswered query before, and don't see many of them around at all.
[+] [-] keymone|6 years ago|reply
[+] [-] toastal|6 years ago|reply
Pure functions are definitely a selling point. Random number generation needs to be in an isolated part of your app unless it's a toy. Because it deals with IO much like reading from disk, it should have a "hard"-ness to it.
[+] [-] berenddeboer|6 years ago|reply
And issues: at least they are known and logged, and people discuss work-arounds, that's something.
Only pure functions: yeah, that's the point of a functional language, isn't it?
Variable shadowing: many languages don't have this, IMO it's a feature. You can always simply prefix local variables with "l_" or "a_".
Pain to build HTML in Elm? Don't get this. It looks slightly different, that's all. As soon as you start adding your templating code, it gets messy when you use HTML.
[+] [-] the_gipsy|6 years ago|reply
Yes but it gives you a nice guarantee that you will get a (handled) error at parse time, every time. In JS etc. you may never notice until you maybe render that one prop 4 levels deep under a certain UI combination and its a demo for your client.
[+] [-] hota_mazi|6 years ago|reply
That's a very surprising oversight from a language that claims to be functional.
[+] [-] proc0|6 years ago|reply
The problem is it lacks these advanced features for users that already know advanced FP, AND it has features that are too advanced for people that are beginners in pure FP. Elm suffers from trying to please everyone but pleasing no one in the end.
[+] [-] antouank|6 years ago|reply
Of course it does. Exactly like React.
> It's complicated to implement routing and to build a Single Page Application.
not really. It's part of the core libraries in 0.19. Probably simpler than the "react-router" alternative I suppose.
> It's a pain to parse JSON
Probably for a beginner. But once you learn it once, it's trivial to handle most JSON cases.
> Elm avoids HTML
The opposite, the libraries are almost 1-to-1 mapping to HTML elements, so it's as close as it gets.
> I think it's too academical and not really practical for serious projects.
Most definitely not the case.
[+] [-] miki123211|6 years ago|reply
[+] [-] DougBTX|6 years ago|reply
There are a few example errors here: https://github.com/rust-lang/rust/issues/36611
Are the annotated code snippets after the first line useless with screen readers? I wonder if there’s a flag to hide just the snippets.
[+] [-] razze|6 years ago|reply
[+] [-] reimertz|6 years ago|reply
I can still remember how I didn’t understand a thing ( was just starting my internship) but still knew that he would achieve great things with Elm.
So happy to see him succeed and being able build such an amazing community just by being himself.
Finally, I love how his personality has become a part of the language, most obvious when reading error messages.
[+] [-] jweir|6 years ago|reply
The one problem, for us, is when there is an Elm project the developers _not_ working on it are jealous of the developers who are.
It is fun to work with.
I think it because the compiler is freeing your brain from trivial issues and allowing the brain to focus more on creative problem solving.
[+] [-] Karupan|6 years ago|reply
1. How community contribution is handled. I’ve been following the compiler repo for a year now, and the number of bug reports (and PRs) that remain open is concerning. I get it - they want to move slow and be deliberate in the way it is developed. But fixing well known compiler bugs shouldn’t take a year. Makes it harder to sell to dev teams.
2. Using private packages. I know there have been workarounds (including multiple src directories tracked via git), but they feel hackish.
I’ll continue using Elm for personal projects, but it is still a hard sell.
[+] [-] G4BB3R|6 years ago|reply
[+] [-] mordrax|6 years ago|reply
We've recently hit 100k loc for our main frontend written all in Elm. The journey from inception 2.5 yrs ago has been amazing and now we're in full production mode, reaping the rewards of purity and the type system.
[+] [-] mostlysimilar|6 years ago|reply
The compiler is so friendly. It feels like Evan Czaplicki is talking to me directly. :)
[+] [-] gregwebs|6 years ago|reply
[1] https://elm-lang.org/news/small-assets-without-the-headache
[+] [-] Existenceblinks|6 years ago|reply
I really like the Browser module recently.., it enables people to build more things easier, that solves serious problems people trying to use Elm seriously.
I am not sure how Elm evaluates feedback from language users. Elm is too much focus on new comers, make it so new people are excited about it first week, and then get stuck on things they want to actually build, and move on.
[+] [-] bussierem|6 years ago|reply
I can say now that the Elm community is VERY responsive to current devs, and Elm's development is not just focused on new people, but that is where the blog posts and updates focus because, frankly, it's a new concept that Elm is focusing on that many languages do not currently, so it bears mentioning and makes for better updates than normal esoteric patch notes would (which any power user CAN still find).
[+] [-] justinsaccount|6 years ago|reply
[+] [-] savanaly|6 years ago|reply
[+] [-] wjsetzer|6 years ago|reply
[+] [-] protomikron|6 years ago|reply
I just have to figure out what's the best way to wrap JS libraries, but I am sure there is a way.
[+] [-] paulsmal|6 years ago|reply
[+] [-] MichaelGlass|6 years ago|reply
[+] [-] fortran77|6 years ago|reply
Elm worked great, and we had no problem having several developers contribute to the same project without stepping on each other, with everyone able to read each other's code.
It's been 100% stable, predictable, and reliable. And, yes, we're calling JavaScript via ports. Works well.
[+] [-] MohitKumar2020|6 years ago|reply
[deleted]