37 ms·

Why I’m Leaving Elm

• passthejoe 6y ago
  That was a long, long one.
• Chris2048 6y ago
  Holy Moly. Congrats on such a concise critique; I expect it's hard to spend so much work on the thing you're leaving.
  • mercer 6y ago
    I'll second this. I've read many "why I'm leaving <x>" posts and regardless of the degree someone might agree/disagree with the contents, it's a very fair article. That's difficult to pull off, I'd say.
• francasso 6y ago
  If the post is accurate in the Technical Limitations section I wouldn't touch Elm with a 10 foot pole.
• save_ferris 6y ago
  > For example, if there is a bug in any core library, or something missing, you just have to wait for the core team to fix it, rather than being able to fix it yourself. You might need a performance fix, which can be done using Javascript but not in Elm (lack of destructive updates makes some things very hard to implement efficiently), and again you will be stuck having to explain to your boss “I know this is possible in Javascript, but we chose Elm and it makes it very hard”. Hard pass on Elm if this is true. This is an incredibly damaging accusation, is this consistent with other people's experience using Elm?
  • holtalanm 6y ago
    this is, at least, consistent with my experience using elm on a side project. Dropped elm like a hot potato when I hit that wall. frustrating, too, because I was really enjoying the language, and everything about it up to that point. The tooling support for Elm is REALLY solid compared to some other functional compile-to-js languages out there. If anyone is looking for a good functional compile-to-js language, I would suggest taking a look at ReasonML or possibly ClojureScript. Personally, I've just been using TypeScript written in a functional way, and it serves my needs at this point.
    • mercer 6y ago
      My brief experience has been similar. Elm is a dictatorship that could be wonderful if it didn't exist in the realm of messy html/js. I experience an icky feeling of stockholm-syndrome part of the time, and just plain frustration at other times when dealing with Elm. What's infuriating is that I do see the benefit of some degree of strict stewardship. It's just that it's too much in this case.
      • billman 6y ago
        I totally agree with this fustration. There seems to be some innate paradox between growing a community and being a BDFL. I think this also expresses is self in our current political environment.
        • holtalanm 6y ago
          i'm not sure if we need to be bringing politics up in a programming discussion, but hey, that's just my opinion.
          • jwalgenbach 6y ago
            This isn't a programming discussion. It's a discussion of the policies around an open source project. It's totally politics, albeit not on a national scale.
      • smoyer 6y ago
        The use of "dictatorship" in your comment brought a smile to my face because I thought of the BDFL title given to Python's creator ... and then imagined the Elm team forgot the "B" at the beginning of the acronym. Note that I have no personal experience with Elm and am in no position to take sides. The comment just describes the mental image I got from your comment's ink blot.
        • int_19h 6y ago
          Most dictators believe that they are benevolent, as does their close circle (which is then often seen as "the community", because it has the loudest voice). From the blog, it definitely sounds like this is the case for Elm.
  • hajile 6y ago
    This is one of the biggest reasons why I think ReasonML is better.
    • thethimble 6y ago
      Unfortunately ReasonML has its own set of drawbacks which don't make it a drop in replacement. These issues include standard library incompleteness, inconsistent parameter ordering conventions, and poor compiler error messages (compared to Elm).
  • geocar 6y ago
    > if this is true. It's as true as it is for Python.
  • ilaksh 6y ago
    https://github.com/Checksum/elm-compiler https://github.com/Checksum/elm-compiler I just feel like people are right that the core team is not reasonable but at the same time, if there are that many people that like Elm, why not create a total fork? It might come down to the people that would care enough to do the fork and a server or whatever have already had so much Koolaid that they just accept those negatives. And the other ones that can't accept it don't like it enough anymore to go to the trouble of making a fork. But to me it seems like the best outcome is a fork that becomes successful.
  • cttet 6y ago
    This perfectly describe the situation. While it is possible to do it yourself in Elm without the update, it is quite hard and cumbersome to do so. It is much easier to make a PR, but Elm core team is purposely relationship and personal-trust based, any random PRs will not get accepted in foreseeable future.
  • lucamug 6y ago
    We are using Elm in production for almost a year and I never had a situation where a bug was blocking us. Do you have any example?
• cfv 6y ago
  Really well reasoned parting letter. Hoping he'll fare better doing Reason instead. I've tried and haven't had much luck selling it to our local Powers That Be but I understand it's a bit of a nerdy, tough sale.
  • brodouevencode 6y ago
    Started following Luke back when he was doing a lot of Django work. He's not the type to do things "just cuz". Most of his work is well thought out and very reasoned. Big fan of the guy honestly.
• Accacin 6y ago
  Long, but I think reasoning was explained very nicely without it reading like an attack on anyone in particular. I would love to read a nice response to this, but personally I will not be looking to use Elm anytime in the future.
  • wpietri 6y ago
    Agreed. I initially groaned at the length, but I think it was necessary to make his case. This isn't the first time I've heard complaints about Elm leadership like this. And I especially appreciated his nuanced take on open-source projects and entitlement. I tend to place organizations on a spectrum from supportive to controlling. It always is a mix, of course. But open source especially should skew supportive, and this seems like just the opposite.
• beh9540 6y ago
  We had a pretty similar experience with elm around cookies. The elm-lang/cookie repo README starts with "Cookies are an ancient mistake of web browsers. They make a bunch of security problems quite easy, so consider this an expert library." However, they never address reading cookies, so if you're using a framework that does CSRF protection with cookies, you have to use ports, which adds quite a bit of complexity for something as simple as making an API request. Elm looks great on the surface, but once you start digging in you really start to realize it's "there" way or else. It's too bad, the ideas have a lot of promise, but we pivoted away quickly after running into the "core arrogance" a couple of times and went with Typescript/React/Redux.
  • frosted-flakes 6y ago
    there -> their
  • clintonb 6y ago
    I remember seeing that repo a few years ago when assessing using Elm for a project. I, also, went with Typescript and React based on that README and the issue full of folks pleading for the package to be restored.
  • deleted 6y ago
    [deleted]
  • hombre_fatal 6y ago
    Well, you should be using `httpOnly` cookies (i.e. unusable from the browser) and setting them from the server. Your browser client will automatically send them. document.cookie is a security vulnerability that's hard to find in any respectable documentation. It's up there with sql string concatenation.
    • jfkebwjsbx 6y ago
      SQL string concatenation is fine. You mean parameter concatenation (into the query string).
• antew 6y ago
  I've been working in Elm for a few years, and I feel like I can answer some of the questions. 0.19 introduced a new restriction on Native code (javascript), previously you could compile kernel code in your own projects, now you can't. You've never been able to publish a package using native code to the package site (only packages under the elm or elm-explorations github namespace can). If you feel strongly about it there are ways around it, forking the compiler, or giving your project a fake "elm/whatever" name so that the compiler will build it, there is also a set of shell scripts on github that allows you to get around the restrictions. I've used it before to make some tooling to track virtual-dom performance. The biggest miss in the post in my view is not looking more at using Custom Elements for the internationalization needs. Having a custom element where you pass in a posix time and have it formatted using the Intl APIs is very possible, and it also allows you to wrap up the interface between Elm and JS in a nice, type-safe way. The 0.19 upgrade was fairly large, but manageable. Our app was around 70k LOC when we upgraded from 0.18 to 0.19, the upgrade was fairly smooth, and it hugely improved our build times. I had actually forked the 0.18 compiler to improve build times, full builds took around 2 minutes, and incremental builds around 45 seconds. In 0.19 full builds take 4 seconds and incremental builds less than a second. I share in some of his experiences as well, I have had posts deleted on the Elm Discourse page for mentioning a way for someone to run a fork of a core package to get a fix. I stopped working on a private package manager for Elm after someone described an existing solution as a hostile attack on Elm. Overall the benefits of Elm still outweigh the downsides for me, no other language I have used has made development a joy like Elm has, refactoring is honestly fun, change whatever you want, follow the compiler errors, and at the end everything works again. Packages are generally high quality and work, an Elm package that hasn't received any updates in a year probably isn't abandoned, it's finished. Coming back to code I haven't worked on in a while is easy, the type system has my back, and most Elm code looks similar due to using the elm architecture and elm-format.
  • jfkebwjsbx 6y ago
    Side-note: "kernel" code is bad naming for JS modules.
    • maxhille 6y ago
• ar-nelson 6y ago
  I haven't used Elm, so I have no horse in this race. But I feel like I've been hearing these stories for a while, that it started out as an interesting and useful language but kept having features removed in new versions. Since it's open-source, and apparently there are existing projects in older versions of Elm that would effectively be held hostage by these feature removals, I'm amazed there hasn't been a (well-known) fork yet. Has anyone considered making a compatible fork of Elm?
  • mrunkel 6y ago
    They could call it pine.
    • hellofunk 6y ago
      Or even Mutt.
      • hellofunk 6y ago
        Well I guess that downvoter doesn't know much about email history.
    • okareaman 6y ago
      Name it Ruth so Elm and Ruth can be in relation like in the poem "Elm" by Sylvia Plath: https://www.poetryfoundation.org/poems/49003/elm https://www.poetryfoundation.org/poems/49003/elm
• EdSchouten 6y ago
  This criticism is spot on; it is exactly what I observed in late 2018, early 2019 as well. It's an awesome language, but there is basically a big case of 'vendor lock-in'. Certain compiler features are only available to the maintainers, nor is there any way to use alternative package sites. I don't want to know what would ever happen if the Elm developers decide to take https://package.elm-lang.org https://package.elm-lang.org offline. That will leave so many projects out there in an unbuildable state. Even if you saved source tarballs of the core packages, there is no way to tie it into the build yourself. The Elm compiler must load it through the official package site. I would thus personally strongly advise against using something like Elm to build any piece of software that needs to be maintained over time. It's too much of a risk.
  • razze 6y ago
    That's not correct, you can just inline any package into your vendor folder in your project. And the package website is just an index, the sources need to be on github in the first place (this has some problems too), but if the website is down, you can still grab them from github.
    • vaer-k 6y ago
      Here's the relevant section from the article for this comment. https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/#why-don-t-you-just-ing https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/#why-d...
    • dorian-graph 6y ago
      Hasn't package.elm-lang.org gone down a couple of times last year alone, which stopped people from installing/updating packages locally?
  • jeremyjh 6y ago
    > This criticism is spot on; it is exactly what I observed in late 2018, early 2019 as well. These issues were obvious much earlier than that. I looked into Elm and was excited about it initially, in either late 2013 or early 2014. Then I looked into the history of some of the design decisions that baffled me (such as lack of type classes) and concluded the project was poorly conceived and led. The leadership didn't respect the opinions or capability of its end users.
• java_script 6y ago
  Wow I never knew how much I loved typescript until reading this. Never had a blog post worth of complaints, at worst just cast to ‘any’, write a comment to recheck after the next update, and clock out at 5. And maybe pray for forgiveness from God for my code having side effects if I’m feeling guilty.
• Keats 6y ago
  The last time I looked at Elm was about ~4 years and this attitude was already showing. We hesitated building our business front-end in Elm at the time and had a general bad feeling about its future considering the various interactions we had seen. Seeing this article makes me pretty glad I didn't invest time in Elm.
  • lazersharkman 6y ago
    Same. We founded on Haskell but had some need to more front-end oriented code. Can say Elm was never considered because I was hearing this weird stuff back in 2016--not to mention it would just make hiring even harder. Can't trust tooling that will be capricious.
    • hopia 6y ago
      What did you settle on, considering you were otherwise Haskell focused?
      • lazersharkman 6y ago
        Typescript. We try not to be type/pl theory fanatics. Choose your tools well. Haskell is great since the core of our product is an interpreter/compiler with multiple stages. But I don't wanna use it everywhere. Personally I'd be using JS (or TS) + jQuery. Almost no dependencies, but a lot more manual. No one would be happy on the team if we did this of course. And it can be impractical
  • cashsterling 6y ago
    Same.. was looking at make machine control system web HMI in Elm. After some investigation into Elm's background and development team... saw too many warning signs.
• dbrgn 6y ago
  This post resonates with me. I'm not deeply involved in Elm, I just have an Elm side project (started on 0.17) with roughly 1k lines of code. Do I love Elm? Yes, definitely. It's such a well-designed language. Lots of thought went into it. It's very focused and has great (albeit sometimes non-obvious) solutions for almost everything. However, the leadership style is also what keeps me from recommending Elm to anyone wanting to create a project that cannot be simply rewritten in case Elm does a change that doesn't work for you. I wouldn't use Elm at work, since it would be a very high-risk situation. (In fact, I was faced with that decision and decided against Elm.) If you face a blocker, you're screwed. A version of Elm that is being developed in the open, where people are allowed to make suggestions, where all feedback is considered valuable, where people can experiment and explore the design space without artificial limits? Yep, I would love such a thing, and I'd happily contribute. Until that happens, I'll happily use Elm for small, personal low-risk projects. I do hope that the situation will improve once the "big rewrite" with a WASM backend is done.
  • haolez 6y ago
    This kind of leadership gave us Go. It's not necessarily bad. If everyone gets their way with the language specs, then all languages will look like a weird dialect of C++ :)
    • diggan 6y ago
      Same with Clojure, where Rich and other core contributors decide for the rest of the community what should be worked on. I think Python is/used to be the same. Name of this leadership style is BDFL (Benevolent dictator for life) and seems to work for some projects, but you always have people feeling unfairly treated by it, while others enjoy it greatly. Guess that's the effect of being a human :) https://en.wikipedia.org/wiki/Benevolent_dictator_for_life https://en.wikipedia.org/wiki/Benevolent_dictator_for_life
      • bcrosby95 6y ago
        Except those BDFLs give you escape hatches to do whatever you want. Elm removed it. It's the same as Clojure, if they didn't let you use your own Java libraries. Or if you couldn't write C extensions for Python. Rich Hickey isn't going to chastise you for resorting to a Java library if you have to, because despite Clojure being an opinionated language, at the end of the day he's pragmatic, which is why Java interop is so readily available.
• deleted 6y ago
  [deleted]
• adius 6y ago
  I‘m not sure why this hasn’t been mentioned by anyone: If you’re unhappy with Elm‘s constraints the obvious solution is to switch to PureScript (purescript.org). It’s basically are more powerful Elm like language with a great FFI and absolutely no constraints how to work with JavaScript. There are also a lot of compatibility packages to provide functions and workflows from the Elm ecosystem.
  • christiansakai 6y ago
    The learning curve to PureScript is way higher than Elm. Is that not that obvious?
    • mjepronk 6y ago
      Do you think it is harder to learn than Ocaml/ReasonML though? I think there is a good free introductory book [1], a welcoming community [2], the language and ecosystem are quite stable nowadays and there's good tooling (now that there's the Spago package manager). [1] https://leanpub.com/purescript/read https://leanpub.com/purescript/read [2] https://discourse.purescript.org/ https://discourse.purescript.org/
      • vchak1 6y ago
        It's definitely harder. I have been doing O'caml for about 20 years now, and we have probably one of the largest Elm apps out there. I looked at Purescript, especially because it also compiles to other languages (C++, BEAM) but the learning curve is a bit steep.
      • christiansakai 6y ago
        Absolutely. The 'Pure' is the problem here.
    • sli 6y ago
      Not only is it nearly as high as Haskell, the PureScript guide hasn't been updated in years and is wildly out of date. You have to go searching for an unofficial rewrite, and those are incomplete as well.
• scarfacedeb 6y ago
  Arrogant is the most accurate word to describe Elm and its leadership. I tried to use Elm in production between 0.14 and 0.18 versions and it was fun and mind expanding experience. I'm truly grateful that I've used it because it introduced a lot of functional stuff to me. But I no longer use it myself or recommend it for any serious work. Breaking changes were negligible in the beginning. But I got fed up with rewriting the app after the 3rd Elm upgrade. I think it's irresponsible to advertise the language to be used in production and break it every fucking year. Speeches about finding the perfect solution are great for academical discussions and toy languages, but you can't just remove the stuff that your community uses without offering any alternative. It all stems from the arrogance and cult-like behavior of the core team. I'm sure that they're wonderful and very smart people who do their best to create the best version of the language that they can. But their management style is too dictatorial and they don't respect their community. For me, the split started with elm formatter discussion on github. I disagreed with some of decisions that the core devs made and I wanted to see what other developers have been saying about it. On of the issues was the preference for 4-space indentations instead of 2-space. I understand that it's important to have a single source of formatting for the language. But at that time there was no consensus on what amount of spaces to use. Basically, the community divided almost 50/50 between the two. Moreover, a lot of core libraries and example code still used 2-space indentation. (that's why I preferred it). Due to lack of consensus, there was a suggestion to add a flag to formatter to set the indentation. It required to change some parts of code to pass the flag to the formatting module. At that moment, one of the core devs stepped up and closed the discussion because he didn't approve of this decision and he just said that 2-space people should adapt to the new 4-space default (that wasn't supported by any majority). It was the first time when I felt that the Elm management is too strict and I don't want to have anything to do with people with such attitude.
  • marcus_holmes 6y ago
    isn't this the exact problem that tabs solve?
    • billman 6y ago
      You might as well ask if he likes vim or emacs :)
• sullyj3 6y ago
  Wow, this is pretty damning. The author seems fairly level headed and the criticisms feel well reasoned. I've played around with elm a little bit, but this really puts a damper on my desire to dive in further. Hopefully the core team takes some of this criticism on board.
  • bjz_ 6y ago
    I've definitely found Elm worth playing around with - it's a really beautifully designed language with some really cool library design thrown in that I wish more people would learn from. That said I'd _really_ recommend steering clear of it for important stuff due to the issues described in this article.
• canadaduane 6y ago
  Has anyone started a full fork of the compiler and ecosystem? It seems like the size of the pool of the "Elm disaffected" is large enough by now that a fork of the entire project might be worthwhile. I imagine there are a lot of software engineers (like me) who at one time used Elm, but lost interest under the leadership of the core team.
  • fbonetti 6y ago
    I think people have already taken the good parts of Elm and implemented those ideas in other frameworks. Redux was inspired by the Elm, for example. I personally like using React, Redux, and Typescript. It's nowhere near the purity of Elm, but it's good enough.
• IAmEveryone 6y ago
  This mirrors my experience quite perfectly. To add another aspect: The over-management of GitHub issues is, in my experience, borderline pathological. On dozens of occasions (no exaggeration), I've experienced the following: - I notice some bug, or some missing functionality. - After dozens of searches I finally find a relevant Github issue. It's difficult to find because it's closed, in a project with a different, former name to the current version of the package, and part of a now-defunct GH organisation. - The only comment on the issue was Evan saying the issue is being folded into some meta issue bundling "issues concerning <some broad concept>". He closes the issue and adds a line into the meta issue. - Any discussion of individual items on the meta-issue is blocked - Work on that collection of issues is not going to happen "right now" because "it's so much more efficient to work on sets of related issues". - 14 months or so later, some work is done on <general concept>. The issue is closed (& locked) - My original issue obviously persists Evan seems to consider open issues as accusations or personal failures, or otherwise I can't understand why this is happening. When some recent version broke the existing support for WebSockets, the issue was immediately closed (making it, again, invisible to people experiencing this problem and searching with default options). The most constant output of Elm leadership are long-winded essays explaining how, specifically, you're stupid. You don't get to use WebSockets. We could merge this patch fixing the problem, but anyone could do that. It's just code, after all, and "Code is Easy" (https://www.youtube.com/watch?v=DSjbTC-hvqQ https://www.youtube.com/watch?v=DSjbTC-hvqQ). Have you heard about XY problems? It's a great concept that neatly explains why you are the problem, not us. I really liked Elm. I would (have) loved to see it succeed. I fully understand that small, young projects come with limitations, that it may take a long time to fix some issue, that backward-compatibility may be broken, etc. Not once have I complained about some issue, Elm or otherwise, not being fixed fast enough. And on the few occasions where I witnessed such a sense of entitlement, I called them out on it. But the defensiveness of Elm Core to whatever they perceive as hostility has somehow led directly from "benevolent dictator" to this weird kiddy version of Stalinism, where everyone is always upbeat, and "constructive", and prefacing even totally valid questions with five paragraphs of Dear-Leader praise and caveats about probably just being really stupid, lest they trigger the benevolent ego. I'm just really happy I never used Elm for work projects. I imagine trying to get something fixed when it really matters is a lot like getting ventilators to blue states these days.
• kazinator 6y ago
  I don't agree with everything here. Open source really does mean that you just have all the code to rebuild the thing from scratch under the right sort of license. Open source doesn't mean anything else, like having access to design decisions. Interaction style and personalities are also not part of the definition of open source; open source doesn't mean nobody is brusque or abrasive. Some communities have additional codes of conduct and social contracts and what not for that sort of thing. Here is a balanced viewpoint from the GNU Awk and Bash maintainers: http://www.skeeve.com/fork-my-code.html http://www.skeeve.com/fork-my-code.html Elm users who are not happy should fork the code --- everything, including the ecosystem's dependencies on an ELM internet domain --- and maybe produce something that is completely self-contained. Software that relies on "phoning home" is a risk regardless of where that is hosted and whether the people are nasty or nice. If the Elm core developers don't like it and kick people out of their project for forking, you just have to bite the bullet on that. (From the description of what that project is like, why would you care about being kicked out. Kicked out or not, your 20 line bugfix still isn't getting looked at for another two years.)
  • mooted1 6y ago
    Your suggestion for the problems with this project is "Why don't you just fork it and maintain your own?"
    • kazinator 6y ago
      That's right[1]; and the author of "Why I'm leaving Elm" understands this, yet claims that it's not possible somehow because the Elm people are hostile to it, and that's one of the reasons the project supposedly isn't really "open source". Something seems a bit off in the reasoning. The only reason you can't fork something is that either you don't have all the code, or there is a license problem. One way not to have all the code is that there is a dependency on specific SaaS server installation, whose source code isn't available. If that's the case with Elm, I missed the coverage of it in the article somehow. I did get the part that the packaging ecosystem depends on a particular server controlled by the Elm project. 1. Well, not a solution for the project, but for some of its unhappy users. The project, as such, perhaps doesn't even feel that it has these problems that require solving.
• kuon 6y ago
  I really like Elm. I don't use it now for some of the reasons pointed in the article but I like the lessons it taught me. It shows how you can do a lot of things with functional/reactive programming. Building an app in Elm can be frustrating but it can teach a lot of concepts.
• hombre_fatal 6y ago
  These posts (and HN comments) really make me wonder if adopters of fringe languages are always going to be thin-skinned developers who get emotional when they realize they won't be part of the language's design decisions. That "On Whose Authority" rant about Clojure complains about the exact same things. And I'll refer to Rich Hickey's response: https://old.reddit.com/r/Clojure/comments/73yznc/on_whose_authority/do1olag/ https://old.reddit.com/r/Clojure/comments/73yznc/on_whose_au.... Elm in particular has this weird problem where there are vocal people in the community who you can count on to drape a wet, accusatory blanket over every discussion, and you wonder why they can't just find another language that they do like. Sometimes you need to leave the theater so other people can enjoy the show. Also what are these languages yall are using where you're part of steering committee level decisions? This blog post is full of the usual suspect complaints, like being annoyed that a language can use features like custom operators but they can't in their user lib even though most people would agree that user packages shouldn't be able to invent yet more custom operators. It's such a weird jealousy for a point to be "but core libs can do it, why not me? :(". Well, simple: think of the rest of us who don't want every user lib to define its own custom operators. But the complainer here gets hung up on what seems like an ego / entitlement issue.
  • ivanbakel 6y ago
    >Well, simple: think of the rest of us who don't want every user lib to define its own custom operators. Then why not simply not use those userlibs? Now it seems you're the one draping a blanket, only yours is over a non-specific hypothetical scenario rather than a real-world problem. The reality is that people have opinions about things. You have opinions about things. People are going to try to manipulate tools they use because nobody in open-source has any significant amount of learned helplessness over software.
  • Zinggi 6y ago
    Thank you! Well put.
  • leoh 6y ago
    Thanks for posting this, it's important.
  • 6y ago
• myu701 6y ago
  The closest I've been to using elm is elmish. As a completely random internet user evaluating what proglangs to look at next, I'm staying far, far away from elm itself.
• xtian 6y ago
  As someone who spent over a year working on a production Elm app, I agree with this post 100%. Our team experienced all of these issues and more. The true cost of the approach Evan and the core team have taken is hard to measure, since what I observed most was skilled community members with the time and will to contribute silently abandoning the community after their efforts were roundly rejected or ignored. The record of these interactions tend to be scrubbed from GitHub and other community forums. There are some really great ideas in Elm, but I would never recommend it to someone as a tool for production use. It is run more like a hobby project.
  • javier2 6y ago
    I (luckily) only implemented a few smaller projects in elm around the time of 0.18 release. I started looking into how to get WebCrypto working, and was scared away by how they treated outside contributors. I liked Elm as a language, and Evan made a very good design. But to the core team, I got the message that they intend to work at their own pace, at their own leisure and will probably not take much input from outside contributors. This makes it very hard to expand the community and the usefulness of the language. They still have not afaik released anything for WebCrypto or WebWorkers. It is fine they are committed to the 100% pure language for frontend idea, but it makes it very hard to use if the Gods in the core team does not think it's fun/worthy to solve.
• type0 6y ago
  What I learned from this article: All Elm developers are equal, but some are more equal than others.
  • michaelcampbell 6y ago
    And that distinction seems to be very, very clear.
• jlokier 6y ago
  For me, the best thing I got from this critique was the link to this 2018 talk by Evan: The Hard Parts of Open Source, https://www.youtube.com/watch?v=o_4EX4dPppA https://www.youtube.com/watch?v=o_4EX4dPppA I found Evan's talking style really entertaining and enjoyable, and I totally relate to the first part about "why don't you just..." and "have you thought about delegation..."! The HN comments here are near uniformly negative towards Elm and supportive of Luke's criticisms. Fair enough, it's a reasoned critique and those are definitely issues that would affect users. I found the critique informative and useful. I don't use Elm though I've watched with passing interest for a while. Now I feel there are gotchas or expectations I should be aware of if I'm considering using it, about the way the project is heading. But I felt it came off way more entitled than I'm comfortable, mainly when Luke starts moralising, placing ethical obligations upon Evan. That came over to me as "you are obliged to do a lot more work that I want you to do, on your own time and personal cost, and to stop developing the project according to your own vision or you are a bad person".
  • hombre_fatal 6y ago
    > That came over to me as "you are obliged to do a lot more work that I want you to do, on your own time and personal cost, and to stop developing the project according to your own vision or you are a bad person". I mention this in my top-level comment, but here's Rich Hickey of Clojure responding to similar assertions: https://old.reddit.com/r/Clojure/comments/73yznc/on_whose_authority/do1olag/ https://old.reddit.com/r/Clojure/comments/73yznc/on_whose_au... > Clojure was not originally primarily a community effort, and it isn't primarily one now. That has to be ok. The presumption that everything is or ought to be a community endeavor is severely broken. A true community respects the autonomy of its participants, else it degenerates into a cult of need/want. The people who write these "I'm leaving X" posts must know they have disproportional power in such a tiny pond. Imagine writing the same post about Javascript or Java because you thought it was supposed to be a democracy or something. Nobody would even read your post.
    • a_c 6y ago
      Oh, I was knee jerked into replying this thread and didn't realised the same comment was made!
• salimmadjd 6y ago
  I believe Elm took some major missteps. Despite doing so many things right with the initial designs (and still one of the best designed front-end experiences) it never grew much beyond the early adopters and it basically remained a fun hobby language. I criticized the basic lack of communication and the infrequent updates in r/elm (I believed these infrequent updates were going to kill the momentum of Elm). I was concerned that it made the language seem stagnant. Immediately, after posting it was clear it was a major concern by others as well. So what did Evan do with that criticism? He spent the opening part of his European talk mocking it [0]. I didn’t take it personally, but it illustrated the kind of mindset Evan has. A good leader would have asked questions about why many feel that way and would have instituted a process for more frequent updates. It became clear to me, outside of being brilliant at designing Elm he is not the person to take it to the next level of adoption. If it’s not moderately adopted it won’t make sense recommending it for any production project, even if it does many things right. To me it feels like (sadly) Elm will just be a hobby project despite what it could have been. [0] https://youtu.be/uGlzRt-FYto https://youtu.be/uGlzRt-FYto
  • jaredklewis 6y ago
    I also eventually came to the conclusion that elm Will be forever niche and can’t become a mainstream language. I agree with so much of what Evan says in principle, but every time the project development style is criticized, someone pastes a link of Evan basically telling everyone to sit down, shut up, and wait. Which is Evan’s right, but rhetorically speaking, this is horrible. Just a little charm can go such a long way.
    • AlexCoventry 6y ago
      He's quite charming in person, FWIW, and he has great language design sensibility.
      • jaredklewis 6y ago
        I don't doubt it. FWIW, I was really impressed with Elm the language. But I don't see how their current messaging can possibly be working for Elm's benefit. It feels like the PL equivalent of a politician who refuses to shake hands or take selfies. I don't think it requires Elm or Evan to make any technical compromises just to be a little less off-putting.
• leshow 6y ago
  I gave up on Elm years ago. It's kind of funny, I paid for the Elm in Action book that was partially written like 6 or 7 years ago. I got an email last week that it's finally finished. It's hilarious that the book has taken this long, probably because they had to rewrite it every release.
  • michaelcampbell 6y ago
    Mostly the same for me, but a "mere" 4 years ago. Absurd.
• cultofmetatron 6y ago
  This came at an awkward time. I just bought Richard Feldman's book "Elm in Action" a few days ago and was working through the first 2 chapters. This has made me reconsider my intention use Elm in my startup. Having features randomly fail on me and having to rewrite an entire library in elm vs calling out to js means less time creating features that matter to my customers! I was drawn to elm as a way of spending less time debugging my own code in production. Part of that overall strategy means pulling in tested, working code whether it's also elm or js. Some of what I see here could easily relegate elm to being a toy language; a damn shame considering how good it is as far as strongly typed functional languages to js go.
  • olvn 6y ago
    You can call out to JS using ports and custom elements and accomplish nearly everything you could possibly need. This blog post is focusing on a largely undocumented, always discouraged "feature" (used loosely, as even from its inception it was verboten, couldn't be distributed via the official package manager, etc.) which allowed users to hack library support directly into the Elm language while risking (and losing!) many of the guarantees Elm provides. Whether it's a good fit for your startup is another question, but I just wanted to assuage that concern.
    • toastal 6y ago
      This is untrue--and I'm not entirely sure you followed the article. You can't do synchronous tasks like Intl's format for strings from floats as many locales use "," over ".". It is a pure function `Float -> String`. This should not have to go through the entire update cycle to handle receiving these kinds of value. Using ports adds async to this equation which means you need to write the ports, and handle and store all temporary values which tightly couples and makes a mess everything.
      • maxhille 6y ago
        It is now 'Locale -> Float -> String' or do I miss something?
• soamv 6y ago
  Having maintained an open source project for a while I relate to a lot of the problems brought up here. It's really really hard to create a contribution system that works well when there is a large set of users, a large set of contributors, _and_ a tricky design space. It's tempting to become authoritarian, especially when the design space is complex and you've thought about it longer than anyone else. Inclusion is a shit ton of work, and a lot of it feels non-technical and boring to most people. It's tempting to throw away compatibility and ask users to just deal with it. No project is perfect at this, but infrastructure stuff has a much higher bar for this than most other projects. That makes everything else that much harder. Most tech culture undervalues management a lot, especially in open source. But open source should be valuing it more, because the problems are so much harder than in a small co-located one-company team -- communication is lower bandwidth and higher stakes, there's no way to manage other people's schedules, there's differing goals and incentives, and on and on.
• rstarast 6y ago
  Somewhat tangential to the valid arguments here, it is possible to work around the Elm 0.19 restrictions: https://vllmrt.net/spam/subverting-elm.html https://vllmrt.net/spam/subverting-elm.html https://github.com/robx/shelm https://github.com/robx/shelm
• dzonga 6y ago
  I will forever be grateful to Elm, for introducing me to Functional programming. And the helpful community. But a lot of things could've been handled differently in that community. e.g if Elm had been made sort of the route that ReasonML is trying to go i.e a functional ML wrapper around JS. with full inter-op without the message passing madness.
• bwanab 6y ago
  After reading a large number of the responses here, I feel like I've noticed a pattern - two types of comments: 1) I've used the language and agree with the conclusions of the post even if I don't necessarily agree with every point. 2) I haven't used the language, but I believe open source projects must be maintained by their maintainers as they see fit. I actually agree with both of these positions, but, having used Elm in the past for a hobby project with an eye towards using it in production, I probably won't ever use it. I loved the original promise. Evan's ideas about the Elm Architecture are worth reading and learning for anyone. But, as many others have pointed out, if one has to maintain a project over the years, the breaking changes in the language would have caused great bouts of teeth gnashing. I don't love Java, but over the years I've come to expect that with each new major version of the language, that a small amount of work needs to be done to guarantee my production code will keep working and I can integrate new features as I have time. With Elm, every release forced me to spent hours figuring out how to make my old code work again.
  • bachmeier 6y ago
    I'm not much into web development professionally, but it's something I learn and use a bit as both a hobby and for personal projects. I looked at Elm a while back (maybe two years ago, but I'm not sure exactly). I decided against it after I ran into some issues related to language instability and old documentation. I dug a little further and it appeared to be how the Elm project was run, so I stayed away. On your second point > I haven't used the language, but I believe open source projects must be maintained by their maintainers as they see fit. I totally agree. But I also think it's good when others point out the weaknesses in the project publicly, to prevent people from wasting time or having to deal with certain personalities. As long as it's true and done in a professional manner, an important part of open source is harsh public criticism.
    • projektfu 6y ago
      For a hobbyist like me, Elm bounced around far too quickly that every time I returned to my side project it was incompatible. Worse, a library I would be using wouldn’t have made the upgrade so... that seemed OK in the first year or so but after a while you need some stability. The author is 100% right about how Elm’s package manager and repository are the only ones available and they can be really lacking sometimes.
• roebk 6y ago
  As someone who’s been watching Elm since 0.18 and writing Elm since 0.19, I’ve heard similar stories to this in the past. Elm is a great language for building frontend apps, I feel far more confident and enjoy writing code in Elm than I ever did in JavaScript / TypeScript. It also feels like Elm is becoming a little more stable and hopefully the big breaking changes of the past aren’t going to be as severe moving forward. I do wish Evan and the core team were a touch more vocal and transparent about future plans and responsive to bugs / issues. There’s a balance to strike here and it doesn’t feel like we’ve hit the sweet spot yet. I’ll still keep on writing Elm, as it still brings me happiness. I just hope issues like this don’t have an overwhelming impact of the growth of the community.
• superdisk 6y ago
  I fully agree with everything listed in this article. One point he alluded to (by mentioning the "friendly" exclamation marks) but didn't fully address is the Elm community's bizarre and infuriating language policing. You can't say the word "guys" in the Slack channel, or a bot will come and correct you, and tell you to say "folks" instead. And from then on, you'll notice the core team all use the word "folks" incessantly in their writing, it's like some weird cult. You'll notice it from the quotes of Evan and Richard in this article. The forbidden JavaScript FFI is called either "kernel modules" or "native code" despite it being neither. They also claim it's an "implementation detail" or "flaw" despite the fact that it's obviously not. There are more examples. If you go against any of these rules then you're ostracized. I quit using Elm because of this problem above all else. I recognize the need to have respectful rules for conversation but having a dialect of newspeak that you're forced to use is just too ridiculous.
  • SrslyJosh 6y ago
    > You can't say the word "guys" in the Slack channel, or a bot will come and correct you, and tell you to say "folks" instead. Being asked to use inclusive language is a weird thing to complain about, especially as the very first example you give. > And from then on, you'll notice the core team all use the word "folks" incessantly in their writing, it's like some weird cult. I use "folks" and other non-gendered language by my own choice. It's a habit I developed after self-reflection. Am I in a cult?
    • rriepe 6y ago
      What is he allowed to complain about first?
    • serf 6y ago
      >Being asked to use inclusive language is a weird thing to complain about that is, if you consider the word 'guys' as gender bound and inclusive. Female friends with myself in attendance are often referred to as 'Guys' by waitresses, waiters, and serving staff nearly anywhere I've gone. A former roommate who worked as a server at a restaurant used the word non-inclusively with the same meaning as 'Folks'. So, first get people to believe the word 'Guy' is inclusive. It's not. It's originally synonymous with 'Fellow'[0], which is also from non-inclusive origins meaning colleague, even if 'Fellow' was attached to males in the 50s and 60s common American English. >I use "folks" and other non-gendered language by my own choice. It's a habit I developed after self-reflection. Am I in a cult? Good. That's a great choice of habit. I commend you. Now, please, reconsider 'Guys', it's not as bad as the (current) common tongue might paint it. [0]: https://www.washingtonpost.com/news/volokh-conspiracy/wp/2015/05/14/the-origin-of-the-word-guy/ https://www.washingtonpost.com/news/volokh-conspiracy/wp/201...
• leoh 6y ago
  I have a hypothesis that people treat open source a little like the way that some managers and product managers treat software engineers — as dispensable, as people that shouldn't have authority or control, as people that don't know what the best is for the product. Unfortunately this isn't true. Empathetic makers — the ones that are most successful — are often deeply in touch with (a) needs of customers and (b) know what they are capable of offering. Unfortunately, what individuals offer is often not thought of as a gift (in both the open source world and in business), but rather as a given. This orientation is harmful to the human spirit, but unfortunately we have grown used to it in our world of seemingly endless commodities.
• eweise 6y ago
  Elm gets taken out behind the woodshed again on hacker news. Remind me not to open source software.
• tarkin2 6y ago
  I loved the Elm architecture even though I left it behind a couple of years ago because it developed into an explosion of files with a fairly large project. I hardly interacted with the community (although I think I remember that slack bot correcting people for using 'guys') but the architecture is both conceptually simple and great and should be emulated.
• danpalmer 6y ago
  Well done to the author for the level of self awareness in this post. It’s hard when faced with frustrating situations to remain calm and critique usefully rather than emotionally, but this was mostly well done. I hope more engineers can learn to be this self aware. I know I’m working on it.
• lolc 6y ago
  As a casual user of Elm it was interesting for me to read from someone who knows more about its development process. Unfortunately the author is frustrated by the process. And that frustration resonates with me. I've personally run up against these end-of-discussion comments that do not address the points that were raised in the thread. Obviously, the developers of Elm can choose their development style. And those who can't live with that style can fork or fuck off. Still it is sad to see people sore from conflict. The author has a lot of investment in Elm, otherwise they wouldn't have written this. When I need to decide on my involvement in Elm, I will consider how conflicts are resolved. I understand the purism of Elm, and I know it is part of why I like the language. I accept it takes unpopular decisions to keep it "pure". On the other hand, when I see people break off over limitations that the Elm project places on its users, but not on themselves (one of the main points of that article) I do get a sad feeling. What kind of relationship is this where you trust yourself with compiler features you don't allow other people to handle? Words like patronizing, controlling, and self-serving come to mind. They may have the best of intentions and my protection in mind, but I prefer the privilege to know I can shoot both my feet if I need to.
• savanaly 6y ago
  Elm wasn't the right language/community for this author and that's ok, not everything is for everyone. I use and love elm as something to write my side projects in. It has a zen like appeal for many reasons: - No runtime exceptions in practice, so you are developing against the compiler and almost never need to manually test what you're writing - Very opinionated about how to do most things. There's usually just one good library to solve a problem and it solves it in a particular way. What you lose in the process of trying to solve your problem in a way that's not optimal for you, you gain in not having to search for the optimal solution. - Little politics or debate about the language itself. This does make it like a cult, that's a fair comparison. Doesn't hurt my enjoyment of it though :) - Tooling is pretty good, with helpful linters, stylers and plugins for vs code, vim and so on that the relatively small community has standardized on. - Very active community on their Slack, I get considerable help on all problems from syntax to architectural at all hours of the day from certain tireless people on there. I do my part to help as well, I try to help the ultra-newbies now that I'm not one anymore. I think the type of engineers who "think big" and want to do very ambitious things that would require them to have input on the direction of the language will not be happy in Elm, so I'm never surprised by the posts like this that are quite frequent. HN is especially full of these type so be cautious if this note is applicable. I also don't think I would recommend Elm as the solution to my 2k+ engineer company even though it's my favorite language. There's just too much at stake at that point to take a chance that the Elm process will screw you. But for small projects, maybe under 50 people? I think it can be a very strong candidate.
  • ng12 6y ago
    > There's usually just one good library to solve a problem and it solves it in a particular way. Isn't this the author's core contention? He really needed an i18n library but wasn't allowed(?) to implement it himself and the Elm team wasn't inclined to provide one.
    • savanaly 6y ago
      Yeah, that's unfortunate. I haven't run up against anything like that and maybe if I did I would share his viewpoint.
• mcguire 6y ago
  Is it just me or does the Elm development style resemble that of Go?
  • int_19h 6y ago
    It's not just you. There's definitely a similar "we know how to do everything better, which means differently" vibe here, and a similar penchant for rewriting everything to minimize library dependencies outside of the ecosystem. But with Go, at least it's the community as a whole making the decision to be like that - people might shy away from cgo, for example, but it's a convention, not a hard limitation. And if you do decide to use Go in your app, you still get to choose how much or little of it there will be. With Elm, it seems that there isn't any community consensus along these lines, or even a community in the same sense (i.e. that can establish a consensus that would be meaningful). It's practically a religion - you get the rules delivered to you on stone tablets, and you're either all in or all out. Except in this religion, there are new stone tablets every couple of years. It might be an overly uncharitable comparison, but I can't help but remember https://wiki.lspace.org/mediawiki/Abominations_Unto_Nuggan https://wiki.lspace.org/mediawiki/Abominations_Unto_Nuggan. Especially "Abomination 6543: Umbrellas or any other Devices that shield the wearer from the Blessings of Nature", in the context of native/kernel code.
• GiorgioG 6y ago
  Elm has a bus-factor of 1. https://github.com/elm/compiler/graphs/contributors https://github.com/elm/compiler/graphs/contributors I feel quite uncomfortable hitching my wagon to a single developer who owes me nothing.
  • hashbig 6y ago
    Evan response to the bus-factor: https://youtu.be/uGlzRt-FYto?t=508 https://youtu.be/uGlzRt-FYto?t=508
    • jdbernard 6y ago
      From that video: I have a feeling that the answer to the question is like, "What if so-and-so was hit by a bus?" It's like, "It'd be bad." I think that's the general answer but it's something people worry about. That's... confidence inspiring.
  • ggregoire 6y ago
    Why are the most recent commits about implementing an endpoint to receive donations for his foundation? Why would you want that in a compiler?
    • GiorgioG 6y ago
      I took a look at Elm a couple of years ago and while I was intrigued I simply couldn't consider using Elm in any serious endeavor. Not because it isn't capable, but because the risk of it dying if/when Evan stops working on it (for any myriad of reasons.) Yes someone could fork it, but that doesn't ensure it would continue to be well-supported. Remember RethinkDB? When they shut down, the software was open-sourced to much fan-fare, but for all intents and purposes it appears progress has come to a screeching halt: https://github.com/rethinkdb/rethinkdb/graphs/contributors https://github.com/rethinkdb/rethinkdb/graphs/contributors Elm is unfit for any commercial software project IMO as long as it remains a one-man show. I (like everyone else) have limited amount of time to learn new tech, and despite Elm's technical merits - it's not worth sinking any time/effort into it at this time when other more viable options exist.
• samtechie 6y ago
  Maybe am mistaken but isn't a language that hasn't reached version 1 by its nature supposed to have breaking changes. It is expected that while you can use the language for your projects there is no guarantee that new additions won't break your code so you use it at your own risk unless Elm uses a different versioning system.
• olvn 6y ago
  I've used Elm professionally for about a year, having done full rewrites of both a bloated React/Redux SPA and a map data visualizer with complex JS interop using ports to Leaflet, AWS Cognito, etc. Luke Plant's blog post doesn't at all reflect my experiences with Elm or my feelings about the core team. For those not privy to the Elm tea, a brief primer: this blog post is primarily concerning a months-old issue regarding the removal of the ability to use native modules, which are effectively patches to the Elm runtime[1] which circumvent the core features of the language that provide its greatest strengths: a genuinely helpful compiler and ironclad runtime guarantees (still have yet to encounter a production runtime error that wasn't on the JavaScript side of things!) This "feature" (used loosely) was largely undocumented, always verboten from distribution in user packages, and never intended as anything more than a stopgap measure in extremely rare cases.[2] It was /officially/ not a core language feature intended for widespread usage, and consistently advised against by the Elm team. The removal of native modules was spoken about publicly months before the breaking upgrade. It came as no surprise to me. As an engineer who tries really hard to be responsible, I do not build software which relies on features which are advertised as 'do not use unless absolutely necessary' and are soon-to-be deprecated unless I'm willing to accept the inherent risk of doing so. The core Elm team was, in my opinion, extremely communicative, well-reasoned, and thoughtful in this change and in others, despite the inconvenience to a small subset of people. For each feature discussed in Luke's post, there is an accompanying Discourse thread[3], discussion on Google groups, Github gists[4], etc., that carefully lays out the reasoning, and carefully consider the scope of a change (in the instance of the removal of custom operators, the Elm team analyzed the package ecosystem and determined less than 5% of packages were affected)[4]. I won't cover the moral arguments around the obligations of open source maintainers as this has been covered ad nauseam with the Clojure and Rust fiascos of a similar sort - though I personally believe maintainers don't owe anyone anything, and I try to treat all free software graciously, as a precious gift, lucky to receive it at all. I will say that Elm's somewhat slow, closed BDFL-ish governance is well-documented as well[5, 6], available to all who seek to understand the Elm development process and decide for themselves if this is an ecosystem to hitch their wagon to. Of course the Elm maintainers get to patch their own runtime with native modules, because they are implementing core parts of the language, it's practically tautological. That users living in userland cannot do it is not unfair; it's a language design feature. What Luke seems to see as a stifling of an open community by the closure of issues and deletion of posts on the Discourse is often basic organizational maintenance to handle redundancies. Conversations around these issues have happened for months and in some cases years, and decisions have been made. They may not be to everyone's tastes. That should be just fine! If someone went to Famous Amos Cookies on Discourse, Slack, their mailing list, and opened a Github issue and PR suggesting this genius idea they just had, it's so good, wait for it - an oatmeal cookie without raisins! - I hope they would clean it up, close the issue, delete my posts, etc., for their own sanity. Not to mention that the opening to Luke's opus here is an admission of his own rudeness to the Elm team on most of these fora. Of course the relationship with maintainers will be strained with this kind of behavior. There are critiques of Elm, to be sure. The pace of releases is somewhat slow, custom operators might be nice for 3rd party parsing libraries, it might be cool to have a PR merged in to get that fuzzy feeling only OSS contributors get. But you cannot reasonably argue that Elm's team has been unfair, discriminatory, uncommunicative, or arrogant (pathos, so much pathos here!). I don't generally post comments anywhere, but articles like this are irresponsible and damaging not just to the well-being of maintainers who are being generous with their time trying to make something with great care, but to people (like many top level commenters here) who might have tried Elm but won't due to an inside baseball post from a spurned developer. It makes me actually sad, like want-to-cry sad. [1] https://newfivefour.com/elm-lang-basic-native-module.html https://newfivefour.com/elm-lang-basic-native-module.html (any somewhat experienced Elm developer will get nervous looking at this trivial example and immediately see what might break) [2] https://groups.google.com/forum/#!msg/elm-dev/1JW6wknkDIo/H9ZnS71BCAAJ https://groups.google.com/forum/#!msg/elm-dev/1JW6wknkDIo/H9... (2015!) [3] https://discourse.elm-lang.org/t/native-code-in-0-19/826 https://discourse.elm-lang.org/t/native-code-in-0-19/826 [4] https://gist.github.com/evancz/769bba8abb9ddc3bf81d69fa80cc76b1 https://gist.github.com/evancz/769bba8abb9ddc3bf81d69fa80cc7... [5] https://www.youtube.com/watch?v=o_4EX4dPppA https://www.youtube.com/watch?v=o_4EX4dPppA [6] https://github.com/elm/projects/blob/master/roadmap.md https://github.com/elm/projects/blob/master/roadmap.md
• novok 6y ago
  When I researched elm a few years ago, I pretty much came to the same conclusions that the author came about the hard way. 1. The native / non-native split and coming hard deprecation of native, although makes sense from a 'code purity of the ecosystem' perspective, will ultimately be a huge hindrance in practice. 2. Elm specifically puts it's author as the single point of failure, decision making and design, because he wants to make sure the language features are designed right by sacrificing development multithreading. 3. Because of the 2 decisions above, forces elm to effectively be a research / toy language, who's ideas we benefit from the ideas showing up in other languages. Such as elm's error messages probably inspiring rust and swift to improve their error messages. You can't rely on elm as a business. 4. Elm might of been better off not using the browser as it's runtime environment in the end because of the above 3 issues and how bad javascript is and went straight for a flutter or squeak style of implementation setup, which doesn't cause as many 'temptations of native' kinds of issues.
• mrozbarry 6y ago
  Original author of the elm-firebase ( https://github.com/pairshaped/elm-firebase https://github.com/pairshaped/elm-firebase ) here. While I think Elm certainly has some rough patches in both their aggressively PC community and the immaturity of the language (still many breaking changes, not 1.x, etc.), it's not that awful. I was told that elm-firebase was basically a waste, and don't use native modules, so I stopped development. I didn't need to make a big stink, and write a huge blog post on why I'm leaving Elm and how the community is toxic. If the author needs to leave the community, then do it, but no one needs to leave a community with so much drama.
  • bmurphy1976 6y ago
    That's what many people (myself included) have done. Unfortunately by not sharing our experiences, others will have to learn things the hard way. If Evan is entitled to run Elm however he wants, Luke is entitled to post whatever criticism he wants on his own blog. If nobody ever speaks up, do you think things will actually ever get better?
    • mrozbarry 6y ago
      To be clear, I don't have a problem with Luke posting his experience, but there's a difference between reporting the news and reporting your feelings. I think about half that article could be deleted, and it would still hold content of "why I'm leaving," but without building this huge drama oriented narrative.
      • hitekker 6y ago
        > without building this huge drama oriented narrative. One person's distress is another person's "drama", I suppose.
      • dorian-graph 6y ago
        As much as we can pretend that feelings aren't involved in software engineering, it will never be true, especially when relationships is the currency
      • 6y ago
• deleted 6y ago
  [deleted]
• ghthor 6y ago
  I'd be interested to see why the author would be unable to use the ports interface to work with the API of his package. My understanding about why the core team is being so controlling over the native modules access is that they're trying to prove that each native module is pure, so they can make assumptions and declarations in the compiler that the code produced is pure. By forcing unblessed/unreviewed modules to use the ports interface they can maintain this assumption. Without doing this you lose all of that assumption and your compiler falls apart, if it's based on that assumption.
  • sonofaplum 6y ago
    The author gives more specifics in the footnotes, specifically footnote #4 https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/#id14 https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/#id14
• tmcw 6y ago
  I've used Elm on a few projects - most recently oldfashioned.tech - and it's a lovely language. I read this article expecting the word 'ethical' to eventually point to something and it never did. The author wanted a different language, shouted at a bunch of people for not agreeing with him, those people correctly wrote him off as a productive member of the community, and then he wrote a long blog post about how he can't see their side of the argument. Indeed, he should use a language that aligns with his preferences. Extrapolating from his experience into this right vs. wrong narrative doesn't actually work. Even after his explicitly acknowledged troll-like behavior, he didn't get some expletive-laden response from the project maintainers. He wasn't banned from the repos. At no point does he substantiate the idea of the leadership style being 'threatening.' On the other hand, there are plenty of communities with actual threatening, abusive behavior in plain view, that everyone's aware of. There are plenty of communities that "well actually" every forum post instead of being helpful. Elm isn't one of those.
• praveenperera 6y ago
  I used Elm in 0.18. I actively campaigned for its use. After 0.19, I actively campaign against it. Back when I chose Elm, ReasonML and ReasonReact was not around. That is what I would choose instead now. I am currently stuck with an Elm 0.18 app that I'll need to convert to React or bucklescript-tea. Elm's leadership and as a result the community around it is super arrogant and toxic.
• mwfunk 6y ago
  This is a ton of emotionally charged verbiage about community interactions here, but at any point does this person say what they were using Elm to do? That seems like a pretty important point. Is this somebody who was just using the language recreationally, for their own amusement? And if so, did they have some expectation for the language community to be a source of (online) social interactions and connections with people? Because if so, that really changes the significance of the accusations, in the sense that it makes them almost meaningless. "I wanted Elm to be my new life and my new friends and I wanted to shape it myself as a personal milestone but that stuff didn't happen and now I'm mad and I'm leaving" is a heck of a lot less meaningful to me than, "this language doesn't work well for the problems I'm trying to solve, and the maintainers aren't interested in adapting it to my problem domain, so I'm going to move on to some other language for this thing I'm working on". I really don't care if someone is pissed that a language development community didn't make someone feel like they belonged to a social club or otherwise interacted with him in a way that satisfied some void inside of him. But if there was some actual purpose to his language noodling, as opposed to being purely recreational, it would be infinitely more interesting to know about how it fell short of the purpose, why the language fell short, why the maintainers didn't want to evolve it in that direction, and what language the author is moving to for their project that does a better job, and why they chose that language. That's meaningful. Anything related to whether or not they felt listened to or if they felt like they were on the inside or the outside is just utterly meaningless, it's like when people complain about news articles that don't have anonymous comment sections. I realize that to a lot of people, the recreational community aspects of open source development are literally the only thing they care about. But I also realize that to some of those people, they don't understand that this is not the primary purpose of hardly any of the projects they care about, language projects probably least of all. Open source maintainers are not obligated to anybody to create a fun community for recreational users, with a well-lined pathway to becoming a recreational core developer. But that is clearly all that this person cared about, hence all of the emotional stuff which I just don't get. I'm not saying it's invalid, I just don't personally relate to that perspective at all.
  • rcxdude 6y ago
    I mean, he goes into some detail about the issue: he wants to be able to use an internationalisation library, but the best option is in javascript, and these libraries are very hard to write because i18n is really hard with a bunch of edge cases. He also gives evidence that some commercial apps using Elm really need this functionality. He wrote bindings so it could be used in Elm, it worked well, but the core team were not interested in his solution, seemed to misunderstand the problem, and will not allow anyone else to solve it without an outright fork (which the core team act extremely hostile towards).
• tobyhede 6y ago
  I find it fascinating that the author is leaving one fringe language with a small community for another fringe language with a small community- in this case Bucklescript. I've never found the productivity benefits of these JS alternatives worth the risk and cost. There is an understandable desire to move away from the messy reality of JS and it's browser friends, I get it. Having written many thousands of lines of CoffeeScript, experiments with ClojureScript and Elm, I see the appeal. But you can easily find yourself stranded. Following the herd is important if you want to hire and maintain projects for the long term.
  • hombre_fatal 6y ago
    The upsides make more sense if your Webpack/JS tool chain was growing out of hand. For example, once you take on Typescript, you take on quite a bit of idiosyncrasies. And your Webpack config may grow pretty large over time. We have some hacks in our Webpack config just to avoid some thing like double ESLint/TS evaluation. And it all can start to feel quite precarious. We even found bugs in Webpack's circular dependency plugin. Meanwhile, Elm does a lot of this right out of the box. There's a point where you may be easily reducing complexity and idiosyncrasies by using a tool like Elm.
    • tobyhede 6y ago
      I agree that opionated frameworks can reduce complexity. I was Rails for a very long time. But moving to a new language that you can't hire for seems like an extreme reaction to "our config is complex". One good thing about a mainline technology like TS is that thinga get attention. Manual config today may be supported feature in the future.
      • bravura 6y ago
        Isn't the real risk, in moving to a fringe frontend framework, not just that you can't hire, but that you run into some roadblock you just can't get around? That you have some abstraction leak or messy interactions with JS?
• popara 6y ago
  When I decided to commit my project to Elm, back in 2017, I have seen all those writings on the wall. Basically I am buying in someone's whim. One caveat is that I can stop following his whim, freeze source code that I need and carry on my development with out needing or caring about future releases, ie, I do the dreadful fork. I work alone so I choose my tech destiny. But when you look at the guy at which will you are submitting to, and can't but say he is the everything I want from a COMPILER MASTER. He have designed clean and well working language and ecosystem around it. This is the ecosystem where you are not afraid that one of library's dependencies might install crypto miner or steal your user data. You are sure with like 99.99999....% that you won't have errors in runtime. And language is simple, my wife started writing it, you only need to know to structure the code and all the frontend power is to you. Ad hominem - also Evan is soft spoken guy that cares about his life's work, and sharing it with others. Ad hominem on my side - I am sick of ALGOL languages. After 12 years of proffesional work with many different languages, touching JS or anything related gave me head aches, such inherently stupid and inefficient ways of building systems, from syntax to /ways of doing things/ and making sure they are /allright/. Luke may have different ambitions than me, I wanted to build reliable systems that brought me money, for me, after 3 years of Elm, I am happy as I can be. I build new features with confidence and speed. It took me 3 days of work to switch to 0.19. I have deleted big chunks of JS that I though were necessary in order for my app to work. But I was wrong, there were pure way to do it. That was rewarding mental exercise for me, after which I had cleaner code, and customers noticed performance improvements. Can language /be better/? Yes. Is Elm at the point where think it desperately needs some improvement, because of which my work is blocked or stalled? No. It wasn't like that since 0.19. Luke is off and rude in this post at least. He is considered about the posture of OSS not the real benefits of it. Why Luke didn't came up with big blog post about the features he would like to see in Elm? Much more constructive than bitching about it.
  • rcxdude 6y ago
    > Luke is off and rude in this post at least. He is considered about the posture of OSS not the real benefits of it. Why Luke didn't came up with big blog post about the features he would like to see in Elm? Much more constructive than bitching about it. Sounds like he has done a lot of talking about features he would like to see (as well as work to realise them), and gotten nothing but dismissal and inaction for it. I think this blog post is probably the most constructive thing left he could do.
• Myrmornis 6y ago
  After reading that I’m fairly clear in my mind that Elm is something I will avoid if possible. The author seems extremely credible to me and several of the quotes entirely damning. For example, the one where the core team / leader ended a communication by saying that they weren’t interested in hearing alternative views but that they did want feedback on whether their communication was clear. I cannot imagine that behind those words lie people I would want to work with.
• tolmasky 6y ago
  Although the particulars are unique, this seems to be another problem stemming from what I like to call "Having Your Open Source and Eating It Too Syndrome". Namely, it seems to me that the authors don't actually want an Open Source project (or perhaps more accurately a Production-Ready Open Source Project). They may certainly want many of the advantages that Open Source brings, but are upset by what I think are honestly completely predictable consequences from not living up to the, regrettably for lack of a better word, "responsibilities" of Production Open Source. I say regrettably because I don't want to get into an argument about what is actually "owed" -- I agree no one entered any contract or whatever. All I'm saying is if you put in the work to convince someone that something is production-ready, and convinced them to stake their livelihood on your project, then it shouldn't be surprising that they are upset when you prioritize abstract principles or decisions over their ability to ship. Again, I'm not implying you should be forced to have a process or do what they say, just don't be surprised when your users get upset, and then on top of that accuse them of "entitlement". There's a lot of convenient, and perhaps subconscious, confusion of terminology in technology. For example, people can point to the fact that a project isn't 1.0 yet and argue "well you should have known anything goes pre-1.0". But Linux was amazingly solid prior to 1.0, and even the term "Beta" has been watered down by Google's infamous insistence of using the term for ages on their software. I'm not saying you have to agree with the watering down of technical meaning, but you should understand the unfortunate reality that a lot of this is mixed signaling. For example, a common one is "It's beta but we use it in production and it works great!", which if you break it down is kind of a used-car-salesman technique. It's saying "I've created plausible deniability for myself so that I owe you nothing, but the final thought I'm going to leave you with is an emotionally manipulative statement that wink wink it's really ready to go". Similarly, if you have a fancy landing page telling people why your product is better than other production-ready products, for example Elm compares itself against Angular, React, and Ember, then you are strongly implying you are a peer. So even though the words "production-ready" don't appear on the page, there is a strong implication here. There's certainly no asterisk anywhere saying "pre-shipping numbers", something that game trailers will even do. Again, I don't think this is intentionally deceitful, I think it's supremely easy to accidentally run into this sort of messaging. But you should absolutely be mindful of this and work against this. Luckily, this is all fairly avoidable if you're willing to take some simple steps. For example, just say "this is a toy project" or at least "We absolutely do not recommend this for production", or even "the primary purpose of this project is for researching ideas that interest me". That can completely avoid any miscommunication and sets expectations up correctly, and furthermore puts you 100% in the right in the event that someone ends up relying on your code... But no one wants to do that because it hurts adoption! This is what I mean by wanting to "Having Your Open Source and Eating It Too". You want to portray an amazing product that does everything well AND is a happy community, while reserving the right to treat it like a side project whenever you want.
• OOPMan 6y ago
  No offense to anyone here contributing to Elm, but the project sounds like it's a dumpster fire based on the linker post.
• quercus 6y ago
  This sort of thing is why I stopped open sourcing my work (I had several successful open source projects a decade ago). I realized that it was the responsibility of an open source maintainer to put the community first, but I was only interested in strictly pursuing my own interests. Neither side was wrong, I just realized I wasn't cut out to be a maintainer. Maybe Evan should also consider if he's cut out for the job.
• xupybd 6y ago
  Evan is brilliant, Elm even more so. There are trade offs that they are making that I totally understand. There is one way to do things. There is one path to fix things. Everything works one way and works incredibly well. But those trade offs come at a cost. It is very hard to take Elm into production having to put all of your trust in Evan and the few in his company. There are going to be times that your bugs are not considered bugs by the core team. There are going to be times when your required features are considered harmful to Elm by the core team. Other projects allow you the freedom to work around those sorts of things. Elm has tightened things so this is very hard to do. Elm has made huge wins by doing that. But it makes Elm in production a much harder sell. I love Elm I want to use it production. But I don't want to have to front to my manager trying to explain we can't do X because I picked a technology that met my needs as a developer but not failed to meet the needs of the business. Evan has every right to build Elm as he sees fit but it's painful to sit here as a dev and see something so perfect yet have to go for something so terrible for commercial considerations.
  • chase-sequence 6y ago
    I cannot understand how one could call something "so perfect" if it cannot be feasibly considered for use in production. How can something perfect come with so many drawbacks and warnings?
    • xupybd 6y ago
      Please forgive my hyperbole. Elm achieves simplicity and reliability by having it's entire eco system locked down. But it turns out the same things that make it a brilliant developer experience make it unusable in production. I suspect I can and might use it in production but if I do I will be putting a lot of trust in one guy. No one else can really take over.
• throwaway17_17 6y ago
  I don’t use Elm. But I have watched several of the founder’s talks about different subjects. That is to say, I have a half decent idea as to what the ‘native modules’ issue means. I think Luke’s issue is that under the newest release Elm is requiring that no code contain any ‘raw’ JS or it won’t compile. It seems like this was an option prior to the current version so is this basically like if the Rust team said as of the new release no code, other than that code coming from the Rust team may use ‘unsafe’? — This is an honest question I’ve been holding in all afternoon, and seeing this still on the front page, I just decided to ask.
  • ta20200202 6y ago
    > issue is that under the newest release Elm is requiring that no code contain any ‘raw’ JS or it won’t compile. It seems like this was an option prior to the current version so is this basically like if the Rust team said as of the new release no code, other than that code coming from the Rust team may use ‘unsafe’? Yes, the problem is similar. It can be considered worse, because in safe Rust you can do almost everything, but Elm is much more limited. You can still use regular JavaScript with ports, but it is more complicated. It is something like a WebSocket channel, where the server is the JavaScript code.
• okareaman 6y ago
  I knew nothing about Elm or Luke or Evan before this, but I'm always curious about social relationships in the developer community. That said, I read Luke's article, then watched Evan's video "What is Success?" then I went back and read a couple more of Luke's articles. I am reminded of "Scala War Stories with Paul Phillips," which to me is kind of a classic of the genre of a great developer with huge passion and incredible work ethic almost driven to a nervous breakdown. https://www.youtube.com/watch?v=v1wrWQcqLpo https://www.youtube.com/watch?v=v1wrWQcqLpo I was really impressed with Evan's thought process. I liked his thoughts and feelings about design simplicity and getting it right. I was also really impressed with Luke. He has a practical bent I appreciate and was really excited about his i18n solution, rightly so...and then the clash... I'm really sad about this. There are no winners here. No one is wrong. It's a loss all around. I'm sorry.
• frozenlettuce 6y ago
  Besides being much more elegant, Elm's tooling is very limited when compared to JavaScript and React. When working with the js+react+redux combo, you have access to specialized browser extensions that allow exploring the application structure and events. It's sad because the language precedes Redux, but the centralization from its owner made it lose the boat. The fact that the Elm blog has a new post only once a year does not help, either.
• toastal 6y ago
  I'm mentioned in the article. I had nearly the exact same experience as the author from a different side of the planet -- and we even overlapped on i18n/l10n issues. I actually raised some of these issues in a blog/Reddit post from a rewrite I did in 2016, where this was one of the biggest pain-points (back when native code was cryptic but legal). After that thread was closed without real answers or a way to reply, I stopped participating in any meaningful way to the community and did all side projects in something else. I've been afraid to even ask the community for any sort of assistance because of the hostility I've encountered for suggesting something was wrong or incomplete. You can see in the authors constant preapologies in the article that he's really afraid of the tact chosen for this so he doesn't get any flack to put him in even worse standings with community; this is absurd, and it's the reason it needed to be aired out in a long blog post after bottling frustrations. I've switched jobs since, but we've discussed migrating from Elm to PureScript for the last like year without having a big enough reason to pull the trigger, but maybe this would be a good time since it seems a lot of people are frustrated in the community and I've had to come up with a few too many 'clever' solutions to get around limitations. I think Elm is the best playground to learn functional programming, but I wouldn't recommend it to anyone for anything other than a learning opportunity or a narrowly-scoped weekend SPA project.
• lewisjoe 6y ago
  When a technology wraps over another technology with its own opinions - doesn't it always end up bad? Especially when the wrapper decides to take away the escape hatches, locking people into its opinions without considering genuinely valid exemptions. I wonder how so many truly bright minds, bought into this philosophy, despite knowing this was coming. I guess the promise of Elm was just far too convincing.
• the_gipsy 6y ago
  This is a very emotional piece. While a lot of his points are true from some perspective, they seem to come from an expectation that Elm should be treated the same as enterprise languages or frameworks, whose ultimate goal is to "get traction and adoption" as success measure. I have used Elm in a hobby project, a multiplayer web game, which I have been developing over 4 years now. Elm has been a complete joy. New features and refactors are done incredibly fast AND safe. I believe this is due to Elm's restrictions letting no unsafe code "in".
• alephu5 6y ago
  Seems like two different discussions going on here, on the one hand you have core language design such as not having typeclasses, and it's fair to say it's the core team's prerogative to organise these decisions as they want. On the other hand there's no good argument for intentionally restricting language features from certain users, it's not in anyone's interest. I am a big fan of safe languages that use a formalism to stop you _accidentally_ modifying shared state or hitting a runtime error but why should the designers care about me making a bad architectural design, i.e. including some JavaScript modules in an elm package? If I misuse it and write a bad application that's my problem, you can't protect bad developers from themselves because they'll just use other tools. If I publish a library with JavaScript, okay show a warning to the user, have red scary text on the package description page if you want. But let the users decide how they want to build their applications. The argument that this would block a clear path to WASM is bogus, they've already shown that breaking tons of libraries doesn't bother them.
• auggierose 6y ago
  Just bought the book Elm in Action. If people are so frustrated about the leadership, but still say it is a great language, it definitely is worth checking it out.
• socialist 6y ago
  If it all ends up generating Javascript, why don't people learn to write good Javascript. Rather than compound problems with unnecessary incompetence and calling it functional and typed. The only thing typed I discovered is undefined incompetence from Elm to C++. There is always an excuse to complicate problems when you are incompetent and invent useless languages.
• jlokier 6y ago
  I've just realised that by the understanding of "Open Source" assumed by Luke and by many of the commenters here: - Firefox isn't Open Source. - Lots of other things often held up as shining examples of Open Source are not Open Source. ...because they are worked on by people or teams who decide their own design goals and roadmap, and while you can contribute and talk about the project, many users feel the project moves on without catering to their needs or remaining compatible over time. Firefox is an interesting example, not only because it's a poster child for Open Source, but because it evolved from Netscape Navigator's source release and is associated with events when the "Open Source" term was being coined.
• jaeming 6y ago
  I literally just started learning Elm this week and then I find there's all this drama and baggage to consider. It's seems like 0.18 to 0.19 was a divisive upgrade for the community. I feel like a lot of good languages or frameworks go through this existential crisis at some point. There was Python 2 to 3, or Angular 1 to 2, Node vs IO, etc.. I think Vue narrowly avoided it on it way towards 3.0 (maybe remains to be seen). I remember when Rails community split when Yehuda Katz got frustrated with DHH and made Merb, and then they merged back together for Rails 3. It seems like open source has a love/hate relationship with the benevolent dictatorship model.
• gdotdesign 6y ago
  I've invested a lot of time in Elm about two-to-three years ago, the two main things was elm-ui [1] and elm-github-install [2]. At the time elm-ui was impossible to build without "native code" so I used it and built elm-github-install to make it work. Suffice to say, I've run into the exact same issues as the author. Had they allowed me to contribute in a meaningful way Elm now would have a nice UI library and probably a much nicer package website which I've developed as well [3] (no longer running, but I've turned maintenance mode off for a few days so you can take a look). I stopped using and contributing to Elm when 0.19 came out. If you are interested how much effort I put in just check the Elm related repositories in my Github profile [4]. After that I missed the developer experience and I created Mint [5], so in the end some of knowledge I gathered during that time have been put to good use :) I just can't understand how they could ignore all the work I've put in, if someone would invest that much time and effort into Mint (or any open source project of mine) I would welcome it and or at least start a dialog on how we could integrate their work into the language. Anyway, I thought I share my Elm story with you (although probably a bit late :)) Cheers [1] https://github.com/gdotdesign/elm-ui https://github.com/gdotdesign/elm-ui [2] https://github.com/gdotdesign/elm-github-install https://github.com/gdotdesign/elm-github-install [3] http://elm-directory.herokuapp.com/ http://elm-directory.herokuapp.com/ https://github.com/gdotdesign/elm-directory https://github.com/gdotdesign/elm-directory [4] https://github.com/gdotdesign?tab=repositories&q=elm-&type=source&language= https://github.com/gdotdesign?tab=repositories&q=elm-&type=s... [5] https://www.mint-lang.com/ https://www.mint-lang.com/ https://github.com/mint-lang/mint https://github.com/mint-lang/mint
  • emerongi 6y ago
    Mint looks cool! Maybe this is answered somewhere, but what would you say is the differentiator between Mint and Svelte? Many of the design choices seem similar. I am in the position of starting a new hobby project soon myself and currently Svelte is the one I have landed on. Thank you for your efforts.
    • gdotdesign 6y ago
      Thanks :) Mint has what Svelte doesn't: - consistent language with a good type system - at its base it is a functional language - styling is built in - https://www.mint-lang.com/guide/reference/components/styling-elements https://www.mint-lang.com/guide/reference/components/styling... - routing is built in - https://www.mint-lang.com/guide/reference/routing https://www.mint-lang.com/guide/reference/routing - language constructs for error handling - language constructs for asynchronous tasks - compiles to Preact so the build output is small - easy JavaScript interopability Svelte has what Mint doesn't: - it is basically JavaScript compiler - different syntax for template (HTML) vs code - code is just mostly JavaScript and can use NPM packages (I think) - have their own runtime without virtual DOM - transitions and animations are built in - reactive by default (without the need for language constructs) I haven't really played around with Svelte though so I might be a bit biased. I suggest that you try both a see what you like more. Let me know if I can help with that :)
• dmjio 6y ago
  Haskell will accept you ! https://haskell-miso.org/ https://haskell-miso.org/
• doorbellpan 6y ago
  i am not familiar with elm, but openbsd has similar issues. unless you do everything perfect from the outset and make friends with theo himself or a core person you are pretty hosed. even then they can berate anyone and everyone however they seem fit, but if you speak out you get personally attacked. they care about themselves over users and cannot even follow their own rules along with using old technology to manage the contributing process making it cumbersome and sometimes not worth the time of new people to try and work with. i know people who gave up even trying after about a year to 18 months for these reasons and they wont even go near the os on a server anymore
• smaudet 6y ago
  I have wondered, it seemed like there was a community of dev professionals who had managed to make things work for them, they could have forked the project easily? The ideas were nice, nobody needs the sort of toxic behavior being exhibited by the ELM core devs. Perhaps its a case of wanting something for nothing...this is a long post and a lot of mental energy better put into a fork, and getting like minded folk involved. New users also quickly discover that the language is unsuitable for use, there would be many interested in such a thing.
• ybit 6y ago
  https://github.com/dmjio/miso https://github.com/dmjio/miso Miso was written exactly for Haskell enthusiasts who want the simplicity of an Elm interface without sacrificing too much performance. The benefits I’d say are thus: • Type sharing (A lot of web dev becomes boilerplate -- serializing and transferring state is a large part of the work of web dev. Type sharing ensures correct-by-construction serialization between server / client amidst any changes to your business logic data types, allows you to focus on your apps core offerings as opposed to minutia). • Rich ecosystem (the Haskell ecosystem has many great libraries that compile w/o any problems on the frontend). • Concurrency (Programming with threads and synchronization primitives is now first class in the browser) • Extensibility. (Compared to Elm’s ports feature, the GHCJS FFI is a much simpler way to interface with third-party libs. Also, Haskell supports typeclasses, and Generic programming, a rich lens library, etc.) • Community involvement (You’ll be working directly at the intersection of a lot of interesting developments in GHC, specifically around cross compilation, syntax, lenses. Any new advancements to GHC has an impact on your frontend code. Also, many PhDs use, love and contribute to Miso. These people tend to be very smart, empathetic and intellectually curious as opposed to dogmatic and contentious that can be found in the software engineering industry at large today). • Nix, a one-tool-to-rule them all for dev, build, and deploy. While not easy, deterministic builds are the future and help one to sleep at night (I’ve found). It can be used solely for personal dev, or for an entire organization, and anything in between. • Virtual DOM. (If your Haskell web framework does not handle the tedious task of DOM manipulation for you, you have been failed as a library consumer IMO. Miso has a very well-tested, simple recursive micro virtual DOM diffing library that can exist standalone and can detect regressions in performance via a benchmark suite). • Simplicity. (Unlike many other ivory tower libraries in Haskell, Miso maintains a simple interface. Many different common abstractions were explored in the early stages of development (free monads, FRP, etc.) and found lacking, unnecessary or replaceable by a simpler solution without sacrificing features. Miso does not attempt to hide behind complex type-level abstractions and blame end-users for their lack of understanding. As opposed to a top-down approach that shoe-horns an abstraction into an environment where it does not belong, Miso takes a bottom-up approach to fully understand its environment, the browser, it’s APIs, the DOM and its short-comings and provide a simple commonly-used abstraction to the end-user that can scale to large applications. This also makes it easier for newcomers to Haskell to get up and running quickly). • Industry adoption. (Several companies are using miso in production for various things in their company, from full product to internal tools / data visualization). • Isomorphic. Due to the rose tree structure of both the DOM and HTML, pre-rendering increases load-time and overall UX along with correct SEO.
• ybit 6y ago
  https://github.com/dmjio/miso https://github.com/dmjio/miso """ Miso was written exactly for Haskell enthusiasts who want the simplicity of an Elm interface without sacrificing too much performance. The benefits I’d say are thus: • Type sharing. A lot of web dev becomes boilerplate -- serializing and transferring state is a large part of the work of web dev. Type sharing ensures correct-by-construction serialization between server / client amidst any changes to your business logic data types, allows you to focus on your apps core offerings as opposed to minutia. • Rich ecosystem. The Haskell ecosystem has many great libraries that compile w/o any problems on the frontend. • Concurrency. Programming with threads and synchronization primitives is now first class in the browser. • Extensibility. Compared to Elm’s ports feature, the GHCJS FFI is a much simpler way to interface with third-party libs. Also, Haskell supports typeclasses, and Generic programming, a rich lens library, etc. • Community involvement. You’ll be working directly at the intersection of a lot of interesting developments in GHC, specifically around cross compilation, syntax, lenses. Any new advancements to GHC has an impact on your frontend code. Also, many PhDs use, love and contribute to Miso. These people tend to be very smart, empathetic and intellectually curious as opposed to dogmatic and contentious that can be found in the software engineering industry at large today. • Nix, a one-tool-to-rule them all for dev, build, and deploy. While not easy, deterministic builds are the future and help one to sleep at night (I’ve found). It can be used solely for personal dev, or for an entire organization, and anything in between. • Virtual DOM. If your Haskell web framework does not handle the tedious task of DOM manipulation for you, you have been failed as a library consumer IMO. Miso has a very well-tested, simple recursive micro virtual DOM diffing library that can exist standalone and can detect regressions in performance via a benchmark suite. • Simplicity. Unlike many other ivory tower libraries in Haskell, Miso maintains a simple interface. Many different common abstractions were explored in the early stages of development (free monads, FRP, etc.) and found lacking, unnecessary or replaceable by a simpler solution without sacrificing features. Miso does not attempt to hide behind complex type-level abstractions and blame end-users for their lack of understanding. As opposed to a top-down approach that shoe-horns an abstraction into an environment where it does not belong, Miso takes a bottom-up approach to fully understand its environment, the browser, it’s APIs, the DOM and its short-comings and provide a simple commonly-used abstraction to the end-user that can scale to large applications. This also makes it easier for newcomers to Haskell to get up and running quickly. • Industry adoption. Several companies are using miso in production for various things in their company, from full product to internal tools / data visualization. • Isomorphic. Due to the rose tree structure of both the DOM and HTML, pre-rendering increases load-time and overall UX along with correct SEO. """ ^ from the author of Miso
• G4BB3R 6y ago
  I can't believe people are still complaining about something that happened almost 2 years ago for a good reason, or even about Elm not having typeclasses, or worst, for elm-format using 4 spaces, that is pointless. And I personally prefer Elm the way it is, with typeclasses the compilation speed and error messages wouldn't be the way it is now. There is already Purescript for those who need typeclasses and better js ffi, no need to follow the same path. In the next few years Elm will have everything we need as pure elm, and libs with great quality.