10 ms·

Making Elm faster and friendlier in 0.16

243 points by jwmerrill 11y ago

Apanatshka 11y ago
Long anticipated, and now finally here :) I <3 the type diffs, exhaustiveness checks and TCO. Not completely sure about the removed syntax, but it's not like I used it a lot, so I guess simpler is better.
notacoward 11y ago
Very nice. I love the "beginner hints" idea, and explicit enumeration of which cases are missing in incomplete pattern matches. Overall, the "compilers as assistants" idea seems great.
nathankleyn 11y ago
Some of these errors remind me of Rust and the attempts in that community to give every error an exhaustive description [1]. This looks fantastic, and shows a true commitment to reducing friction with the language - a goal which often goes too long without attention. [1]: https://github.com/rust-lang/rust/issues/24407 https://github.com/rust-lang/rust/issues/24407
- steveklabnik 11y ago
  Yup, I would strongly agree. Diagnostics are one of those things that's easy to let slip by the wayside, but we've seen a huge payoff for users with all the time we've invested in ours. Glad to see other languages like Elm help raise the bar here too.
sotojuan 11y ago
Elm is such a pleasure to learn. I really need to sit down and write something non-trivial with it one of these days.
hellofunk 11y ago
Elm is a beautiful expression of a language. Alone, it is a work of art. Put to use, it lets you build works of art. One of the best contributions to modern languages.
laszlok 11y ago
Finally TCO! Actually in my UI-heavy Elm programs it isn't that often that I have to write functions with large recursion depth. But it is really comforting to know that the compiler is analyzing my code and making it more efficient. :)
mdm_ 11y ago
I'm just finishing up a first-year course at McMaster University where we learned basic CS concepts (divide and conquer, state machines, recursion, algebraic data types, FRP, etc) using ELM. It's the first time I've ever put an honest effort into learning a pure functional language, and although it was initially frustrating to a self-taught programmer with a background in several procedural languages and SQL, it's growing on me, and I'm probably going to look for a side project (maybe a small game or a simple CPU simulator) to build with ELM when the course is over. I only wish the "Improved error messages" and "Catching more bugs" features had been introduced about three months ago, probably would have saved me hours!
khgvljhkb 11y ago
I wish the clojure compiler also had the explicit goal of making things easier like this...
- lemming 11y ago
  There is hopefully some movement in that direction after my talk at the conj: https://www.youtube.com/watch?v=kt4haSH2xcs https://www.youtube.com/watch?v=kt4haSH2xcs. I'm continuously inspired by Evan's approach and his dedication to the user experience, and I hope to be able to bring some of that to Clojure.
methehack 11y ago
I'm trying to decide between Elm and React/Reflux for the js part of a side project. I'm concerned about learning curve and awkwardness of adoption if the project ever turns into something someone else is coding on. I know they are very different technologies, but I think others must be choosing between them. Any thoughts from those who have tried both?
- jmite 11y ago
  The learning curve is not terribly steep, compared to Haskell. There are a lot of good resources, and many friendly people on the mailing list to help you if you decide to learn Elm!
- jdudek 11y ago
  Elm is a much, much smaller community than React. You won’t find as many libraries and ready-made components in Elm as you would in React. On the other hand, when there is an Elm library for something, it’s often of very high quality.
- danneu 11y ago
  I personally like React + Immutable.js (for the store) + Redux (https://github.com/rackt/redux https://github.com/rackt/redux) which is more similar to Om and apparently Elm. It's actually the first Fluxlike implementation I willingly use.
  - mercurial 11y ago
    I'm using the same stack (minus immutable.js, but I'm thinking on it), combined with redux-simple-router. Apart from the usual problems associated with Javascript, it works pretty well, and I feel it's easy to understand what is going on. On the other hand, there are some pitfalls. Since you may need to trigger actions based on some transient state (eg, fetching data from the server), you occasionally need to set flags in your store ("my state is dirty"). Forgetting to clean up a flag will lead to tears.
  - Keats 11y ago
    Same here, just switched to TypeScript today and it's quite nice. Not as nice than Elm in terms of tooling (those errors are much more helpful than the TypeScript one and js of course). I guess it depends whether you want the React community or don't mind a smaller one and a functional language.
boubiyeah 11y ago
I find the Elm language quite fun and I think it has potential. However, I'm absolutely not convinced about "the Elm architecture" for anything but the simplest UIs. Is pure functional reactive programming suitable for ambitious UIs ? I do not think so. React has its own set of flaws but at least I believe it nailed the state problem: Encourage the minimization of local state but still make it easy to have some when necessary. I like functional programming a lot but I think this is a case where good old object oriented encapsulation provides a more pragmatic solution. There are all sorts of transient states that a parent's component shouldn't have to care about (Whether I currently have focus, a transient list of changes not yet committed that should be thrown away should I navigate away, is the calendar drop-down opened?, etc, etc) Elm makes it hard to have truly rich and reusable components for that reason as all that transient state must leak to the parent components. But that's still doable at least, if cumbersome; some other things simply appear impossible, like coding a ReactTransitionGroup equivalent. This React component encapsulates the concept of a changing-over-time list of children and animate in/out the children that changed across two redraws. It needs to know about the previous list of children to diff it with the new. It needs to manipulate the actual Virtual nodes passed to it so that it temporarily leaves the exiting nodes till their animation finished, etc. This thing has tons of state and it needs it to do its job; and it's fine. How would you do this in Elm without leaking the abstraction at every call site ? (I'm looking for a pragmatic, easy-to reuse by everybody solution, not some convoluted sliding Signal of component lists ;-) ) I'm wondering whether performance tweaks should be the focus right now; Elm already had good performances. The issue is adoption, and if it's too convoluted to write (non trivial) reusable components, I don't see how it can succeed. Right now I would never start a complex project with it in fear of getting stuck with a medium-complexity task because the architecture didn't foresee my problem. Maybe the architecture provide some escape hatches I didn't see, and I would love to be proven wrong.
- spuz 11y ago
  I have been contemplating the same issue. Unfortunately I haven't yet had enough of a chance to write a large complex application to verify whether or not the Elm Architecture works in practice. In particular the potential for actions and effects of subcomponents to pollute the code of parent components concerns me. If you have some further insight I would love to see a blog post comparing React and Elm that demonstrates where the issues are. Also, the Elm community could potentially make suggestions or take those issues into account for the future.
excitom 11y ago
My first thought on seeing this post was "Oh wow, people are still using the elm email client". I guess I'm getting old.
- Apanatshka 11y ago
  hehe, I see this every time on an HN post about a new Elm release. At some point I'll have to look into that old email client, I'm curious what people are talking about.
garyclarke27 11y ago
If Elm had a dedicated library for io with Postgres functions (stored procedures) would then become very attractive to my company, for a very ambitious project we are developing. we store all state and logic inside db safely firewalled by stored procs, so i'm looking for UI focused language/ toolset that is productive, functional and produces atractive ultra reliable, performant html js. I don't feel good about the Sencha tools, my team currently uses, so I'm looking around for alternatives. ur/web looks very interesting aswell but the limited adoption with only 1 albeit genius developer, is a bit offputing
- ac2u 11y ago
  I don't understand, elm is for your browser based application, which can't communicate with postgres anyway except through a web server sitting in the middle.
  - aflinik 11y ago
    That's true, although I see no reason Elm couldn't be compiled to server-side JS running in Node. I'd love to see some full stack solution that would abstract away separation between backend and frontend (like Meteor perhaps) using some sane programming language and architecture. Having built lots of SPAs and APIs serving as a backend for them I always feel that what's really relevant is modelling your data and domain logic (which tends to happen on a server side) and the UI consuming this data on the other end. Everything in between – endpoints exposing the data on the backend, frontend machinery to pull that data into client – seems to be totally arbitrary and implementing it is nothing short of a grind.
bribri 11y ago
Has anyone tried Reflex? Really interesting concept in Haskell + GHCJS https://github.com/ryantrinkle/try-reflex https://github.com/ryantrinkle/try-reflex I liked Elm but I felt the language was a bit limited coming from Haskell, ex no type classes so you have List.map, Signal.map, Set.map, etc Overall Elm is great in terms of tooling, setup, error messages, performance, js interop though
- ablesearcher 11y ago
  Reflex is great (and its author is a genius) but it's not really useful yet for non-desktop apps. Because Reflex + GHCJS is impossibly slow on mobile. As an experiment, try using chrome (iOS) or android to load this: obsidian.systems/reflex-nyhug/ or this: https://obsidian.systems/ https://obsidian.systems/ They're both reflex apps. GHCJS is bees-knees. But unfortunately, minimizing-code-size/mobile-performance has not been a priority. (It's understandable, as Luite can't do everything himself.) (Aside: the best solution I've seen -- in terms of generated code size -- in GHCJS-land right now is: https://hackage.haskell.org/package/react-flux https://hackage.haskell.org/package/react-flux. Anecdotal, though. YMMV.) I can't wait for GHCJS to be ready for prime time. I wish all these alt-JS-haskellish language authors (of Purescript, Elm, Roy, etc.) would just work on making GHCJS better. It's a bummer that Clojure and Scala are much newer than Haskell and yet they both have a mature, production-ready JS compiler. The statically typed ML-family is too small for multiple JS compilers. The entire community needs to pick one and let the others die. Otherwise, we end up with several half-baked solutions and not a single industrial-strength one.
  - purescript 11y ago
    > I wish all these alt-JS-haskellish language authors (of PureScript, Elm, Roy, etc.) would just work on making GHCJS better. All three of those have very different goals and trade-offs from GHCJS. I agree that it would be nice to share more work/knowledge though. One of the nice things about AltJS is that several languages can coexist in the same codebase.
    - ablesearcher 11y ago
e12e 11y ago
Apparently the web site is having some issues? Google cache: http://webcache.googleusercontent.com/search?q=cache:http://elm-lang.org/blog/compilers-as-assistants http://webcache.googleusercontent.com/search?q=cache:http://...

243 points by jwmerrill 11y ago

Long anticipated, and now finally here :) I <3 the type diffs, exhaustiveness checks and TCO. Not completely sure about the removed syntax, but it's not like I used it a lot, so I guess simpler is better.

notacoward 11y ago

Very nice. I love the "beginner hints" idea, and explicit enumeration of which cases are missing in incomplete pattern matches. Overall, the "compilers as assistants" idea seems great.

nathankleyn 11y ago

Some of these errors remind me of Rust and the attempts in that community to give every error an exhaustive description [1]. This looks fantastic, and shows a true commitment to reducing friction with the language - a goal which often goes too long without attention. [1]: https://github.com/rust-lang/rust/issues/24407 https://github.com/rust-lang/rust/issues/24407

steveklabnik 11y ago
Yup, I would strongly agree. Diagnostics are one of those things that's easy to let slip by the wayside, but we've seen a huge payoff for users with all the time we've invested in ours. Glad to see other languages like Elm help raise the bar here too.

sotojuan 11y ago

Elm is such a pleasure to learn. I really need to sit down and write something non-trivial with it one of these days.

hellofunk 11y ago

Elm is a beautiful expression of a language. Alone, it is a work of art. Put to use, it lets you build works of art. One of the best contributions to modern languages.

laszlok 11y ago

Finally TCO! Actually in my UI-heavy Elm programs it isn't that often that I have to write functions with large recursion depth. But it is really comforting to know that the compiler is analyzing my code and making it more efficient. :)

mdm_ 11y ago

I'm just finishing up a first-year course at McMaster University where we learned basic CS concepts (divide and conquer, state machines, recursion, algebraic data types, FRP, etc) using ELM. It's the first time I've ever put an honest effort into learning a pure functional language, and although it was initially frustrating to a self-taught programmer with a background in several procedural languages and SQL, it's growing on me, and I'm probably going to look for a side project (maybe a small game or a simple CPU simulator) to build with ELM when the course is over. I only wish the "Improved error messages" and "Catching more bugs" features had been introduced about three months ago, probably would have saved me hours!

khgvljhkb 11y ago

I wish the clojure compiler also had the explicit goal of making things easier like this...

lemming 11y ago
There is hopefully some movement in that direction after my talk at the conj: https://www.youtube.com/watch?v=kt4haSH2xcs https://www.youtube.com/watch?v=kt4haSH2xcs. I'm continuously inspired by Evan's approach and his dedication to the user experience, and I hope to be able to bring some of that to Clojure.

methehack 11y ago

I'm trying to decide between Elm and React/Reflux for the js part of a side project. I'm concerned about learning curve and awkwardness of adoption if the project ever turns into something someone else is coding on. I know they are very different technologies, but I think others must be choosing between them. Any thoughts from those who have tried both?

jmite 11y ago
The learning curve is not terribly steep, compared to Haskell. There are a lot of good resources, and many friendly people on the mailing list to help you if you decide to learn Elm!
jdudek 11y ago
Elm is a much, much smaller community than React. You won’t find as many libraries and ready-made components in Elm as you would in React. On the other hand, when there is an Elm library for something, it’s often of very high quality.
danneu 11y ago
I personally like React + Immutable.js (for the store) + Redux (https://github.com/rackt/redux https://github.com/rackt/redux) which is more similar to Om and apparently Elm. It's actually the first Fluxlike implementation I willingly use.
- mercurial 11y ago
  I'm using the same stack (minus immutable.js, but I'm thinking on it), combined with redux-simple-router. Apart from the usual problems associated with Javascript, it works pretty well, and I feel it's easy to understand what is going on. On the other hand, there are some pitfalls. Since you may need to trigger actions based on some transient state (eg, fetching data from the server), you occasionally need to set flags in your store ("my state is dirty"). Forgetting to clean up a flag will lead to tears.
- Keats 11y ago
  Same here, just switched to TypeScript today and it's quite nice. Not as nice than Elm in terms of tooling (those errors are much more helpful than the TypeScript one and js of course). I guess it depends whether you want the React community or don't mind a smaller one and a functional language.

boubiyeah 11y ago

I find the Elm language quite fun and I think it has potential. However, I'm absolutely not convinced about "the Elm architecture" for anything but the simplest UIs. Is pure functional reactive programming suitable for ambitious UIs ? I do not think so. React has its own set of flaws but at least I believe it nailed the state problem: Encourage the minimization of local state but still make it easy to have some when necessary. I like functional programming a lot but I think this is a case where good old object oriented encapsulation provides a more pragmatic solution. There are all sorts of transient states that a parent's component shouldn't have to care about (Whether I currently have focus, a transient list of changes not yet committed that should be thrown away should I navigate away, is the calendar drop-down opened?, etc, etc) Elm makes it hard to have truly rich and reusable components for that reason as all that transient state must leak to the parent components. But that's still doable at least, if cumbersome; some other things simply appear impossible, like coding a ReactTransitionGroup equivalent. This React component encapsulates the concept of a changing-over-time list of children and animate in/out the children that changed across two redraws. It needs to know about the previous list of children to diff it with the new. It needs to manipulate the actual Virtual nodes passed to it so that it temporarily leaves the exiting nodes till their animation finished, etc. This thing has tons of state and it needs it to do its job; and it's fine. How would you do this in Elm without leaking the abstraction at every call site ? (I'm looking for a pragmatic, easy-to reuse by everybody solution, not some convoluted sliding Signal of component lists ;-) ) I'm wondering whether performance tweaks should be the focus right now; Elm already had good performances. The issue is adoption, and if it's too convoluted to write (non trivial) reusable components, I don't see how it can succeed. Right now I would never start a complex project with it in fear of getting stuck with a medium-complexity task because the architecture didn't foresee my problem. Maybe the architecture provide some escape hatches I didn't see, and I would love to be proven wrong.

spuz 11y ago
I have been contemplating the same issue. Unfortunately I haven't yet had enough of a chance to write a large complex application to verify whether or not the Elm Architecture works in practice. In particular the potential for actions and effects of subcomponents to pollute the code of parent components concerns me. If you have some further insight I would love to see a blog post comparing React and Elm that demonstrates where the issues are. Also, the Elm community could potentially make suggestions or take those issues into account for the future.

excitom 11y ago

My first thought on seeing this post was "Oh wow, people are still using the elm email client". I guess I'm getting old.

Apanatshka 11y ago
hehe, I see this every time on an HN post about a new Elm release. At some point I'll have to look into that old email client, I'm curious what people are talking about.

garyclarke27 11y ago

If Elm had a dedicated library for io with Postgres functions (stored procedures) would then become very attractive to my company, for a very ambitious project we are developing. we store all state and logic inside db safely firewalled by stored procs, so i'm looking for UI focused language/ toolset that is productive, functional and produces atractive ultra reliable, performant html js. I don't feel good about the Sencha tools, my team currently uses, so I'm looking around for alternatives. ur/web looks very interesting aswell but the limited adoption with only 1 albeit genius developer, is a bit offputing

ac2u 11y ago
I don't understand, elm is for your browser based application, which can't communicate with postgres anyway except through a web server sitting in the middle.
- aflinik 11y ago
  That's true, although I see no reason Elm couldn't be compiled to server-side JS running in Node. I'd love to see some full stack solution that would abstract away separation between backend and frontend (like Meteor perhaps) using some sane programming language and architecture. Having built lots of SPAs and APIs serving as a backend for them I always feel that what's really relevant is modelling your data and domain logic (which tends to happen on a server side) and the UI consuming this data on the other end. Everything in between – endpoints exposing the data on the backend, frontend machinery to pull that data into client – seems to be totally arbitrary and implementing it is nothing short of a grind.

bribri 11y ago

Has anyone tried Reflex? Really interesting concept in Haskell + GHCJS https://github.com/ryantrinkle/try-reflex https://github.com/ryantrinkle/try-reflex I liked Elm but I felt the language was a bit limited coming from Haskell, ex no type classes so you have List.map, Signal.map, Set.map, etc Overall Elm is great in terms of tooling, setup, error messages, performance, js interop though

ablesearcher 11y ago
Reflex is great (and its author is a genius) but it's not really useful yet for non-desktop apps. Because Reflex + GHCJS is impossibly slow on mobile. As an experiment, try using chrome (iOS) or android to load this: obsidian.systems/reflex-nyhug/ or this: https://obsidian.systems/ https://obsidian.systems/ They're both reflex apps. GHCJS is bees-knees. But unfortunately, minimizing-code-size/mobile-performance has not been a priority. (It's understandable, as Luite can't do everything himself.) (Aside: the best solution I've seen -- in terms of generated code size -- in GHCJS-land right now is: https://hackage.haskell.org/package/react-flux https://hackage.haskell.org/package/react-flux. Anecdotal, though. YMMV.) I can't wait for GHCJS to be ready for prime time. I wish all these alt-JS-haskellish language authors (of Purescript, Elm, Roy, etc.) would just work on making GHCJS better. It's a bummer that Clojure and Scala are much newer than Haskell and yet they both have a mature, production-ready JS compiler. The statically typed ML-family is too small for multiple JS compilers. The entire community needs to pick one and let the others die. Otherwise, we end up with several half-baked solutions and not a single industrial-strength one.
- purescript 11y ago
  > I wish all these alt-JS-haskellish language authors (of PureScript, Elm, Roy, etc.) would just work on making GHCJS better. All three of those have very different goals and trade-offs from GHCJS. I agree that it would be nice to share more work/knowledge though. One of the nice things about AltJS is that several languages can coexist in the same codebase.
  - ablesearcher 11y ago

e12e 11y ago

Apparently the web site is having some issues? Google cache: http://webcache.googleusercontent.com/search?q=cache:http://elm-lang.org/blog/compilers-as-assistants http://webcache.googleusercontent.com/search?q=cache:http://...