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.
I don't think RF is against TEA components. But you just don't need to TEA all the things [1] - and to do so introduces a lot of work, and moreover reduces the deep thinking you should be doing about what data structures you need and building the view around it.
But in react is is natural to say "oh I need a spinner, let's make a functional react component for that". And you can always keep some local state in React and avoid the message passing relay-race you'd have in Elm with the same approach. So Elm benefits from a different approach.
> 2. I think the boilerplate is good in making things explicit.
I think Boilerplate is the lack of a more succinct way of expressing your intent. So, boilerplate is never good in making things explicit, it's just the (current) shortest way possible to accurately expose your intent.
For example, in TypeScript, if I delve into making datastructures `algebra-ish`, I always have the boilerplate of defining a `tag` field in my objects, and lengthy switch-constructs to match on the tag field.
It's not good in making things explicit, it's actually just the only way (at the moment).
> - 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.
>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).
It's actually not that easy to write composable components in Elm, and attempting to do this has always been officially discouraged.
> 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.
Yes, you are right! The community - elm users - are wonderful and very nice and helpful! I was speaking about Evan. He doesn't really engage with the community (for example: https://discourse.elm-lang.org/t/elm-shadowing-change-issues... - no response, it's always like that) and we don't know what he is working on and where Elm is going in the future! But don't get me wrong, I know he must be very busy and I understand that, but he could maybe delegate work (he doesn't have to maintain the website, the language, the documentation, code examples, and so all by himself). (I am just trying to be constructive by the way, I don't want my post to be offensive.)
Fair enough. It's taken me a while to understand how he works, and certainly I can see your point. His passion for the project helps the community immensely in many ways and can be spotty in other aspects as a consequence. That's a price I'm willing to pay for using his vision, others may not see it that way though. It's a unique community in that sense for sure.
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.
FWIW, I wrote this without having previous Elm experience—the compiler's error messages are so good that it was mostly trial and error until it worked.
To your point: I think using language primitives for defining views instead of HTML templating is an advantage for Elm because you can write them using only the Elm language itself, without having to learn yet another syntax. Combined with the excellent compiler error messages, it makes writing views easier and less error prone than writing HTML templates.
As others have shown, Elm is actually super good at stuff like this because you can just write resuable pure Elm functions using functional primitives like map and filter.
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.
Well, every language requires you to write serialization code unless you have the rare case where your datastructures line up 1:1 with your serialized structure over the wire. And the 1:1 case is already trivial with Elm. So I don't really understand the complaint.
Frankly, with something like serde in Rust, it's such a pain to deviate from the 1:1 case that you tend to stick to the 1:1 datastructure despite how suboptimal it is, maybe manually transforming it after parse time if you can be bothered. I don't find that to be any superior to Elm's simple combinators.
My experience with Elm's codecs is that there's a small learning curve if the concept is new to you. And then after some real world experience you wonder how it was ever alien at all. I wish I had it in every other language I've worked with.
The complaint is that humans have to write and maintain code that the compiler could be writing. The more trivial, the more annoying it is for a human to do the compiler's work for it. I find 1:1 cases quite common when developing JSON endpoints in the back-end of a thick client.
To my understanding, derived serialization is in conflict with type inference. You can have one or the other but it is very complex and difficult to have both. Maybe one day Elm will get it but it is not a trivial implementation and there are other, more important issues that take precedence.
No, it works fine and inference is completely orthogonal. Haskell and PureScript both have this. You define types and the serialization instances are derived. Elm cannot do this, because it does not even have type classes.
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.
This isn’t a very helpful response I must say. This is the kind of “you’re doing it wrong” sort of reply which has given the Elm community a bad reputation.
If you want to respond, try to have a more empathetic approach to addressing a newer users concerns than “of course it does ... not really ... the opposite ... most definitely not the case”.
If new users cannot understand how to do things correctly in the language, that’s a problem. Note that new users does not mean they are new programmers, simply new to your language or way of doing things.
I just think that those "negative" points are misleading.
It's fine to be new to something and explore it, but don't write negative comments before you get a good grasp of the pros and cons.
> has given the Elm community a bad reputation
The Elm community is actually very welcoming. Not sure where you read about that reputation.
I was also struggling a lot when I started, and the slack channel is extremely helpful.
So you can go there, ask those questions and see if the above are true or not.
Not sure how to address them in a more constructive way.
Stop quoting people and stating that the opposite of what they say is true. You just did it again, after the parent pointed out that doing so is problematic.
You can state your exact same opinion without it coming across as dismissive just by stopping that one thing.
Gave it a whirl online, tried to change WebGL import to Webgl, thinking it wouldn't do anything helpful.
It told me the lib import was prob a typo, with suggestions, and WebGL at the top:
You are trying to import a `Webgl` module:
11| import Webgl
^^^^^
I checked the "dependencies" and "source-directories" listed in your elm.json,
but I cannot find it! Maybe it is a typo for one of these names?
WebGL
Set
Svg
Array
Hint: If it is not a typo, check the "dependencies" and "source-directories" of
your elm.json to make sure all the packages you need are listed there!
Elm already was the gold standard when it comes to helpful error messages and it's amazing to see that they're still working to make it even better. I hope other languages follow suit.
> Elm already was the gold standard when it comes to helpful error messages
I read this all the time about Elm, but did you actually try Elm for a real world project?
I did, and Elm error messages were one of the most painful point of the compiler: they're beautiful but very often completely unrelated to what's actually going wrong. They actually drove me away from the actual errors more than once.
Good error messages can make all the difference. I haven't worked with Elm, but Rust and Vulkan (through validation layers) also have specific, informative errors and warnings like this.
Both those technologies have well-earned reputations for having not-so-shallow learning curves, but that's almost not an issue when the tools always make it clear what has gone wrong.
We (Rust) took a lot of inspiration from Elm here.
One similarity to this post that sticks out:
> Maybe you just try the JavaScript way to see if it works:
Given that the final syntax for async/await was a bit controversial (postfix .await), the compile folks implemented parsing for (at least) the JavaScript way of doing it, and so you get a good error message telling you the correct way:
error: incorrect use of `await`
--> src/lib.rs:2:5
|
2 | await bar()
| ^^^^^^^^^^^ help: `await` is a postfix operation: `bar().await`
This kind of thing can really help polyglots, as well as people new to the language.
I have not personally had the usecase for Rust just yet, but it is the only language I have never heard a negative thing about. That's huge, with how opinionated developers are.
The arguments for the language and general consensus are so strongly positive that without having used it myself I frequently recommend it (I passively follow the language's progress online).
A huge part of it is the developer ergonomics, a large amount of which comes from your compiler error messages.
When I talk to people about the gold standards, Rust and Elm are the examples I give.
Try to write a small program (a basic interpreter or something like that) and i bet you will have some gripes with Rust... I found that it was an extremely slow language to ramp up on.
Same. I have mixed feelings about it. The tooling is great, but I'm not totally convinced the borrow checker is the be-all, end-all of memory management it's sometimes made out to be. Also some of the decisions around syntax are questionable to me, like lack of top-level-inference just feels like a step backward compared to languages which have it. Also while the trait system and macros are really powerful, a lot of times how they are used by libraries seems quite magical, and it takes a lot of digging through documentation and sometimes source to really understand how things work.
Still in spite of that, I think it's an awesome project with a lot of enthusiasm behind it, and I'm happy to see languages exploring new ideas getting so much attention.
The lack of top level inference is a key part in getting great compiler errors: top level inference can be convenient, but it also leads to spooky action at a distance errors.
Interesting. I'm sure you know more about it than I do, but in Swift for example, it seems like this mostly results in an error like "unable to infer the type of X in the current context" which is maybe not the simplest error in the world to figure out, but it's really not too difficult to unwind as compared to say, cryptic C++ template errors.
I suppose you can't have everything, but in my experience top level inference makes code a lot easier to read because it removes a lot of noise and redundant information while largely leaving the "intent" of the code in place.
Yeah I mean, it really depends on the exact type system features and implementation, but that sounds like a different error than the kind I'm talking about. For example, consider this code, imagining Rust had type signature inference:
error[E0308]: mismatched types --> src/main.rs:10:21
|
10 | let s: String = bar();
| ^^^^^ expected struct `std::string::String`, found struct `std::vec::Vec`
|
= note: expected type `std::string::String`
found type `std::vec::Vec<i32>`
You changed foo, but the error points to bar, in main. None of this is related to the code you changed. But in Rust today, you'd get
error[E0308]: mismatched types
--> src/main.rs:2:9
|
1 | fn foo() -> String {
| ------ expected `std::string::String` because of return type
2 | Vec::new()
| ^^^^^^^^^^ expected struct `std::string::String`, found struct `std::vec::Vec`
|
= note: expected type `std::string::String`
found type `std::vec::Vec<_>`
This points right to the issue: you're returning a vec, and not a string, in foo.
There are other issues too; global inference and subtyping have problems. While Rust doesn't have subtyping generally, we do in lifetimes...
Beyond all of that though:
> it removes a lot of noise and redundant information while largely leaving the "intent" of the code in place.
Rust's perspective on this is that the type signature is what communicates your intent. It's like a unit test. You write down what you expect, and then the compiler's job is to check that your code does what you said you were going to do. This seems like philosophically at odds with what you expect, which is fine of course, but is probably where a lot of the divergence comes from.
It really stands out with Elm and Rust and is much appreciated.
A human/e interface to compiler errors is critical to me. It means the difference between the compiler being an ally and the compiler being an enemy (or maybe a teacher who thinks you're just a bad student and is going to give you a bad grade no matter what, not that there's any scar tissue there).
Matters the world to me personally in terms of my enjoyment and flow and represents the kind of computing I want to do.
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
seems I was mistaken, Rust seems fine. I was probably misremembering, as I haven't played much with it. The point about Python and other still stands, though.
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.
As much as I really like Elm (and use it professionally), the speak of making it developer/learner-friendly is humorous considering how the --debug flag was broken for ~ 1 year [1].
fyi compilation speed has had a noticeable improvement as well with this release, but is not mentioned in this blog post.
RE: compilation speed, given that it appeals to an entirely different demographic than the one being reached out to in this blog post I suspect it was not mentioned because it would only be distracting. Nice though!
Mentioning compilation speed needs solid data to back the claim. This would have delayed the release. To my understanding, there is some work being done on a script that would produce this kind of reliable data and a later post will be made to cover this detail.
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.
I've used elm-css-modules-loader[1], although haven't tried it with Webpack 4 yet. Since my CSS is usually small (< 300 lines), I prefer a standalone stylesheet.
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).
Elm Slack is cool, there are my heroes there who create some cool packages and share deep knowledge of Elm (blog etc.)
But Elm's development is really out of focus in the sense of fulfilling, fixing what people using it seriously encounter. I don't want to mention specific things where its solution is "use port".
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.
True that's biggest thing people complaining about, I'm cool with no Typeclass whatever, but to build large app it's going to have crazy boilerplate. I can't stand removing Weboscket module, that made me leave because I don't want Port to be a solution of all things.
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.
I mean yes they don't have an explicit function that does exactly zip anymore, but that's because it's been generalized into (IMO) a much more powerful 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.
I really appreciate the focus on helpful messages in Elm. When working with it I'm recurringly surprised at how the computer seems so considerate for once. Time well spent!
My biggest project, it's about 6k loc. So maybe that's not what you meant by 'big', but many of the others here have listed a lot of closed source apps.
Just looks like it thinks it's printing to terminal due to misconfiguration. Check out what went wrong or find the appropriate ansi --color/--no-color toggle.
Obviously browsers should add color codes support. JS frameworks should make color output optional. But this is hardly sufficient to say the language errors are uninformative. Just a bug with a logically straightforward solution.
I'm in my 30s and have only ever seen someone mention the Elm email client across all technical forums I've been on when commenting on Elm-the-language to suggest that other people might be confused. (Nobody is, btw)
Nightmare on elm street is a horror movie from my childhood, I hate elm trees and the email tool and the language because they all bring horrible memories.
I’m not sure who the intended audience for this post is, but I’ve never known any serious or productive developer who quit learning a language just because they got hung up on a few of the trivial syntax examples in this article.
And on top of that, it's a blog post. Evan gave examples of really helpful error messages.
I don't use elm, as I don't do webdev and I don't agree with Evan's tendancy to minimalism, but I really wish other languages had the "pair programming" aspect of the elm compiler.
In special if you try a NEW lang. Lets say I wanna check elm, I try it a little then BANG! weird errors. I will quit, not matter how cool the lang is.
When learning something new, even if you are experienced (I have used professionally more than 12+ langs now) you "budget" to learn something is low: New syntax? New paradigm? hard to install? Limited tooling? Nothing work? Not stackoverflow explains of that error?
You quit in any step of this chain. I glad ELM designer is smart to fix one of them
BTW: Rust is similar here. It have decent error messages.
The point here is to improve the user/developer experience learning Elm. It's one of the things that make Elm such a nice language to work with. A error message that suggests how you might fix the problem is so useful when you are not familiar with the language or programming in general.
Being able to do frontend development that /just works/ when it compiles is fantastic. I have yet to use Elm for anything serious because I mostly do backend work, but if I need to Elm would be my choice. No more 'undefined is not a function' mysteries or trying to figure out what part of the latest Javascript framework is stopping me.
Elm has the basics of what you need to develop frontend applications today, even though I'm sure there is work to be done yet.
The people who become a serious programmer didn't give up. I think this is a real problem with the industry as a whole. I've known a few people who gave up on programming because they were introduced to it through a language that didn't value their error messages, or that had really bad new programmer failure modes. By "new programmer failure modes" I mean a program that gives no relevant feedback to a new programmer gone wrong.
I like the detailed error messages -- it definitely helps learning the language! But I would also like a 'terse' mode for when I become an expert and want to integrate this into a build system and don't want all that chattiness.
Also perhaps a mode where I could instruct the compiler to fix the error itself (like the closing brackets) and continue the compilation as far as it can and then output the "fixed" code. That might be a dangerous feature, but it could also be a fun feature to auto-gen your code without knowing much of the language :-).
I disagree. Not even a new language, even for libraries/frameworks - if something is unnecessarily confusing/annoying to use, I'm going to take a pass, and I won't recommend it to others. Of course I will put up with some level of obscurity if the benefits are great. It isn't the case often though.
Elm really raises the standards in this area far beyond most languages. This isn't something to be bothered by but rather something to see as an example to be emulated elsewhere.
>Say you are learning Elm and do not know how to import modules yet. Maybe you just try the JavaScript way to see if it works.
Or maybe you read the documentation section "Importing modules" which takes you 5 f*ggin minutes? That's a lot less to ask than "implement very verbose error messages that talk to you like you're a baby".
Well, this kind of RTFM bravado mindset is one of the reasons every compiler has garbage errors and why manpages are more hassle than just googling "how to unzip with tar" and why so many projects can't even be fucked to flesh out a README. ("Just read the tests!")
So, if that's what you want, you already have every other programming language to pick from. Let the rest of us have our fun. I've been programming for 20 years and appreciate Elm's errors every time.
Why should I need to do any more work than read a compiler error when I accidentally write "import Webgl" instead of "import WebGL"?
I'm giving my opinion. Please understand some people think differently than you and that's fine.
>why so many projects can't even be fucked to flesh out a README
Not relevant.
>manpages are more hassle than just googling "how to unzip with tar"
Not relevant.
>Why should I need to do any more work than read a compiler error when I accidentally write "import Webgl" instead of "import WebGL"?
Still not relevant, since that wasn't the example given (correcting typos like this is indeed a very helpful compiler error; gcc does it for like a year or two now).
>RTFM bravado mindset
I really don't think telling people to learn a language instead of typing random things in hope that the compiler corrects them is being a hacker-neckbeard who tells you to rtfm. The example given in TFA is literally: "if you don't know how to import things yet, instead of reading the introduction, googling "elm import", or literally just taking 2 minutes to figure it out, just type what you would do in some other language, and the compiler will gently tell you how to import a module in Elm", or in other words "type random stuff until it works". Should the compiler also correct the user if they write `#import <set.h>`? Or `open Set`? Or `from Set import `? Again, in my opinion* this is neither relevant nor desirable.
> I'm giving my opinion. Please understand some people think differently than you and that's fine.
What does that mean? Should he have NOT responded to your comment? Does that then mean that you should have not responded to his comment? Does that mean I should have not responded to your comment? Does that also mean that you shouldn't have made a comment, since Evan directly expressed his thoughts and opinions in his post? Should we stop communicating at all and become Loopless One-Directional Communication Graphs? Who shall be the original Opinion Holder? Adam or Eve?
Anyway.
> Should the compiler also correct the user if they write `#import <set.h>`? Or `open Set`? Or `from Set import `? Again, in my opinion* this is neither relevant nor desirable.
If it can, why not? Why not tell the user: Hey, you've got `xyz`, but you can only do `zyx` with those literals. Having detailed Errors is not a detriment. I remember my first Segmentation Fault in C. Man, I cried.
Programming languages have users, and caring about the User Experience of a language (i.e. Developer Experience, I supposed) is commonly desirable. There is no downside to a good error message, neither for something as trivial as imports, nor for common things like using the wrong key names in a Record.
I make heavy use of types in TypeScript, but the error messages when something is out of order (ever so slightly) is just so brutal at times, with error messages being 20+ lines long, where only the last line might be relevant. I, for one, welcome our helpful error message overlords.
> I make heavy use of types in TypeScript, but the error messages when something is out of order (ever so slightly) is just so brutal at times, with error messages being 20+ lines long, where only the last line might be relevant. I, for one, welcome our helpful error message overlords.
If you've got examples of cases where we can do better, feel free to file an issue! We want to do better.
Saw that you tweeted an example of error log improvements, which is exactly what I meant with the 20+ lines of error messages with only the last one being relevant.
Now I just need to wait until Typescript 3.7 trickles down to all my dependencies so I can get that goodness. Sigh.
+ 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.