11 ms·

Putting Down Elm

222 points by athaeryn 10y ago

spuz 10y ago
This kind of comment about Elm is quite hard to understand without context. Have you ever used a typed language before? Have you ever used a pure language before? Is there something special about Elm that gives you this kind of benefit, or do other languages do the same thing?
- vittore 10y ago
  Exactly what I wanted to ask. Can we mere developers have some context to it?
  - seanjh 10y ago
    Haven't used Elm myself, but I assume this argument is based in large part on the strength of the Elm compiler error messages. For example: https://twitter.com/ID_AA_Carmack/status/735197548034412546 https://twitter.com/ID_AA_Carmack/status/735197548034412546
    - Semiapies 10y ago
      That's kind of amazing.
      - IanCal 10y ago
        Here are some more examples, though are generally more basic errors: http://elm-lang.org/blog/compilers-as-assistants http://elm-lang.org/blog/compilers-as-assistants Overall, I really like the approach of making error messages an important feature. We see them so often that improving them makes the developer experience much better, but I can imagine they're a less 'sexy' task to work on and probably much harder to get right than you'd expect.
- athaeryn 10y ago
  I've used typed languages, and pure ones, but what I've found to be really special about Elm is that the compiler is super helpful. This also makes learning the language really enjoyable, as you've got someone helping you along. :)
- Tehnix 10y ago
  Without having used Elm that much myself: One of its features is its very user friendly error messages. I imagine the author is comparing with more dynamically typed languages, where when you leave your work in the middle of something, there's usually a bit of digging when reopening it and continuing work, which he contrasts with Elm, where the compiler is quite excellent at reporting your unfinished work (in the form of helpful type errors), allowing you to quickly grasp at what point in your program you were at.
- agentultra 10y ago
  Not the author but I've had similar experiences. I haven't used Haskell or OCaml in my day job (though I would like to if given the opportunity). I have written some trivial and slightly serious programs in both of these languages. I've even worked up a few small programs in Agda. Elm, IMHO, is in a class of its own. There's a strong focus in the design of the language to be usable and friendly to the developer. The focus on structural typing, the error messages, and the tooling all go a long way to bring the developer from beginner to expert with as little friction as possible. In contrast I find this is the biggest hurdle for Haskell and OCaml. It's simple enough in either language to get started but there's a steep learning curve to becoming productive and the tooling, documentation, and even the design of the prelude libraries are the largest stumbling blocks for transitioning from an intermediate developer to an advanced one. update: grammar
- orblivion 10y ago
  Haskell does the same thing. EDIT: I didn't mean to say that Haskell is as easy, or that the error messages are as good. I just mean that the error messages can give you a nice reminder of what you were working on, which I believe was the point of this post.
  - baldfat 10y ago
    Really? Having dipped my toes in both I certainly felt like the error messages of the compiler to be very different. I could be way off.
  - skybrian 10y ago
    Haskell had poor error messages last I tried it. Have they improved?
    - orblivion 10y ago
      I didn't think that ease of understanding was necessarily the point. My point was that once you do understand them, it sort of tells you what to do next. That said, in a recent HN post somebody said that the latest version of GHC has better error messages, which I agree would be welcome, but I haven't tried it.
    - danpalmer 10y ago
      Haskell has... precise... error messages. As I learn more about it, the errors are become more useful, and driving my development in a similar way to with Elm, however with Elm the learning curve is far shallower and the compiler helps you up it, whereas with Haskell I'm always just googling types to figure out what the compiler is trying to tell me.
      - thinkpad20 10y ago
        Many of the error messages become clearer with experience, but this is mostly due to developing an intuition for what is actually wrong with your code based on the error message you see, not due to the helpfulness of the error message. Often the actual source of the error is in a different place than what is reported. Consider what happens if you mean to concatenate two strings but forget to put `++` in there: Prelude> "foo" "bar" <interactive>:3:1: Couldn't match expected type ‘[Char] -> t’ with actual type ‘[Char]’ Relevant bindings include it :: t (bound at <interactive>:3:1) The function ‘"foo"’ is applied to one argument, but its type ‘[Char]’ has none In the expression: "foo" "bar" In an equation for ‘it’: it = "foo" "bar" Yikes. Even worse, consider a similar situation with numbers: Prelude> 1 2 <interactive>:2:1: Non type-variable argument in the constraint: Num (a -> t) (Use FlexibleContexts to permit this) When checking that ‘it’ has the inferred type it :: forall a t. (Num a, Num (a -> t)) => t Also the parser errors in Haskell are terrible. That the community has so long put up with "parse error (possibly incorrect indentation or mismatched brackets)" is a marvel to me, and is one of the most irritating errors to fix because of the (at least apparent) simplicity of improving it.
- masklinn 10y ago
  > Is there something special about Elm that gives you this kind of benefit Evan cares about compiler messages, and as a result Elm's compiler errors are the most friendly, readable, helpful and actionable messages I know of, even compared with projects with good error messages like Clang or Rust. Most other typed functional languages don't come even remotely close, best case scenario is they're fairly complete once you've learned to decrypt them, Elm's compiler error messages have almost no learning curve. Though it may help that Elm is wilfully limited abstraction-wise.
- draw_down 10y ago
  It's just "Elm is good and other languages are bad/not as good". I try to be live-and-let-live about such things.
kemiller 10y ago
This has always been my experience with TDD, at least if you always leave yourself a failing test when you go. A lot more labor-intensive, since you are essentially writing the "compiler" as you go, but a similar effect.
- tlrobinson 10y ago
  I think "gradual typing" like Flow might be a nice middle-ground. You're still free to quickly sketch out ideas without worrying about type checking, but you can solidify things by just adding /* @flow */ to the top of a file and fixing the errors. I haven't actually tried Elm though, so maybe a "middle-ground" isn't necessary.
  - shimon 10y ago
    This is the promise of type inference. Languages like Elm that do a good job inferring types are able to play out potentially invalid implications of how your code uses values without requiring you to separately specify all your types in great detail. You'll spend some time just addressing edge cases as "safe to ignore" but it's a lot lower than explicit typing while delivering many of its benefits.
    - tlrobinson 10y ago
      Flow actually does type inference as well.
    - skybrian 10y ago
      Type inference usually makes it harder for a compiler to provide good error messages though. Elm has gone the extra mile on this.
  - pka 10y ago
    This will sound counterintuitive to dynamic language people, but prototyping is actually much easier with types. I often find myself rewriting 50 to 75% of the codebase in the early stages of prototyping, and without types I'd be much less willing to do that, settling for a less than ideal design. This design will then be the base of a potentially large project, which amplifies early mistakes even more.
shrugger 10y ago
What does this mean? There is almost no detail in this other than "Wow Elm is great and the compiler gives persistent, detailed messages" which I think most people interested in Elm already knew.
- Tehnix 10y ago
  I guess the only new addition is that a side-effect of the very helpful errors is that it's easy to eventually come back to your work later on. There's also a lot less state to keep in your head, as it's usually a lot more transparent.
- wanderer2323 10y ago
  It makes other people (like me) interested in Elm
kriro 10y ago
The title is unfortunate. At first I though...wait why are they discontinuing Elm, what did I miss. I've never written anything in Elm but that short post makes me want to try it. Sounds like a pretty great feature of a language to have easy to follow error messages you can readily pick up. This also made me chuckle """I thought Elm was a pure, functional language, but this is one hell of a side effect."""
- actsasbuffoon 10y ago
  The error messages in Elm really are outstanding. I've never used a language that has such clear, concise, and human-friendly error messages. It's a high water mark, and I hope other programming languages are inspired to try to equal what Elm has accomplished.
- agumonkey 10y ago
  I literally had to read it 5 times before realizing it's not a dismissal of Elm.
therealmarv 10y ago
ok nice. We know that. I'm personally touching Elm only after they have something like ComponentDidMount from React or something which is better implementend than "wait 50msec and do something like set focus" on their (virtual) DOM rendering is solved: https://github.com/evancz/elm-todomvc/blob/8be8914582870d59989ce518e6c7d38f8081faaf/index.html#L18-L25 https://github.com/evancz/elm-todomvc/blob/8be8914582870d599...
- kylecordes 10y ago
  I'm not sure this is a fair criticism. The nice thing about this tiny chunk of code is that there is only one aspect of this example program that needs to manipulate the already instantiated DOM, and that tiny chunk is explicitly brought up to the top level and separated and connected back to the program via the port mechanism. It would certainly be worse if this magic happen behind the scenes. Of course it could be better, and that's probably what you are getting at. Ideally the machinery provided for building web applications would be more aware of the nature of web applications and have something in the box (still explicit and obvious, but in the box) to do something like setting focus.
  - Hupriene 10y ago
    It's absolutely a fair criticism. The real DOM is stateful, elm's virtual DOM is not, and elm doesn't provide any tools to manipulate the state of the real DOM. This impedance mismatch is bound to cause problems any time you are dealing with the stateful aspects of the DOM. And solutions like the one linked to by GP are error prone and fragile.
- maxthegeek1 10y ago
  Elm gives you the ability to hook into requestAnimationFrame, which allows you to execute some native js through a port when a piece of html first renders.
- ccapndave 10y ago
  This is certainly annoying at the moment (although there are workable hacky solutions). However it's a well known issue and there is movement at https://github.com/elm-lang/html/issues/19 https://github.com/elm-lang/html/issues/19 so hopefully it will be addressed in the near future.
tacos 10y ago
This is the perfect example of the content-free HN posts that are topping the charts lately. It contains not a single example of a "helpful error message." Nor a single line of code from the language in question. Just a 173 word free-verse poem with some feel-good handwaving. If this were a post about soap (the salt, not the protocol) we'd downvote the post as obvious content-free shilling. But because it's some obscure language that doesn't even make the top 100 TIOBE language list, here we are, upvoting someone we've never heard of, celebrating his opinion of awesome compiler error messages that none of us has ever seen, for a language that nobody uses. http://www.tiobe.com/tiobe_index http://www.tiobe.com/tiobe_index
- pka 10y ago
  In the time it took you to write your content-free comment, you could've googled Elm and seen the error messages yourself.
  - mdm_ 10y ago
    Great, I look forward to future HN posts such as "Elm is really super. The rest of this article is left as an exercise for the reader."
- tvon 10y ago
  I think this is a case where the topic is something that enough people want to discuss so the post generates discussion regardless of the content. I agree with the basic gist of your comment, there isn't much content here to discuss (no offense to the author, it doesn't seem like it was meant for a site like HN). Though I think you might be over-reacting a bit with the tone of your comment.
programLyrique 10y ago
This blog post seems to be more explanatory about the error messages of Elm: http://elm-lang.org/blog/compiler-errors-for-humans http://elm-lang.org/blog/compiler-errors-for-humans
vinceguidry 10y ago
You should always let something else 'drive' your coding. Lots of people like tests. I personally am not a huge fan of TDD, though it's better than a lot of alternatives. Essentially, you set a visible goal. Passing test, compiling program, running command, visible widget on a browser. Run the test / command / browser URL and watch it fail. Let the error message you get determine your next step. It makes a good debugging workflow too. The first step is to get a reproduction. Then you need to set up an environment where you can repeatedly and idempotently reproduce the bug at will. Then all you have to do is keep trying and learning things about the system until you know enough to devise a fix. Here you can manipulate the command itself to exercise less of the system, giving you a clearer idea of where the bug is. Whereas if you're building a new feature, you want to keep the command static until you see what you want to see. There's nothing magic about programming languages or paradigms that allows you to do this more easily. It's just how well you know your system. Some domains are trickier. You need special tools and expertise to reproduce network errors, and God help you if your stack isn't memory safe.
Kip9000 10y ago
Elm is a great language for web. It's evolving but there are some bits that need some rework/improvement/rethought like the canvas performance and managing random number generation. This is difficult with purely functional architecture. But there are a quite a lot of good thought gone into making the whole functional programming user friendly and a pleasant experience. Kudos to the creators/maintainers
md224 10y ago
I feel like something clicked for me once I realized that all functions in Elm are curried by default. Cool feature.
deleted 10y ago
[deleted]
mrcactu5 10y ago
in my experience, when I am stuck figuring out types, I just let the compiler do it. As the error messages are so well-formed, it tells me exactly which lines are inconsistent and how to put the types back together. most compilers tell you there's a problem but none outline how to fix it the way Elm does
gjolund 10y ago
Elm has the best error messages of any language I have ever used. I have dreams about it one day replacing JS as the front end language of choice.
andrewvijay 10y ago
Fell into the bait! Clicked and disappointed at a different content than expected
hawkice 10y ago
To me, the most promising thing about elm is how much improvement it has seen. The last minor version was a huge leap forward for building real things AND for beginners. The makers of elm (seems to mostly be Evan Czaplicki) think about things the same way I do, except they are thinking about it more than I do and more carefully. Whether it's elm or anything else, I'm glad the tool-explosion has let more people use tools they vibe with. Hopefully it will help more random people (like me) do more cool stuff.

222 points by athaeryn 10y ago

spuz 10y ago

This kind of comment about Elm is quite hard to understand without context. Have you ever used a typed language before? Have you ever used a pure language before? Is there something special about Elm that gives you this kind of benefit, or do other languages do the same thing?

vittore 10y ago
Exactly what I wanted to ask. Can we mere developers have some context to it?
- seanjh 10y ago
  Haven't used Elm myself, but I assume this argument is based in large part on the strength of the Elm compiler error messages. For example: https://twitter.com/ID_AA_Carmack/status/735197548034412546 https://twitter.com/ID_AA_Carmack/status/735197548034412546
  - Semiapies 10y ago
    That's kind of amazing.
    - IanCal 10y ago
      Here are some more examples, though are generally more basic errors: http://elm-lang.org/blog/compilers-as-assistants http://elm-lang.org/blog/compilers-as-assistants Overall, I really like the approach of making error messages an important feature. We see them so often that improving them makes the developer experience much better, but I can imagine they're a less 'sexy' task to work on and probably much harder to get right than you'd expect.
athaeryn 10y ago
I've used typed languages, and pure ones, but what I've found to be really special about Elm is that the compiler is super helpful. This also makes learning the language really enjoyable, as you've got someone helping you along. :)
Tehnix 10y ago
Without having used Elm that much myself: One of its features is its very user friendly error messages. I imagine the author is comparing with more dynamically typed languages, where when you leave your work in the middle of something, there's usually a bit of digging when reopening it and continuing work, which he contrasts with Elm, where the compiler is quite excellent at reporting your unfinished work (in the form of helpful type errors), allowing you to quickly grasp at what point in your program you were at.
agentultra 10y ago
Not the author but I've had similar experiences. I haven't used Haskell or OCaml in my day job (though I would like to if given the opportunity). I have written some trivial and slightly serious programs in both of these languages. I've even worked up a few small programs in Agda. Elm, IMHO, is in a class of its own. There's a strong focus in the design of the language to be usable and friendly to the developer. The focus on structural typing, the error messages, and the tooling all go a long way to bring the developer from beginner to expert with as little friction as possible. In contrast I find this is the biggest hurdle for Haskell and OCaml. It's simple enough in either language to get started but there's a steep learning curve to becoming productive and the tooling, documentation, and even the design of the prelude libraries are the largest stumbling blocks for transitioning from an intermediate developer to an advanced one. update: grammar
orblivion 10y ago
Haskell does the same thing. EDIT: I didn't mean to say that Haskell is as easy, or that the error messages are as good. I just mean that the error messages can give you a nice reminder of what you were working on, which I believe was the point of this post.
- baldfat 10y ago
  Really? Having dipped my toes in both I certainly felt like the error messages of the compiler to be very different. I could be way off.
- skybrian 10y ago
  Haskell had poor error messages last I tried it. Have they improved?
  - orblivion 10y ago
    I didn't think that ease of understanding was necessarily the point. My point was that once you do understand them, it sort of tells you what to do next. That said, in a recent HN post somebody said that the latest version of GHC has better error messages, which I agree would be welcome, but I haven't tried it.
  - danpalmer 10y ago
    Haskell has... precise... error messages. As I learn more about it, the errors are become more useful, and driving my development in a similar way to with Elm, however with Elm the learning curve is far shallower and the compiler helps you up it, whereas with Haskell I'm always just googling types to figure out what the compiler is trying to tell me.
    - thinkpad20 10y ago
      Many of the error messages become clearer with experience, but this is mostly due to developing an intuition for what is actually wrong with your code based on the error message you see, not due to the helpfulness of the error message. Often the actual source of the error is in a different place than what is reported. Consider what happens if you mean to concatenate two strings but forget to put `++` in there: Prelude> "foo" "bar" <interactive>:3:1: Couldn't match expected type ‘[Char] -> t’ with actual type ‘[Char]’ Relevant bindings include it :: t (bound at <interactive>:3:1) The function ‘"foo"’ is applied to one argument, but its type ‘[Char]’ has none In the expression: "foo" "bar" In an equation for ‘it’: it = "foo" "bar" Yikes. Even worse, consider a similar situation with numbers: Prelude> 1 2 <interactive>:2:1: Non type-variable argument in the constraint: Num (a -> t) (Use FlexibleContexts to permit this) When checking that ‘it’ has the inferred type it :: forall a t. (Num a, Num (a -> t)) => t Also the parser errors in Haskell are terrible. That the community has so long put up with "parse error (possibly incorrect indentation or mismatched brackets)" is a marvel to me, and is one of the most irritating errors to fix because of the (at least apparent) simplicity of improving it.
masklinn 10y ago
> Is there something special about Elm that gives you this kind of benefit Evan cares about compiler messages, and as a result Elm's compiler errors are the most friendly, readable, helpful and actionable messages I know of, even compared with projects with good error messages like Clang or Rust. Most other typed functional languages don't come even remotely close, best case scenario is they're fairly complete once you've learned to decrypt them, Elm's compiler error messages have almost no learning curve. Though it may help that Elm is wilfully limited abstraction-wise.
draw_down 10y ago
It's just "Elm is good and other languages are bad/not as good". I try to be live-and-let-live about such things.

kemiller 10y ago

This has always been my experience with TDD, at least if you always leave yourself a failing test when you go. A lot more labor-intensive, since you are essentially writing the "compiler" as you go, but a similar effect.

tlrobinson 10y ago
I think "gradual typing" like Flow might be a nice middle-ground. You're still free to quickly sketch out ideas without worrying about type checking, but you can solidify things by just adding /* @flow */ to the top of a file and fixing the errors. I haven't actually tried Elm though, so maybe a "middle-ground" isn't necessary.
- shimon 10y ago
  This is the promise of type inference. Languages like Elm that do a good job inferring types are able to play out potentially invalid implications of how your code uses values without requiring you to separately specify all your types in great detail. You'll spend some time just addressing edge cases as "safe to ignore" but it's a lot lower than explicit typing while delivering many of its benefits.
  - tlrobinson 10y ago
    Flow actually does type inference as well.
  - skybrian 10y ago
    Type inference usually makes it harder for a compiler to provide good error messages though. Elm has gone the extra mile on this.
- pka 10y ago
  This will sound counterintuitive to dynamic language people, but prototyping is actually much easier with types. I often find myself rewriting 50 to 75% of the codebase in the early stages of prototyping, and without types I'd be much less willing to do that, settling for a less than ideal design. This design will then be the base of a potentially large project, which amplifies early mistakes even more.

shrugger 10y ago

What does this mean? There is almost no detail in this other than "Wow Elm is great and the compiler gives persistent, detailed messages" which I think most people interested in Elm already knew.

Tehnix 10y ago
I guess the only new addition is that a side-effect of the very helpful errors is that it's easy to eventually come back to your work later on. There's also a lot less state to keep in your head, as it's usually a lot more transparent.
wanderer2323 10y ago
It makes other people (like me) interested in Elm

kriro 10y ago

The title is unfortunate. At first I though...wait why are they discontinuing Elm, what did I miss. I've never written anything in Elm but that short post makes me want to try it. Sounds like a pretty great feature of a language to have easy to follow error messages you can readily pick up. This also made me chuckle """I thought Elm was a pure, functional language, but this is one hell of a side effect."""

actsasbuffoon 10y ago
The error messages in Elm really are outstanding. I've never used a language that has such clear, concise, and human-friendly error messages. It's a high water mark, and I hope other programming languages are inspired to try to equal what Elm has accomplished.
agumonkey 10y ago
I literally had to read it 5 times before realizing it's not a dismissal of Elm.

therealmarv 10y ago

ok nice. We know that. I'm personally touching Elm only after they have something like ComponentDidMount from React or something which is better implementend than "wait 50msec and do something like set focus" on their (virtual) DOM rendering is solved: https://github.com/evancz/elm-todomvc/blob/8be8914582870d59989ce518e6c7d38f8081faaf/index.html#L18-L25 https://github.com/evancz/elm-todomvc/blob/8be8914582870d599...

kylecordes 10y ago
I'm not sure this is a fair criticism. The nice thing about this tiny chunk of code is that there is only one aspect of this example program that needs to manipulate the already instantiated DOM, and that tiny chunk is explicitly brought up to the top level and separated and connected back to the program via the port mechanism. It would certainly be worse if this magic happen behind the scenes. Of course it could be better, and that's probably what you are getting at. Ideally the machinery provided for building web applications would be more aware of the nature of web applications and have something in the box (still explicit and obvious, but in the box) to do something like setting focus.
- Hupriene 10y ago
  It's absolutely a fair criticism. The real DOM is stateful, elm's virtual DOM is not, and elm doesn't provide any tools to manipulate the state of the real DOM. This impedance mismatch is bound to cause problems any time you are dealing with the stateful aspects of the DOM. And solutions like the one linked to by GP are error prone and fragile.
maxthegeek1 10y ago
Elm gives you the ability to hook into requestAnimationFrame, which allows you to execute some native js through a port when a piece of html first renders.
ccapndave 10y ago
This is certainly annoying at the moment (although there are workable hacky solutions). However it's a well known issue and there is movement at https://github.com/elm-lang/html/issues/19 https://github.com/elm-lang/html/issues/19 so hopefully it will be addressed in the near future.

tacos 10y ago

This is the perfect example of the content-free HN posts that are topping the charts lately. It contains not a single example of a "helpful error message." Nor a single line of code from the language in question. Just a 173 word free-verse poem with some feel-good handwaving. If this were a post about soap (the salt, not the protocol) we'd downvote the post as obvious content-free shilling. But because it's some obscure language that doesn't even make the top 100 TIOBE language list, here we are, upvoting someone we've never heard of, celebrating his opinion of awesome compiler error messages that none of us has ever seen, for a language that nobody uses. http://www.tiobe.com/tiobe_index http://www.tiobe.com/tiobe_index

pka 10y ago
In the time it took you to write your content-free comment, you could've googled Elm and seen the error messages yourself.
- mdm_ 10y ago
  Great, I look forward to future HN posts such as "Elm is really super. The rest of this article is left as an exercise for the reader."
tvon 10y ago
I think this is a case where the topic is something that enough people want to discuss so the post generates discussion regardless of the content. I agree with the basic gist of your comment, there isn't much content here to discuss (no offense to the author, it doesn't seem like it was meant for a site like HN). Though I think you might be over-reacting a bit with the tone of your comment.

programLyrique 10y ago

This blog post seems to be more explanatory about the error messages of Elm: http://elm-lang.org/blog/compiler-errors-for-humans http://elm-lang.org/blog/compiler-errors-for-humans

vinceguidry 10y ago

You should always let something else 'drive' your coding. Lots of people like tests. I personally am not a huge fan of TDD, though it's better than a lot of alternatives. Essentially, you set a visible goal. Passing test, compiling program, running command, visible widget on a browser. Run the test / command / browser URL and watch it fail. Let the error message you get determine your next step. It makes a good debugging workflow too. The first step is to get a reproduction. Then you need to set up an environment where you can repeatedly and idempotently reproduce the bug at will. Then all you have to do is keep trying and learning things about the system until you know enough to devise a fix. Here you can manipulate the command itself to exercise less of the system, giving you a clearer idea of where the bug is. Whereas if you're building a new feature, you want to keep the command static until you see what you want to see. There's nothing magic about programming languages or paradigms that allows you to do this more easily. It's just how well you know your system. Some domains are trickier. You need special tools and expertise to reproduce network errors, and God help you if your stack isn't memory safe.

Kip9000 10y ago

Elm is a great language for web. It's evolving but there are some bits that need some rework/improvement/rethought like the canvas performance and managing random number generation. This is difficult with purely functional architecture. But there are a quite a lot of good thought gone into making the whole functional programming user friendly and a pleasant experience. Kudos to the creators/maintainers

md224 10y ago

I feel like something clicked for me once I realized that all functions in Elm are curried by default. Cool feature.

deleted 10y ago

[deleted]

mrcactu5 10y ago

in my experience, when I am stuck figuring out types, I just let the compiler do it. As the error messages are so well-formed, it tells me exactly which lines are inconsistent and how to put the types back together. most compilers tell you there's a problem but none outline how to fix it the way Elm does

gjolund 10y ago

Elm has the best error messages of any language I have ever used. I have dreams about it one day replacing JS as the front end language of choice.

andrewvijay 10y ago

Fell into the bait! Clicked and disappointed at a different content than expected

hawkice 10y ago

To me, the most promising thing about elm is how much improvement it has seen. The last minor version was a huge leap forward for building real things AND for beginners. The makers of elm (seems to mostly be Evan Czaplicki) think about things the same way I do, except they are thinking about it more than I do and more carefully. Whether it's elm or anything else, I'm glad the tool-explosion has let more people use tools they vibe with. Hopefully it will help more random people (like me) do more cool stuff.