14 ms·

Why Elm? [pdf]

194 points by antouank 9y ago

ng12 9y ago
One thing I don't see addressed here is the biggest "Why Not Elm": you have to learn Elm. Elm is a beautiful language and in the last year or two the ecosystem has gotten much better. However I don't think I'll ever make progress adopting it at my day job. For all of it's flaws JavaScript is still quick, scrappy, and easy to pick up. Convincing a curmudgeonly back-end developer that React and webpack will make his life easier is hard enough. Convincing him to learn a seemingly esoteric functional language too is basically a non-starter.
- splintercell 9y ago
  I have learned ELM and I have done React + Redux development, and I can say that I found learning and using former a lot easier than doing the latter. Probably because react redux were trying to make me learn a new concept over existing knowledge of JS was, while Elm was easier to pick up because I entered with a mindset of learning a new language. For those who are new to any kind of development, learning Elm would be no more different/difficult than learning react redux.
  - ng12 9y ago
    I think that's only true if you're already familiar with Haskell-like languages. Elm-html is conceptually close to React/Redux so you basically have to learn it either way. Even knowing a few functional languages already it took a while for me achieve a basic level of competency with Elm. On the other hand someone who knows Java can pick up JS in an afternoon.
    - Risord 9y ago
      I don't know. I felt sameway that elm was easier when I was learning Vue with all modern shiny stuff. I had done mostly C#/Java and some old school JS programming but none Haskell likes. It's hard to say which ones was easier since learning experiences were so different. Maybe learning took approximately same time but time was used with JS for googling and brute forcing things. On the other side Elm compiler just said "You probably did this common error ####. Try do ###" so learning was much more efficient since you know instantly what was wrong and why. I can certainly say that learning Elm was much more pleasant one for me.
- cel1ne 9y ago
  Why not Elm on google turns up this: http://reasonablypolymorphic.com/blog/elm-is-wrong http://reasonablypolymorphic.com/blog/elm-is-wrong I think the basic gist was that it's type-system is far from complete.
  - commandertso 9y ago
    FWIW, when this was new it got a lot of pushback in a related Reddit thread. Might be worth digging in if you're seriously thinking about it.
  - AlexCoventry 9y ago
    This was definitely a pain point for me when I experimented with Elm.
  - 0xCMP 9y ago
    It's not that it is not complete, but not entirely as powerful as Haskell which inspires a lot of how Elm works and looks like. The creator/maintainer of elm doesn't believe they're required.
  - zeptomu 9y ago
    The main critics is that it does not support type classes, but maybe that is actually not a bad thing. The discussion is similar to the never ending Go discussion about generics and people do amazing stuff with Go (now I guess critics would say they would do even more amazing stuff with generics). Not that I say type classes (or generics) are useless, but keeping a language simple (in the sense of keeping the feature list small) has benefits on its own. I did not to complicated projects in Elm, but I watch the language closely and really like what I have seen so far, so I hope Evan keeps up the good work, as I think he has pretty good taste for language design.
- allochthon 9y ago
  Wrapping my head around Elm took a little while. I was enjoying my progress until I attempted to abstract out some view render code into a separate module. I fought with the type system for a long time and had difficulty getting beyond an obscure compiler complaint.
- danyx 9y ago
  I'm actually surprised that so many teams have this view. We are a very small dev team working on scientific apps and I feel that the time it took us all to get comfortable with Elm was easily recouped by the constant development speed we had even as the app got bigger. In Javascript, projects just become harder and harder to refactor and so they accumulate cruft and development speed drops as the project ages. In Elm, with the help of a really decent type system and a helpful compile, we were able to keep going and just add features at a constant pace. I think it's worth taking a close look at Elm for this reason alone (or Purescript for that matter but there it is possible to get lost in rabbit holes of type complexity :) ).
  - ng12 9y ago
    > We are a very small dev team That's the secret though, right? When you have teams of dozens of developers in a company of thousands the cost of adoption and the resistance you encounter increases exponentially. At least I can evangelize React/Redux/Typescript and get a sane development experience that's still just JavaScript.
    - firethief 9y ago
      That's an interesting claim. Can you elaborate on the superlinear factors of the cost increase?
      - mikekchar 9y ago
        I'm not entirely sure that the cost is exponential as the parent stated, but it certainly is superlinear above a certain threshold in my experience. There are a few issues you have to deal with. The first is how adoption happens. This is generally based on power structures and reputation. If you are in a position to mandate a change, the cost is potentially lower (see below, though), but if you are not then you have to influence enough people to make a change. There are many ways to do this, but I will split it into 2 for simplicity. First, you can try to influence the rest of the group directly. As the group size grows, this becomes progressively more difficult because your message is lost in the noise of other people pressing their own agendas. Once you get above certain point (say about 8-10 people), your odds of success drops to near zero. The other main way is to pilot a project and use its success to influence others. Setting up the pilot requires influencing a smaller group and therefore you have higher chances of success. The problem is that when you pilot a new way of doing things, you are intentionally breaking consensus. You now have a small group of individuals who have experience that nobody else in the group has. Whether the adoption of the new technique is successful or not, this leads to increased cost as attitudes change. The bigger the group, growing out a pilot into a larger project becomes more expensive. This is essentially the same problem as before -- you may be in a position now to mandate a way of working, but if you are not, then you have to create another round of pilots to move the idea around the group. But now you have another problem -- the implementors of the new pilots are different than the implementors of the original pilot. So you will now have more than one message coming out. You now have to harmonise that message in order to drive adoption. At every step, there is a chance of failure (sometimes quite high). The chance of failure grows as size of the group increases, because the external pressures to not change are higher. Again, there are several possible outcomes, but I will pick 2 for simplicity. You may find that your idea is rejected. You have now spent resources on your pilot that you will have to reimplement in another way. Another outcome is that your adoption is simply stalled -- you split your group permanently. This has cost implications ranging from staffing, to training, to tooling, to management, etc. Now, assuming you don't fail, you may have organically grown the adoption in your group (which is ideal), but as your group size grows, the possibility of that decreases (because the risk of failure increases based on the size of the group). More likely is that you have gotten enough reputation to be able to mandate a change. Mandating changes has costs as well. The first is that some people will be uncomfortable with the change and will quit. You now have to replace those individuals - which costs you both lost productivity, referral fees, and training costs. This is more likely as the group size increases because you are more likely to have diverse, strongly held opinions. The next biggest cost would appear to be training, retooling, etc. However, there is a hidden cost -- compliance. Very good people who dislike the change will leave. Very poor people will not leave -- they will simply refuse to follow the new strategy competently. This may be because they are depressed over the change, scared of how the change affects their influence, and many other things. These people can often end up sabotaging your projects (mostly unintentionally, but as they are usually quite upset they also don't care if they do). As the size of the group increases, the chances of building an unshiftable group of discontents grows. If you want to make a lot of money, become a consultant introducing new development techniques into large organisations like banks. It's a bit like siphoning all their operating capital into your pocket because you have no hope of success and can blame all your failure on other people.
- napsterbr 9y ago
  Before diving into elm, I had this fear too. But speaking from someone who never used haskell before (hell, I never used a statically typed language before), learning elm was quite simple. There's a lot of help from the compiler and the community as well. After two weeks I was quite confident on my work, and in one month I managed to create the entire architecture of our production app. Through the months I got a better grasp of elm and refactored the entire app several times (not nearly as painful as it sounds). I've made the decision to use elm and put my two frontend devs to learn it. They managed to start contributing to the app in less than a week. So if you have the chance, I think it's worth a shot. I thought I'd never learn elm, but so far my experience proved that it's much easier than it seems.
  - KurtMueller 9y ago
    > Through the months I got a better grasp of elm and refactored the entire app several times (not nearly as painful as it sounds). Refactoring Elm code isn't as painful for me as Javascript or Ruby - because it's statically compiled, it gets rid of a whole class of errors. The compiler does an excellent job at where compilation fails and suggestions to fix the error. Additionally, I find in Elm (and other ML-typed languages) that it's easy to model states of your app (e.g. like a state machine) and events that change the state of your app. Adding/modifying states and events in Elm is one of its strong suits and it really forces you to logically think through how your app transitions from one state to another. Scott Wlaschin has an excellent talk on Domain Driven Design in F# that articulates this point quite well.
- boubiyeah 9y ago
  In my company, whenever a backend dev has to do frontend dev, it never ends well :(
0xCMP 9y ago
I like Elm a lot. I also do a lot of React and I have worried about picking Elm to avoid killing a nice product written in it because no one is willing to learn it to maintain it after I'm gone. Better to pick React to avoid any rewrites just to continue maintaining the product. However, if they could just be convinced to learn Elm I'm positive that Elm would be much easier to maintain and improve than just React by its self. React can definitely be maintained easily, but Elm does a lot of the work to check itself and also enforces discipline that React can't (although you could get a lot by just using Flow extensively and treating its errors as blockers).
- mistersys 9y ago
  The static types system is great, however, having used elm: elm unloads much of the work react does onto you. React automatically (with keys) manages state creation for lists and child components, but with elm you have to manage that manually. Using a component isn't simply matter of importing and using, you have to integrate its state into your component, send all it's events back to its reducer, and then map each child state to the corresponding view. You end up with lots of boilerplate.
  - hathawsh 9y ago
    Would it be possible for Elm to evolve a way to let components keep internal state? The lack of component-local state is what ultimately drove me away from Elm for my last project. It seems like it should be possible, since Elm and Redux are vaguely similar and Redux can store component-local state if you need it to.
    - boubiyeah 9y ago
      I don't see this happening. local state would invalidate many things in the Elm ecosystem like the time travel debugger, all the tutorials, etc. It's not such an easy problem, you have to write a new reconciler that only renders the things that have changed instead of always rendering the entire tree. btw, redux only deal with global state but encourages the use of local (setState based) state whenever it makes sense.
zellyn 9y ago
I want to like and use Elm. However, unless things have changed recently, it seems the author hasn't learned to delegate. They also like to really get things right, which takes forever. So it's really good at what it does, but for everything else, it's just incomplete. For instance, Elm seems like a natural fit for an offline-first ServiceWorker design. But I don't think it really covers much of the just-outside-of-core-Javascript browser APIs. You're likely to run into "I have some really interesting ideas about how to cover that a super elegant way, but I'm concentrating on rewriting the $WHATEVER right now" newsgroup posts, but that's it… :-(
- canadaduane 9y ago
  Yes, this is a problem IMO. I dedicated 9 months to learning Elm, but left frustrated by the tight control and lack of delegation that would have leveraged my skills and many others' skills to further the idea and language.
  - skybrian 9y ago
    On the other hand, it's easier to wait patiently if you're not using the language yet :-) I've been watching Elm for some time. I'll wait until it's done. So my reason for not using Elm is: I'd rather be patient.
    - KurtMueller 9y ago
      I think you're going to be waiting indefinitely then :).
- boubiyeah 9y ago
  The elm language/framework designer is planning 10 years ahead. At least it's ambitious! For everyone who need to write SPAs right now (or in 2 years) it's just meh.
  - zellyn 9y ago
    In 10 years, the proverbial puck will have moved. Language ecosystems where the BDFL doesn't learn to delegate wither and die.
mistersys 9y ago
I've tried to use Elm and The Elm Architecture on a project before, but I gave up. The Elm Architecture makes it very easy to create small type safe components, but it forces parent components to manage the state + structure all children components. This makes it hard to use a component and to separate concerns. In order to create a list of stateful children, you must: 1. Add a list of the child states to the component state, event if the parent component doesn't care about the child's state. 2. Handle adding + removing child state's manually 3. Map all scoped child state updates through your reducer, adding a constructor to your action type 4. Finally, map each of the child state's to the component's view. You end up big types and match expressions that just manipulate lists. I have yet to see a FRP library that allows you to just use a component without introducing boilerplate.
- KirinDave 9y ago
  I'm curious if you've ever looked at optics-based systems for component coupling? Personally I think that the entire top-down state tree is a bad idea, but I'm willing to be convinced. I'd much prefer a modeling like the actor approach.
  - jadbox 9y ago
    I've seen optics for Cycle.js but I haven't found one yet for Elm. https://github.com/staltz/cycle-onionify https://github.com/staltz/cycle-onionify
  - uryga 9y ago
    > optics-based systems for component coupling Do you know of any good resources on that? Or projects using these concepts? Sounds interesting.
    - yiransheng 9y ago
      Calmm-js is one of these: https://github.com/calmm-js https://github.com/calmm-js
  - colordrops 9y ago
azangru 9y ago
I am surprized Elm gets talked about so much more than Purescript. Although Purescript is more of a general-purpose language and feels like Haskell that compiles to Javascript, and Elm is something that relies on its specific runtime to work.
- zem 9y ago
  same reason rails got so much more mindshare than any of the competing web frameworks of its day - there is considerable value in optimising for the common case, and indeed adding constraints in the name of safety and good architecture; most languages/frameworks try to optimise for flexibility and miss out on this fact.
  - KurtMueller 9y ago
    I think this is one of the main selling points about Elm - it's got conventions and it's got opinions. There's only one way to structure your app and it's the Elm way. That's a good thing when you're 1) building & growing the app - there's only way to grow and it must follow the same conventions as every other Elm app 2) bringing on developers - their main hurdle is the business logic itself and not the structure of the app 3) finding resources in the community - most everybody is traveling down the same road and can teach one another the lessons they've learned
- systems 9y ago
  Well, I think with so many language trying to replace javascript (purescript, coffeescript, livescript, clojurescript, bucklescript, dart, typescript .. probably there is more) It is impossible that all of them will be popular, plus more general purpose, doesnt really seem to help with popularity ... look at sql or r ... very popular, and very domain specific
- deleted 9y ago
  [deleted]
- deleted 9y ago
  [deleted]
- 9y ago
mrbill 9y ago
Too many products with conflicting names. I thought this was about the email client at first. http://www.instinct.org/elm/ http://www.instinct.org/elm/
- ng12 9y ago
  > Update 06th Jan 2000: elm 2.4 is not Y2K compliant. I'd be really surprised if it were.
  - richardwhiuk 9y ago
    > Sadly, most of the information about elm on the internet is badly out of date.* The program is still being slowly developed, and the release (March 24, 1999) of elm 2.5 is promising. Awesome.
- ryandrake 9y ago
  No idea why you're getting down-voted. The mail client was the first thing I thought of too. Was a really confusing read until I realized it wasn't about E-mail.
eweise 9y ago
I'm using Elm for an internal customer service app and it is working out fairly well. My background is more server side programming so the ability to avoid javascript and its constantly changing ecosystem is a big plus. Elm the language is simple enough to understand in a day and the basic architecture is also straightforward. The biggest challenges are finding examples of how to architect larger apps but this example should help https://github.com/rtfeldman/elm-spa-example https://github.com/rtfeldman/elm-spa-example Also, I tried mentoring another coworker on Elm but they seemed to have a harder time than I did. I think it could be partly because they were an experienced Javascript developer who wanted to apply their existing patterns to Elm.
antouank 9y ago
Been using Elm for a few months now. Both in small side projects, and in a production app for work. Many benefits over using js, and basically no downsides apart from the initial learning curve. And even that could be equal to the learning you have to do every time your team decides to add/use a new foo.js library or framework to the project. With Elm: - you are confident about your code - others ( and your future self ) can actually read it and understand it - it pushes you to think before you write - refactoring is a breeze, not a nightmare I hope I won't have to use js on my next gig. edit: Also, I cannot speak highly enough about how helpful the compiler is, and the community in the slack channel. Makes the whole experience a joy.
- ChemicalWarfare 9y ago
  +1. Totally digging Elm as well. Learning curve is pretty minimal, although I've spent some time "playing around" with Haskell which helped. Love how structured things are and even though Elm is an "in progress" kind of thing - still no left-pad or js fatigue type issues (unless you really try to make them happen).
- boubiyeah 9y ago
  That's just dynamic vs static typing though :p
  - antouank 9y ago
    You can say that. But, I also tried to learn and use OCaml and Haskell in actual projects. They are nowhere near as friendly and approachable as Elm to beginners.
    - KurtMueller 9y ago
      Elm is definitely in my future - in fact, many of the ML based languages are as well: Purescript, Haskell, F#, ReasonML, etc. Elm will be and is the gateway to all of that because it gives you only 1 path to traverse and tries to set up all the initial sign posts along the way.
    - 9y ago
arrty88 9y ago
Is it good for server side NodeJS as well?
- agentultra 9y ago
  Don't know about Elm, but there's Bucklescript or Reason and they generate really great, readable JS for use on Node. (And even on the front-end there's `bucklescript-tea`; a port of the Elm architecture to OCaml)
- boubiyeah 9y ago
  It's not designed for it. Some people do it, but it's a rough ride that need you to understand Elm's internals.
- daddykotex 9y ago
  Honestly, if you don't want to use JS on the server side then you should not. There are plenty of very good alternatives. I think Elm is to address the issue that JS is the only thing that runs in a browser. With that said, I suppose you could use it with Node as well.
snappyTertle 9y ago
Is there an effort to bring elm on native mobile to compete/work with react-native?
- kuon 9y ago
  There is https://github.com/ohanhi/elm-native-ui https://github.com/ohanhi/elm-native-ui
sandeepc24 9y ago
Also have a look at https://www.npmjs.com/package/fable-elmish https://www.npmjs.com/package/fable-elmish with F# flavor.
- KurtMueller 9y ago
  Do you use Fable / Fable-Elmish? If so, how do you like it?
  - sandeepc24 9y ago
    I am working on a project using Fable Elmish and I am really happy with it. All I can say is give it a shot.
    - KurtMueller 9y ago
      As a side project or at work? Thanks for any info.
deleted 9y ago
[deleted]
bauerd 9y ago
Off-topic, but here I go: Has anyone tried compiling Elm's compiler (written in Haskell) to JS (with ghcjs)? Are there any other small and approachable functional languages that are in-browser compilable and provide JS interop? I'd love to hack on a small Agent Based Modelling environment for the browser, comparable to what NetLogo[1] achieves in large on the desktop. Or maybe just make it a LISP? [1] https://ccl.northwestern.edu/netlogo https://ccl.northwestern.edu/netlogo
- firethief 9y ago
  Since you don't seem set on a language, let me throw my hump in for OCaml. It's supports a functional style without forcing you to use it for everything; js_of_ocaml compiles OCaml's dense, high-performance bytecode to Javascript that apparently integrates well with web APIs.
- sjrd 9y ago
  Since you mention NetLogo, note that it has a Web version whose compiler is written in Scala.js. (The Scala.js compiler itself does not run in the browser, though.)
jshute 9y ago
Elm hasn't merged a trivial change to allow manipulation of UTC and timezones in 6 months: https://github.com/elm-lang/core/pull/739 https://github.com/elm-lang/core/pull/739 Basically, if you have to deal with local time, this isn't the language for you. If you expect to be able to add to the platform where you find it lacking, this isn't the language for you. At this point, Typescript has the momentum to make it irrelevant
- zeptomu 9y ago
  Typescript is a completely different language advocating different paradigms so they are not comparable. However I have to agree with you that the lack of support for local time is pretty unfortunate.
  - jshute 9y ago
    I've used both heavily. I think paradigm is the key word if you're thinking mind-expanding properties. While immutable types and combinators are less used in Typescript (you've got me there) you can certainly get 80% of the value of strong typing, and there are several variants of Virtual DOM support. Elm's error messages and semantic versioning are still a class above anything else, though. Sad to see it rotting on the vine like this.
  - StreamBright 9y ago
    In this thread Elm was compared to OCaml and Haskell, comaparing it to Typescript is really not that bad. :)
- boubiyeah 9y ago
  The roadmap priorities always baffled me too. I mean, what elm needs now to be usable is surely not code splitting... Almost no one really need that, it's a late optimisation for top sites.
  - derefr 9y ago
    It makes sense if their strategy is to try to get at least one of said "top sites" to adopt them—which might, after all, result in development being sponsored or supported by full-time employees of whichever bigcorp runs the site.
rcgorton 9y ago
Elm (software): an interactive mail system Elm (physical): a tree Elm (this): "functional" software. While I do Knot No the language, any language which claims to be functional, but stateful behavior (such as network timeouts) is really not functional. AKA, pitching pretty/current buzzwords, rather than being a new/useful language. As for a "useful SPA" - a useful SPA has at least 300 gal. capacity and seating for 4+. Sigh - arbitrarily re-using names for pre-existing widgets is silly. Sort like claiming that Kleenex is actually a machine tool.
steinuil 9y ago
I think the two things Elm lacks the most right now are some form of polymorphism and some way to make parts of an Elm application manage their local state. At the moment there's only an internal API for the latter, and it's pretty ugly. I think what would be good for Elm would be to spin up a few separate Elm processes and provide an easy interface to make them communicate, sort of like in Erlang. You can do this using ports and binding them together with js right now, but it's kind of ugly.
bradknowles 9y ago
Good question. For a CLI mail client, I prefer mutt or pine. But elm isn't too bad as an alternative, if those aren't available.
Myrmornis 9y ago
The string "haskell" doesn't seem to appear in the text at all. That seems silly and rather patronizing, since it seems to be a book about a language that is heavily based on haskell, with very similar syntax. It bothers me when authors take this sort of "oh you don't need to know about that" approach.
jlebrech 9y ago
Last time i tried Elm I couldn't figure out how simply modify this clock example to move the hand quicker than every second http://elm-lang.org/examples/clock http://elm-lang.org/examples/clock
- redka 9y ago
  Well this isn't _that_ hard. Time.every (second / 2) Tick and to still move it the same amount: Tick newTime -> (newTime * 2, Cmd.none)
  - jlebrech 9y ago
    I tried to use millisecond, but I don't it has the same interface as second.
filoeleven 9y ago
Late to the party, but someone posted in the Ableton "Get started making music" thread[0] that the components in their slick web app[1] were made with Elm. Pretty impressive. [0] https://news.ycombinator.com/item?id=14299816 https://news.ycombinator.com/item?id=14299816 [1] https://learningmusic.ableton.com/ https://learningmusic.ableton.com/
kureikain 9y ago
I really like Elm. It makes writing code so easier. At first, it's bit hard to get into the habit. But once I got paste that state(that takes 1-2 days) and get into how to write Elm, everything become so clear. I currently use Rails and this helper[1] to render an Elm component. Then I mount it like this: [2] ``` <%= elm_component('TeamPicker', {flags: { formAuthenticityToken: form_authenticity_token, domain: current.domain, teams: user.my_teams.map { |team| {id: team.id.to_s, name: team.name || ""} }, current_team: {id: current.team.id.to_s, name: current.team.name || ""} }}, {tag: 'div', class: "nav-item"}) %> ``` I think this is an easy way to get into Elm world step by step. My site is still normal HTML but I used ELM here and there for some component require interaction/multi step form etc. --- [1]: https://github.com/NotyIm/trinity/blob/master/app/helpers/elm_helper.rb https://github.com/NotyIm/trinity/blob/master/app/helpers/el... [2]: https://github.com/NotyIm/trinity/blob/master/app/views/partials/dashboard/_header.html.erb#L46-L52 https://github.com/NotyIm/trinity/blob/master/app/views/part...
pcvarmint 9y ago
I used elm for a while after mailx, but finally settled on pine. I never got used to mutt's UI. Oh, how tech names keep getting recycled!!!

194 points by antouank 9y ago

ng12 9y ago

One thing I don't see addressed here is the biggest "Why Not Elm": you have to learn Elm. Elm is a beautiful language and in the last year or two the ecosystem has gotten much better. However I don't think I'll ever make progress adopting it at my day job. For all of it's flaws JavaScript is still quick, scrappy, and easy to pick up. Convincing a curmudgeonly back-end developer that React and webpack will make his life easier is hard enough. Convincing him to learn a seemingly esoteric functional language too is basically a non-starter.

splintercell 9y ago
I have learned ELM and I have done React + Redux development, and I can say that I found learning and using former a lot easier than doing the latter. Probably because react redux were trying to make me learn a new concept over existing knowledge of JS was, while Elm was easier to pick up because I entered with a mindset of learning a new language. For those who are new to any kind of development, learning Elm would be no more different/difficult than learning react redux.
- ng12 9y ago
  I think that's only true if you're already familiar with Haskell-like languages. Elm-html is conceptually close to React/Redux so you basically have to learn it either way. Even knowing a few functional languages already it took a while for me achieve a basic level of competency with Elm. On the other hand someone who knows Java can pick up JS in an afternoon.
  - Risord 9y ago
    I don't know. I felt sameway that elm was easier when I was learning Vue with all modern shiny stuff. I had done mostly C#/Java and some old school JS programming but none Haskell likes. It's hard to say which ones was easier since learning experiences were so different. Maybe learning took approximately same time but time was used with JS for googling and brute forcing things. On the other side Elm compiler just said "You probably did this common error ####. Try do ###" so learning was much more efficient since you know instantly what was wrong and why. I can certainly say that learning Elm was much more pleasant one for me.
cel1ne 9y ago
Why not Elm on google turns up this: http://reasonablypolymorphic.com/blog/elm-is-wrong http://reasonablypolymorphic.com/blog/elm-is-wrong I think the basic gist was that it's type-system is far from complete.
- commandertso 9y ago
  FWIW, when this was new it got a lot of pushback in a related Reddit thread. Might be worth digging in if you're seriously thinking about it.
- AlexCoventry 9y ago
  This was definitely a pain point for me when I experimented with Elm.
- 0xCMP 9y ago
  It's not that it is not complete, but not entirely as powerful as Haskell which inspires a lot of how Elm works and looks like. The creator/maintainer of elm doesn't believe they're required.
- zeptomu 9y ago
  The main critics is that it does not support type classes, but maybe that is actually not a bad thing. The discussion is similar to the never ending Go discussion about generics and people do amazing stuff with Go (now I guess critics would say they would do even more amazing stuff with generics). Not that I say type classes (or generics) are useless, but keeping a language simple (in the sense of keeping the feature list small) has benefits on its own. I did not to complicated projects in Elm, but I watch the language closely and really like what I have seen so far, so I hope Evan keeps up the good work, as I think he has pretty good taste for language design.
allochthon 9y ago
Wrapping my head around Elm took a little while. I was enjoying my progress until I attempted to abstract out some view render code into a separate module. I fought with the type system for a long time and had difficulty getting beyond an obscure compiler complaint.
danyx 9y ago
I'm actually surprised that so many teams have this view. We are a very small dev team working on scientific apps and I feel that the time it took us all to get comfortable with Elm was easily recouped by the constant development speed we had even as the app got bigger. In Javascript, projects just become harder and harder to refactor and so they accumulate cruft and development speed drops as the project ages. In Elm, with the help of a really decent type system and a helpful compile, we were able to keep going and just add features at a constant pace. I think it's worth taking a close look at Elm for this reason alone (or Purescript for that matter but there it is possible to get lost in rabbit holes of type complexity :) ).
- ng12 9y ago
  > We are a very small dev team That's the secret though, right? When you have teams of dozens of developers in a company of thousands the cost of adoption and the resistance you encounter increases exponentially. At least I can evangelize React/Redux/Typescript and get a sane development experience that's still just JavaScript.
  - firethief 9y ago
    That's an interesting claim. Can you elaborate on the superlinear factors of the cost increase?
    - mikekchar 9y ago
      I'm not entirely sure that the cost is exponential as the parent stated, but it certainly is superlinear above a certain threshold in my experience. There are a few issues you have to deal with. The first is how adoption happens. This is generally based on power structures and reputation. If you are in a position to mandate a change, the cost is potentially lower (see below, though), but if you are not then you have to influence enough people to make a change. There are many ways to do this, but I will split it into 2 for simplicity. First, you can try to influence the rest of the group directly. As the group size grows, this becomes progressively more difficult because your message is lost in the noise of other people pressing their own agendas. Once you get above certain point (say about 8-10 people), your odds of success drops to near zero. The other main way is to pilot a project and use its success to influence others. Setting up the pilot requires influencing a smaller group and therefore you have higher chances of success. The problem is that when you pilot a new way of doing things, you are intentionally breaking consensus. You now have a small group of individuals who have experience that nobody else in the group has. Whether the adoption of the new technique is successful or not, this leads to increased cost as attitudes change. The bigger the group, growing out a pilot into a larger project becomes more expensive. This is essentially the same problem as before -- you may be in a position now to mandate a way of working, but if you are not, then you have to create another round of pilots to move the idea around the group. But now you have another problem -- the implementors of the new pilots are different than the implementors of the original pilot. So you will now have more than one message coming out. You now have to harmonise that message in order to drive adoption. At every step, there is a chance of failure (sometimes quite high). The chance of failure grows as size of the group increases, because the external pressures to not change are higher. Again, there are several possible outcomes, but I will pick 2 for simplicity. You may find that your idea is rejected. You have now spent resources on your pilot that you will have to reimplement in another way. Another outcome is that your adoption is simply stalled -- you split your group permanently. This has cost implications ranging from staffing, to training, to tooling, to management, etc. Now, assuming you don't fail, you may have organically grown the adoption in your group (which is ideal), but as your group size grows, the possibility of that decreases (because the risk of failure increases based on the size of the group). More likely is that you have gotten enough reputation to be able to mandate a change. Mandating changes has costs as well. The first is that some people will be uncomfortable with the change and will quit. You now have to replace those individuals - which costs you both lost productivity, referral fees, and training costs. This is more likely as the group size increases because you are more likely to have diverse, strongly held opinions. The next biggest cost would appear to be training, retooling, etc. However, there is a hidden cost -- compliance. Very good people who dislike the change will leave. Very poor people will not leave -- they will simply refuse to follow the new strategy competently. This may be because they are depressed over the change, scared of how the change affects their influence, and many other things. These people can often end up sabotaging your projects (mostly unintentionally, but as they are usually quite upset they also don't care if they do). As the size of the group increases, the chances of building an unshiftable group of discontents grows. If you want to make a lot of money, become a consultant introducing new development techniques into large organisations like banks. It's a bit like siphoning all their operating capital into your pocket because you have no hope of success and can blame all your failure on other people.
napsterbr 9y ago
Before diving into elm, I had this fear too. But speaking from someone who never used haskell before (hell, I never used a statically typed language before), learning elm was quite simple. There's a lot of help from the compiler and the community as well. After two weeks I was quite confident on my work, and in one month I managed to create the entire architecture of our production app. Through the months I got a better grasp of elm and refactored the entire app several times (not nearly as painful as it sounds). I've made the decision to use elm and put my two frontend devs to learn it. They managed to start contributing to the app in less than a week. So if you have the chance, I think it's worth a shot. I thought I'd never learn elm, but so far my experience proved that it's much easier than it seems.
- KurtMueller 9y ago
  > Through the months I got a better grasp of elm and refactored the entire app several times (not nearly as painful as it sounds). Refactoring Elm code isn't as painful for me as Javascript or Ruby - because it's statically compiled, it gets rid of a whole class of errors. The compiler does an excellent job at where compilation fails and suggestions to fix the error. Additionally, I find in Elm (and other ML-typed languages) that it's easy to model states of your app (e.g. like a state machine) and events that change the state of your app. Adding/modifying states and events in Elm is one of its strong suits and it really forces you to logically think through how your app transitions from one state to another. Scott Wlaschin has an excellent talk on Domain Driven Design in F# that articulates this point quite well.
boubiyeah 9y ago
In my company, whenever a backend dev has to do frontend dev, it never ends well :(

0xCMP 9y ago

I like Elm a lot. I also do a lot of React and I have worried about picking Elm to avoid killing a nice product written in it because no one is willing to learn it to maintain it after I'm gone. Better to pick React to avoid any rewrites just to continue maintaining the product. However, if they could just be convinced to learn Elm I'm positive that Elm would be much easier to maintain and improve than just React by its self. React can definitely be maintained easily, but Elm does a lot of the work to check itself and also enforces discipline that React can't (although you could get a lot by just using Flow extensively and treating its errors as blockers).

mistersys 9y ago
The static types system is great, however, having used elm: elm unloads much of the work react does onto you. React automatically (with keys) manages state creation for lists and child components, but with elm you have to manage that manually. Using a component isn't simply matter of importing and using, you have to integrate its state into your component, send all it's events back to its reducer, and then map each child state to the corresponding view. You end up with lots of boilerplate.
- hathawsh 9y ago
  Would it be possible for Elm to evolve a way to let components keep internal state? The lack of component-local state is what ultimately drove me away from Elm for my last project. It seems like it should be possible, since Elm and Redux are vaguely similar and Redux can store component-local state if you need it to.
  - boubiyeah 9y ago
    I don't see this happening. local state would invalidate many things in the Elm ecosystem like the time travel debugger, all the tutorials, etc. It's not such an easy problem, you have to write a new reconciler that only renders the things that have changed instead of always rendering the entire tree. btw, redux only deal with global state but encourages the use of local (setState based) state whenever it makes sense.

zellyn 9y ago

I want to like and use Elm. However, unless things have changed recently, it seems the author hasn't learned to delegate. They also like to really get things right, which takes forever. So it's really good at what it does, but for everything else, it's just incomplete. For instance, Elm seems like a natural fit for an offline-first ServiceWorker design. But I don't think it really covers much of the just-outside-of-core-Javascript browser APIs. You're likely to run into "I have some really interesting ideas about how to cover that a super elegant way, but I'm concentrating on rewriting the $WHATEVER right now" newsgroup posts, but that's it… :-(

canadaduane 9y ago
Yes, this is a problem IMO. I dedicated 9 months to learning Elm, but left frustrated by the tight control and lack of delegation that would have leveraged my skills and many others' skills to further the idea and language.
- skybrian 9y ago
  On the other hand, it's easier to wait patiently if you're not using the language yet :-) I've been watching Elm for some time. I'll wait until it's done. So my reason for not using Elm is: I'd rather be patient.
  - KurtMueller 9y ago
    I think you're going to be waiting indefinitely then :).
boubiyeah 9y ago
The elm language/framework designer is planning 10 years ahead. At least it's ambitious! For everyone who need to write SPAs right now (or in 2 years) it's just meh.
- zellyn 9y ago
  In 10 years, the proverbial puck will have moved. Language ecosystems where the BDFL doesn't learn to delegate wither and die.

mistersys 9y ago

I've tried to use Elm and The Elm Architecture on a project before, but I gave up. The Elm Architecture makes it very easy to create small type safe components, but it forces parent components to manage the state + structure all children components. This makes it hard to use a component and to separate concerns. In order to create a list of stateful children, you must: 1. Add a list of the child states to the component state, event if the parent component doesn't care about the child's state. 2. Handle adding + removing child state's manually 3. Map all scoped child state updates through your reducer, adding a constructor to your action type 4. Finally, map each of the child state's to the component's view. You end up big types and match expressions that just manipulate lists. I have yet to see a FRP library that allows you to just use a component without introducing boilerplate.

KirinDave 9y ago
I'm curious if you've ever looked at optics-based systems for component coupling? Personally I think that the entire top-down state tree is a bad idea, but I'm willing to be convinced. I'd much prefer a modeling like the actor approach.
- jadbox 9y ago
  I've seen optics for Cycle.js but I haven't found one yet for Elm. https://github.com/staltz/cycle-onionify https://github.com/staltz/cycle-onionify
- uryga 9y ago
  > optics-based systems for component coupling Do you know of any good resources on that? Or projects using these concepts? Sounds interesting.
  - yiransheng 9y ago
    Calmm-js is one of these: https://github.com/calmm-js https://github.com/calmm-js
- colordrops 9y ago

azangru 9y ago

I am surprized Elm gets talked about so much more than Purescript. Although Purescript is more of a general-purpose language and feels like Haskell that compiles to Javascript, and Elm is something that relies on its specific runtime to work.

zem 9y ago
same reason rails got so much more mindshare than any of the competing web frameworks of its day - there is considerable value in optimising for the common case, and indeed adding constraints in the name of safety and good architecture; most languages/frameworks try to optimise for flexibility and miss out on this fact.
- KurtMueller 9y ago
  I think this is one of the main selling points about Elm - it's got conventions and it's got opinions. There's only one way to structure your app and it's the Elm way. That's a good thing when you're 1) building & growing the app - there's only way to grow and it must follow the same conventions as every other Elm app 2) bringing on developers - their main hurdle is the business logic itself and not the structure of the app 3) finding resources in the community - most everybody is traveling down the same road and can teach one another the lessons they've learned
systems 9y ago
Well, I think with so many language trying to replace javascript (purescript, coffeescript, livescript, clojurescript, bucklescript, dart, typescript .. probably there is more) It is impossible that all of them will be popular, plus more general purpose, doesnt really seem to help with popularity ... look at sql or r ... very popular, and very domain specific
deleted 9y ago
[deleted]
deleted 9y ago
[deleted]
9y ago

mrbill 9y ago

Too many products with conflicting names. I thought this was about the email client at first. http://www.instinct.org/elm/ http://www.instinct.org/elm/

ng12 9y ago
> Update 06th Jan 2000: elm 2.4 is not Y2K compliant. I'd be really surprised if it were.
- richardwhiuk 9y ago
  > Sadly, most of the information about elm on the internet is badly out of date.* The program is still being slowly developed, and the release (March 24, 1999) of elm 2.5 is promising. Awesome.
ryandrake 9y ago
No idea why you're getting down-voted. The mail client was the first thing I thought of too. Was a really confusing read until I realized it wasn't about E-mail.

eweise 9y ago

I'm using Elm for an internal customer service app and it is working out fairly well. My background is more server side programming so the ability to avoid javascript and its constantly changing ecosystem is a big plus. Elm the language is simple enough to understand in a day and the basic architecture is also straightforward. The biggest challenges are finding examples of how to architect larger apps but this example should help https://github.com/rtfeldman/elm-spa-example https://github.com/rtfeldman/elm-spa-example Also, I tried mentoring another coworker on Elm but they seemed to have a harder time than I did. I think it could be partly because they were an experienced Javascript developer who wanted to apply their existing patterns to Elm.

antouank 9y ago

Been using Elm for a few months now. Both in small side projects, and in a production app for work. Many benefits over using js, and basically no downsides apart from the initial learning curve. And even that could be equal to the learning you have to do every time your team decides to add/use a new foo.js library or framework to the project. With Elm: - you are confident about your code - others ( and your future self ) can actually read it and understand it - it pushes you to think before you write - refactoring is a breeze, not a nightmare I hope I won't have to use js on my next gig. edit: Also, I cannot speak highly enough about how helpful the compiler is, and the community in the slack channel. Makes the whole experience a joy.

ChemicalWarfare 9y ago
+1. Totally digging Elm as well. Learning curve is pretty minimal, although I've spent some time "playing around" with Haskell which helped. Love how structured things are and even though Elm is an "in progress" kind of thing - still no left-pad or js fatigue type issues (unless you really try to make them happen).
boubiyeah 9y ago
That's just dynamic vs static typing though :p
- antouank 9y ago
  You can say that. But, I also tried to learn and use OCaml and Haskell in actual projects. They are nowhere near as friendly and approachable as Elm to beginners.
  - KurtMueller 9y ago
    Elm is definitely in my future - in fact, many of the ML based languages are as well: Purescript, Haskell, F#, ReasonML, etc. Elm will be and is the gateway to all of that because it gives you only 1 path to traverse and tries to set up all the initial sign posts along the way.
  - 9y ago

arrty88 9y ago

Is it good for server side NodeJS as well?

agentultra 9y ago
Don't know about Elm, but there's Bucklescript or Reason and they generate really great, readable JS for use on Node. (And even on the front-end there's `bucklescript-tea`; a port of the Elm architecture to OCaml)
boubiyeah 9y ago
It's not designed for it. Some people do it, but it's a rough ride that need you to understand Elm's internals.
daddykotex 9y ago
Honestly, if you don't want to use JS on the server side then you should not. There are plenty of very good alternatives. I think Elm is to address the issue that JS is the only thing that runs in a browser. With that said, I suppose you could use it with Node as well.

snappyTertle 9y ago

Is there an effort to bring elm on native mobile to compete/work with react-native?

kuon 9y ago
There is https://github.com/ohanhi/elm-native-ui https://github.com/ohanhi/elm-native-ui

sandeepc24 9y ago

Also have a look at https://www.npmjs.com/package/fable-elmish https://www.npmjs.com/package/fable-elmish with F# flavor.

KurtMueller 9y ago
Do you use Fable / Fable-Elmish? If so, how do you like it?
- sandeepc24 9y ago
  I am working on a project using Fable Elmish and I am really happy with it. All I can say is give it a shot.
  - KurtMueller 9y ago
    As a side project or at work? Thanks for any info.

deleted 9y ago

[deleted]

bauerd 9y ago

Off-topic, but here I go: Has anyone tried compiling Elm's compiler (written in Haskell) to JS (with ghcjs)? Are there any other small and approachable functional languages that are in-browser compilable and provide JS interop? I'd love to hack on a small Agent Based Modelling environment for the browser, comparable to what NetLogo[1] achieves in large on the desktop. Or maybe just make it a LISP? [1] https://ccl.northwestern.edu/netlogo https://ccl.northwestern.edu/netlogo

firethief 9y ago
Since you don't seem set on a language, let me throw my hump in for OCaml. It's supports a functional style without forcing you to use it for everything; js_of_ocaml compiles OCaml's dense, high-performance bytecode to Javascript that apparently integrates well with web APIs.
sjrd 9y ago
Since you mention NetLogo, note that it has a Web version whose compiler is written in Scala.js. (The Scala.js compiler itself does not run in the browser, though.)

jshute 9y ago

Elm hasn't merged a trivial change to allow manipulation of UTC and timezones in 6 months: https://github.com/elm-lang/core/pull/739 https://github.com/elm-lang/core/pull/739 Basically, if you have to deal with local time, this isn't the language for you. If you expect to be able to add to the platform where you find it lacking, this isn't the language for you. At this point, Typescript has the momentum to make it irrelevant

zeptomu 9y ago
Typescript is a completely different language advocating different paradigms so they are not comparable. However I have to agree with you that the lack of support for local time is pretty unfortunate.
- jshute 9y ago
  I've used both heavily. I think paradigm is the key word if you're thinking mind-expanding properties. While immutable types and combinators are less used in Typescript (you've got me there) you can certainly get 80% of the value of strong typing, and there are several variants of Virtual DOM support. Elm's error messages and semantic versioning are still a class above anything else, though. Sad to see it rotting on the vine like this.
- StreamBright 9y ago
  In this thread Elm was compared to OCaml and Haskell, comaparing it to Typescript is really not that bad. :)
boubiyeah 9y ago
The roadmap priorities always baffled me too. I mean, what elm needs now to be usable is surely not code splitting... Almost no one really need that, it's a late optimisation for top sites.
- derefr 9y ago
  It makes sense if their strategy is to try to get at least one of said "top sites" to adopt them—which might, after all, result in development being sponsored or supported by full-time employees of whichever bigcorp runs the site.

rcgorton 9y ago

Elm (software): an interactive mail system Elm (physical): a tree Elm (this): "functional" software. While I do Knot No the language, any language which claims to be functional, but stateful behavior (such as network timeouts) is really not functional. AKA, pitching pretty/current buzzwords, rather than being a new/useful language. As for a "useful SPA" - a useful SPA has at least 300 gal. capacity and seating for 4+. Sigh - arbitrarily re-using names for pre-existing widgets is silly. Sort like claiming that Kleenex is actually a machine tool.

steinuil 9y ago

I think the two things Elm lacks the most right now are some form of polymorphism and some way to make parts of an Elm application manage their local state. At the moment there's only an internal API for the latter, and it's pretty ugly. I think what would be good for Elm would be to spin up a few separate Elm processes and provide an easy interface to make them communicate, sort of like in Erlang. You can do this using ports and binding them together with js right now, but it's kind of ugly.

bradknowles 9y ago

Good question. For a CLI mail client, I prefer mutt or pine. But elm isn't too bad as an alternative, if those aren't available.

Myrmornis 9y ago

The string "haskell" doesn't seem to appear in the text at all. That seems silly and rather patronizing, since it seems to be a book about a language that is heavily based on haskell, with very similar syntax. It bothers me when authors take this sort of "oh you don't need to know about that" approach.

jlebrech 9y ago

Last time i tried Elm I couldn't figure out how simply modify this clock example to move the hand quicker than every second http://elm-lang.org/examples/clock http://elm-lang.org/examples/clock

redka 9y ago
Well this isn't _that_ hard. Time.every (second / 2) Tick and to still move it the same amount: Tick newTime -> (newTime * 2, Cmd.none)
- jlebrech 9y ago
  I tried to use millisecond, but I don't it has the same interface as second.

filoeleven 9y ago

Late to the party, but someone posted in the Ableton "Get started making music" thread[0] that the components in their slick web app[1] were made with Elm. Pretty impressive. [0] https://news.ycombinator.com/item?id=14299816 https://news.ycombinator.com/item?id=14299816 [1] https://learningmusic.ableton.com/ https://learningmusic.ableton.com/

kureikain 9y ago

I really like Elm. It makes writing code so easier. At first, it's bit hard to get into the habit. But once I got paste that state(that takes 1-2 days) and get into how to write Elm, everything become so clear. I currently use Rails and this helper[1] to render an Elm component. Then I mount it like this: [2] ``` <%= elm_component('TeamPicker', {flags: { formAuthenticityToken: form_authenticity_token, domain: current.domain, teams: user.my_teams.map { |team| {id: team.id.to_s, name: team.name || ""} }, current_team: {id: current.team.id.to_s, name: current.team.name || ""} }}, {tag: 'div', class: "nav-item"}) %> ``` I think this is an easy way to get into Elm world step by step. My site is still normal HTML but I used ELM here and there for some component require interaction/multi step form etc. --- [1]: https://github.com/NotyIm/trinity/blob/master/app/helpers/elm_helper.rb https://github.com/NotyIm/trinity/blob/master/app/helpers/el... [2]: https://github.com/NotyIm/trinity/blob/master/app/views/partials/dashboard/_header.html.erb#L46-L52 https://github.com/NotyIm/trinity/blob/master/app/views/part...

pcvarmint 9y ago

I used elm for a while after mailx, but finally settled on pine. I never got used to mutt's UI. Oh, how tech names keep getting recycled!!!