18 ms·

Elm at Rakuten

281 points by dragonsh 5y ago

PragmaticPulp 5y ago
Interesting breakdown of some pros and cons of using Elm in production. However, it appears the JavaScript codebase they used for comparison was quite bad and maybe not representative of a good or even typical JavaScript app: > Our JavaScript application had global variables everywhere, and debugging was a nightmare Point #3 in their list of cons is especially important for anyone considering Elm: > Because Elm is not a mainstream language, it is sometimes necessary to reinvent something that could otherwise have been acquired by adopting a different technology. This is the biggest downfall of Elm projects that I’ve seen in the real world. Teams end up spending half of their time or more solving problems that could have been accomplished quickly with some off the shelf React libraries with numerous tutorials online. This attracts a lot of developers who enjoy working on libraries and tooling, but it’s not ideal if you’re trying to run a lean team that ships products quickly. Elm is fun, but I wouldn’t use it unless I could afford to hire a relatively huge team to absorb all of the additional complexity and detours that go into building an Elm app. There’s a constant promise of Elm being faster and easier to write for various reasons, but in practice it always seems to get bogged down in endless gotchas and framework shortcomings that need to be addressed before we can get down to getting real work done.
- dimitrios1 5y ago
  > but it’s not ideal if you’re trying to run a lean team that ships products quickly. Good. The longer I do this, the longer I realize that unless your in a race-to-the-bottom industry (something like vying for eye balls to increase ad spend), then this is categorically a bad thing. I would prefer the quality of engineering required in knowing how to do some of these things yourselves. Take your time. Understand what you are doing. Some of the world class technologies we all know and use daily use minimal dependencies. And with more malicious code entering more package repositories, it might be apt advice more than ever today.
  - deleted 5y ago
    [deleted]
  - pjlegato 5y ago
    Quality engineering must always be balanced against the reality of finite budgets. Sure, lots of amazing engineering can be achieved in theory, _given infinite funding_. That never happens in the real world. One always has limited time to produce a viable product. There is always some extrinsic constraint to how much time can be spent taking your time and understanding what you're doing. Moreover, if you are operating in any commercially viable product space, you're always competing against other firms for finite market share. If it takes x years to ponder and understand how to build and ship a masterful feat of engineering, while some other company ships a "sort-of-works" product with bugs and engineering flaws in <<< x years, the other company will usually win in the marketplace. Your company usually goes bankrupt, and all the engineers will complain at their next jobs about what a wonderfully designed engineering system they were building, and how awful it is that nobody appreciates such things these days.
    - Silhouette 5y ago
      This is the popular wisdom but I question how universally applicable it is. We all know that having the best technology doesn't necessarily mean you win in a commercial market and we all know that being first mover can be an advantage, but those observations don't tell us what will be successful in the long term. How often does substandard technology and technical debt become a drag on a business not long after that first move, allowing someone else to overtake because the poorly built system couldn't scale to production levels or wasn't adaptable enough for changing requirements or failed so often that the early users drifted away? How often do we see developers advocating shortcuts and showing limited understanding of basic software development or computer science ideas, only to see the product they work on being rewritten within a year or two, or the whole team shut down? You can try to be fastest always. You can often succeed, at first, if you take enough shortcuts. But you can't sustain that pace without enough quality in your people and your code. Planning to throw each implementation away and rewrite with more resources every year or two is a very unicorn-like strategy. It reminds me of VCs whose strategy is to invest liberally, who are fully aware that most of those investments won't work out but they're hoping for one or two in each batch to become the next big hits. Real engineering isn't done in a vacuum and its goal isn't perfection. Real engineering takes issues like costs and timescales and staffing into account and aims to find a solution that is good enough on all counts. But it still has to be good enough. Producing junk but quickly and cheaply is an effective strategy until it's not and the success of any product using that strategy comes down to little more than the luck of the draw.
- theobeers 5y ago
  From the opening section of the blog post, I wondered why an incremental move to TypeScript wouldn’t have worked for them. The rest seems to be all about Elm (I haven’t read it thoroughly), but I feel there’s a disconnect between the problem they started with and their choice to dive into a wholly new ecosystem. edit: Ah, hold on; I just got to where they comment on this. “TypeScript, which adds optional static typing to JavaScript and is probably one of the best things to happen to JavaScript, can partially mitigate the issues with the JavaScript dynamic type system. But being a superset of JavaScript it needs to compromise on elegance and simplicity. It also has several ‘blind spots.’” etc. I don’t know that I’m 100% convinced.
  - cardanome 5y ago
    TypeScript has a slow compiler and horrendous error messages (especially compared to the Elm). Plus it is far away from the no runtime exception guarantees that Elm offers by design. Also TS is just part of a potential solution while Elm comes with all batteries included. You still have to set up your code formater, liner, decide on a framework, state management library and so on and so on. With Elm, you just use elm-format. No arguing about code style, not arguing about how structure your code. There is only way to do it. It is not only a language but a framework. You get everything you need out need out of the box.
    - toastal 5y ago
      Elm also has a sound type system and no side effects because it doesn't need to be compatible with vanilla JavaScript
    - leshow 5y ago
      If you use something like nextjs and strict compiler options for TS a lot of these concerns go away. > You get everything you need out need out of the box. This is specious. There's lots of comments about how you don't get everything out of the box and for the parts that are missing it's a pain. Perhaps your particular use cases are covered, that's great.
  - wk_end 5y ago
- aranchelk 5y ago
  > This is the biggest downfall of Elm projects that I’ve seen in the real world. Teams end up spending half of their time or more solving problems that could have been accomplished quickly with some off the shelf React libraries with numerous tutorials online. This is an important point; I think it applies to varying degrees to any less popular language or framework. It’s a little worse with Elm because of the restrictions they’ve placed on JS interop. I'll add that unless you're very familiar with the framework/language you'll be using, it's pretty hard to estimate scope of work; you'll just encounter surprises during implementation along the lines of "wow I can't be believe they don't have a library for x." On the plus side, since the work of implementing these libraries is very generic with regard to any specific application, it's easy to delegate to other employees or contractors. I’m currently working on a large PureScript project. At various times I’ve had to implement my own base libraries and components, but in many cases I’ve just been able to wrap existing JavaScript code. Some of the key libraries I use, which were developed by other community members are wrapped JavaScript libraries. This has been a pretty powerful mitigation strategy. In the case of PureScript, I also have the benefit of reusing a substantial amount of front end code on the server. For me, on this particular project, the benefits of using a language with advanced features has far outweighed the above mentioned costs, but I think you've got to look at each situation differently and do that evaluation.
  - Silhouette 5y ago
    I'll add that unless you're very familiar with the framework/language you'll be using, it's pretty hard to estimate scope of work I think you've just defined a pretty good benchmark for when it's sensible to consider a less popular choice. Are you familiar enough with it to be confident of coming out ahead by using it? Perhaps you have a backup plan like the interop you mentioned if some functionality is missing. Perhaps the tool is so much more productive in general that you are reasonably confident any extra development work to fill in the gaps will be outweighed by the overall benefits. But there should be some clear reason you think the risk is justified.
  - platz 5y ago
    curious if you using halogen or react-basic? I've gone with halogen for a small project and it's been fine but sometimes i wonder if react-basic is a better choice.
- whateveracct 5y ago
  A seasoned small Elm team will probably scale to higher complexity heights than a small JS team in my experience. Same goes for Haskell and the like. The freaking out about "oh no I gotta write a small library myself" is absurdly overblown here. Most of the time I see it, it's people flipping out at the very sight of there not being something available off-the-shelf. The actual cost is much lower than the panic implies. In general, people see ANY time spent in an FP language to solve FP problems as "a waste of time" but they're blind to the wastes of time people treat as "real code" in mainstream languages. But yeah if you're a software efficiency bean counter, maybe you won't like FP. Fair point. My opinion is the long-term technical & cultural benefits and opportunities pay off. And as a developer, I am happy to not optimize my development velocity to the utmost if it means I don't have to waste my brainpower writing imperative code. My mind is in a much better state at the very least :)
  - vlunkr 5y ago
    > The freaking out about "oh no I gotta write a small library myself" is absurdly overblown here This isn't a good representation of the argument. People don't want to write libraries because it's more valuable for everyone to spend time writing features using existing libraries, provided there are good libraries available. People aren't "freaking out", they just have deadlines, and you know, other things to do with their lives besides write code that has already been written.
    - mst 5y ago
      I would imagine that it's a good representation of their experience of such things, but a poor representation of the experience of such things of the person they're replying to.
    - whateveracct 5y ago
      Nah it's a pretty good representation. And acting like time should 100% be spent writing features is shortsighted - sometimes it's worth it to pay fixed costs such as filling in a gap of the ecosystem of the language you chose for higher reasons than cranking out business code.
- aszen 5y ago
  Elm is build on top of solid foundations, and has a good standard library unlike js so it's much easier to reinvent things as you say. One of the core ways to ship products quickly is to ensure you don't break things often, and elm lets u do that provided one learns it well enough
- lhorie 5y ago
  > Teams end up spending half of their time or more solving problems that could have been accomplished quickly with some off the shelf React libraries with numerous tutorials online. I dunno, having seen both sides, there are pros and cons to each. Teams that reach for libs quickly often think in terms of libraries instead of solutions (one recent example was some folks who were asking for my advice on some over-engineered client-side PDF generation thing, and me suggesting `window.print()` as a solution, considering this was for an internal tool and you effectively want print stylesheets anyways), and often use them as crutches due to a self-fulfilling cycle of "I don't know how to do X, let's use a library so I never need to find out" (and then pulling in a huge lib to do the job of a literal one-liner regex - `uuid.validate()`, looking at you). In my experience, they also often end up buried by their own complexity due to gluing too many things together. But at the same time, it's hard to argue with the ease with which one can plop a modal dialog or a calendar or a collapsible table in a React app. I find that teams working with more exotic technologies tend to be more creative with solutions (e.g. "oh there's no zoomable map UI lib bindings, so let's ask ourselves, do we really need a map library for that contact us page or is a static jpg good enough?") and a have a deeper appreciation for how hard things are to implement. But conversely, UX can suffer from too much "creativity". For example, if care is not taken w/ accessibility concerns for some UI element. Or, as you said, things just take longer to ship because people need to reinvent wheels.
- mjaniczek 5y ago
  > Elm is fun, but I wouldn’t use it unless I could afford to hire a relatively huge team to absorb all of the additional complexity and detours that go into building an Elm app. There’s a constant promise of Elm being faster and easier to write for various reasons, but in practice it always seems to get bogged down in endless gotchas and framework shortcomings that need to be addressed before we can get down to getting real work done. Is this your experience writing Elm apps in production? I am writing large Elm apps in production and I'm having very different experience to what you just described.
tempest_ 5y ago
Elm looks interesting but when it pops up around here and other places it is usually about how the main dev does not work and play well with others. It is a bit off putting. It is nice to see a different perspective.
- z5h 5y ago
  I think when something is built by several people, catering to outside interests, you end up with more churn, bloat, inconsistency, instability, etc. But your specific need has a better chance if being addressed. When something (like Elm) is built in a silo, you end up with less churn, bloat, instability, inconsistency. We forget how we got these nice things, and when we want something NOW we get cranky about the development model. So, as a developer with 20+ years of experience I can say that EVERYTHING (tools, languages, paradigms) is shitty in some ways, and I vastly prefer the ways that Elm and ecosystem are shitty.
- razze 5y ago
  Having worked with "the main dev" I can't say I share this view. It has been very nice to be able to pick his brain and hear his thoughts. It can be exhausting, when you want to improve things now, but come up with a better long term plan. I guess that's a language designer thing.
hitekker 5y ago
The "Elm at Microsoft" link is broken and when I google for it, I can only find an archived package on Github.
- pianoben 5y ago
  This link works for me: https://elmtown.simplecast.com/episodes/it-just-goes-on-and-on-x_tpWljQ https://elmtown.simplecast.com/episodes/it-just-goes-on-and-...
  - hitekker 5y ago
    Hmmm, I think it's my VPN. My bad.
- cfors 5y ago
  Its right here from the "Other Testimonies" section: https://elmtown.simplecast.com/episodes/it-just-goes-on-and-on-x_tpWljQ https://elmtown.simplecast.com/episodes/it-just-goes-on-and-... Obviously Microsoft is a huge company so they use all of the languages, but I find it surprising given the amount of investment they've made into Typescript.
  - Zababa 5y ago
    It's not surprising for a large company. For example, Google uses C++, Rust and Go on Fuchsia. They have Angular with Typescript and Angular with Dart. Big companies are what they are, an association of a lot of people that are all different.
folex 5y ago
Elm is awesome, its compiler is awesome, but its ecosystem is kinda stalling, isn't it? I mean, a lot of libraries aren't updated to the last lang version, debugging JS-Elm interactions been a real challenge for years, yadda yadda. Overall I'd say Elm ecosystem doesn't receive enough attention to survive. I'm not complaining, I'm just sad about that and kinda surprised I didn't found a mention of that in the OP article.
- mechelephant 5y ago
  I would argue the opposite! The elm slack is very active with people who frequently contribute to the ecosystem. I don't think the "a lot of libraries aren't updated to the last lang version" is true, the vast majority are. Debugging elm-JS interactions is not really a problem when using the standard interop methods of ports and webcomponents. It's just not something that comes up often. Source: have been writing elm professionally for the last 2 and a half years.
  - folex 5y ago
    Disclaimer: I'm just describing an annoying technical problem, it's not a blocker for the use of Elm. Elm _is_ great :) I have been using Elm for a kinda-simple project on my work: dashboard for microservices, deployment configs, nodes, etc. One of the biggest time-drains was debugging JS-Elm port interactions, looking whether there is a mismatch in types. Cuz the error looks like this: Elm eventreceiver failed: Error: Trying to send an unexpected type of value through port `collectPeerInfo`: [object Object] I know of no way of even looking into that `[object Object]`. Simply logging its fields would already be a relief, lest telling what field/type caused the error.
- jaeming 5y ago
  As I understand it, there was a rift in the community over the leadership's tone in messaging and communication. Some Developers also felt like they could not contribute in a meaningful way or have constructive discussion with maintainers. See posts like these for more details and comments: https://news.ycombinator.com/item?id=16510267 https://news.ycombinator.com/item?id=16510267 https://news.ycombinator.com/item?id=22821447 https://news.ycombinator.com/item?id=22821447 There are also several great alternatives now. F# with Fable and Elmish for example: https://zaid-ajaj.github.io/the-elmish-book/#/ https://zaid-ajaj.github.io/the-elmish-book/#/ And Bucklescript TEA with Ocaml or Reason: https://github.com/OvermindDL1/bucklescript-tea https://github.com/OvermindDL1/bucklescript-tea Some others have also gone on to develop new languages taking inspiration from Elm: https://www.mint-lang.com/ https://www.mint-lang.com/
mouzogu 5y ago
Wouldn't it be difficult to find other developers that are experienced using Elm? I don't know much about it tbh. Probably, one of my biggest career mistakes was opting for a little known PHP cms instead of WP as I thought it would be easier for the stakeholders to work with the limited options. Since then, I've always avoided going away from the mainstream toolset.
- g_delgado14 5y ago
  > Wouldn't it be difficult to find other developers that are experienced using Elm? Yes, however: - Elm has a very small surface area (you can read through the guide [0] in a weekend) - There are many folks who love functional programming && are willing to learn Elm So, given those two facts, the lack of Elm developers compared to other "markets" is not a big issue. For me, personally, the only risk with Elm is its incredibly opaque development. It's led by Elm's BDFL and a few other folks and it's almost as though they go out of their way to make Elm hard to adopt for outsiders. For example, all you have to do is change elm's version to 1.0.0 to signal to outsiders that, yes .. Elm is and has been production ready for quite a while now (years?). Instead "insiders" will reason and rant about how 0.19.1 is fine. ---- [0] - https://guide.elm-lang.org/ https://guide.elm-lang.org/
  - blowski 5y ago
    I appreciate that I am biased because of my background, but I've met precisely one person who's used Elm while just about every dev I know has worked with WordPress at some point. For most enterprises I work with, 10 years in production is about close as they're willing to get to the bleeding edge. They don't really care about code quality or features. They want to be safe, secure and future-proof for as low a price as possible. That said, I know very little about Elm and would love to understand more about what it offers that's so exciting. I skim-read the article, will read in more detail later.
    - matsemann 5y ago
      My bias is the opposite, probably because I've worked at an Elm shop. But I know zero people with wordpress experience, in my circles I'm the only one I know of with professional php experience at all. But I need more than my hands to count all elm programmers I know.
aaronchall 5y ago
I'd like to recommend Elm at work but I can't because it's still below a major version of 1, which implies there may be a good deal of rework in the short term. I did get an Elm app upgraded from 0.18 to 0.19 without too much extra work, but I'm concerned a major version release may bring much more changes.
- moistoreos 5y ago
  https://github.com/elm/compiler/blob/master/roadmap.md https://github.com/elm/compiler/blob/master/roadmap.md
sergiotapia 5y ago
I'll never even consider Elm after they added DRM to the compiler. https://news.ycombinator.com/item?id=27819874 https://news.ycombinator.com/item?id=27819874
- jeofken 5y ago
  Would it not be to prevent supply chain attacks, and to guarantee the user that all code you run is pure and type safe? They don’t hinder anyone from forking and removing this limitation, allowing any package author to run native code on your machine.
  - macintux 5y ago
    > They don’t hinder anyone from forking and removing this limitation, allowing any package author to run native code on your machine. That has arisen a few times here. Yes, they actually do actively discourage forking (to the point of threatening “excommunication” from the community).
    - vmchale 5y ago
      Yeah if anything the need to constantly fork the compiler indicates a problem lol.
      - jeofken 5y ago
        It can be as simple as having a patch and just updating by reapplying the patch over the master branch. You’d have to build from source of course, rather than downloading someone else’s binaries.
    - jeofken 5y ago
      Who cares? It’s a computer program, just have it do what purpose you require
      - macintux 5y ago
agbell 5y ago
For those want to learn Elm, or to learn strongly typed functional programming in very well thought out order @rtfeldman's book "Elm In Action" is super good. His experience working at a teaching company made his book very well structured for new comers.
dmix 5y ago
> We had global variables everywhere, and debugging was a nightmare. ES6 module imports really helped solve this problem and is a giant step forward in the JS ecosystem. Despite being relatively straight forward they were (and are) a big deal. Any JS project before that was a giant dance of complex window namespacing, closure wrappers, and hoping the 3rd party library you’re using doesn’t expect some weird custom thing to ‘import’ it. The next step obviously is fixing bundling and replacing Webpack and Babel (the closest thing to a widespread standard today in JS) with something less magicy and more native. And these are a big reason newbies/non JS devs freak out when they see a thousand packages in starter kits. These two things (importing and bundling/preprocessing) were a big reason why there always seemed to be a never ending output of new build tools. Just having those two to be predictable is a godsend in any JS developers but IRL even the best internal practices was never consistent across libraries, teams, and projects. I’ve always wondered how much frameworks like Elm and similar are motivated simply but attempting to establish best practices and standards in JS projects vs the abstraction/language innovations they provide (like pure FP and reactivity stuff). It’s at least 50% of the value proposition. The big question is whether it will be for long enough to be worth the investment.
- hashkb 5y ago
  esbuild and TS are a good step you can take incrementally as you move away from webpack/babel. Still the lesser of some evils, but less evil is better.
Existenceblinks 5y ago
I had a problem with perf optimization on Html.Lazy long time ago that I can't solved before I moved on. Since Elm is immutable and lazy render, most of the time, compare underline object reference (referential equality check), the reference (memory location) almost always changes on every update cycle because it needs to update model, thus, a new reference as a result. And that makes Html.Lazy worthless. I had some kind of 1000 html tree nodes, and it rendered every branch every time. I probably did something not right, but I already tried solving that for a few days, no success. If you have the Elm in Action book, that memory location pitfall is explained on the very last page about when memory location of a object changes.
arcade79 5y ago
I wonder if someone will create 'pine' - "pine is not elm". (For younglings: elm was an email client. pine was also an email client. The latter was often thought to be short for 'pine is not elm').
- wing-_-nuts 5y ago
  I have fond memories of using the pine email client. It was so fast. I know mutt is another one, supposedly, but by the time I was considering switching, I had exclusively moved to web mail.
- fatnoah 5y ago
  To be honest, I read the article and was expecting this to be about ditching Outlook or Gmail in favor of Elm.
agumonkey 5y ago
anybody using purescript and its streamed ui lib ?
- osener 5y ago
  Do you have a link for this library?
  - agumonkey 5y ago
    I just spent 10 minutes digging google and I cannot find it again. I didn't even try to find about it last year, it seemed the only ui lib for purescript with a tiny docs website (beige / pale themed) Really surprised not being able to find it again.. I'll reply again if I end up finding it
    - dodecaphonic 5y ago
      Maybe you mean Concur? https://purescript-concur.github.io/purescript-concur-react/ https://purescript-concur.github.io/purescript-concur-react/
      - nextaccountic 5y ago
        Or maybe https://flame.asafe.dev/ https://flame.asafe.dev/
StefanWestfal 5y ago
From a self taught view, the compiler helped me a lot and when it compiles it usually works and when not the community is very helpful. Over all I found libraries usually of good quality while also not needing a lot as Elm includes a lot out of the box (i.e. React, Redux, axios, type guards, etc.). Elm-UI made working with styling much easier for me and was the main reason I gave Elm a try. The Evan and the core team seem to have a clear vision of what they want and I can understand that but this is personal opinion. To make a system work well you have to be strict and including new features all the time might introduce complexity down the line. This might seem a bit closed in form the outside. So far I am very happy with it.
GiorgioG 5y ago
The bus factor of 1 makes it a non-starter for me for any serious project.
- adelarsq 5y ago
  Sad, but true.
- G4BB3R 5y ago
  I could use Elm as it is today for at least a decade without updates, since it's very stable. Anyway, I am sure there are very competent people from the core devs or from the community that could make a new leadership if that happened.
  - GiorgioG 5y ago
    Your assurances don't particularly mean much - no offense. A decade from now I don't want to have a codebase with a toolchain with no future.
- frozenlettuce 5y ago
  even the docs are written in first person
- razze 5y ago
  There is a contingency plan for that. According to the core team.
dsiegel2275 5y ago
It is refreshing once again to see an Elm post that looks at the pros and cons of the language and ecosystem, instead of solely focusing on a perceived problem with the way that the community is run.
neals 5y ago
What is Rakuten? Why is it on all my Samsung TV's? How come it works out of the box?
- deergomoo 5y ago
  > What is Rakuten? A Japanese tech conglomerate. > Why is it on all my Samsung TV's? Because Samsung have no shame and will gladly ruin their own products for a quick buck.
deleted 5y ago
[deleted]
decafbad 5y ago
mkose@casper:~/Desktop$ ./elm repl ---- Elm 0.19.1 ----------------------------------------- > Basics.modBy 0 3 Error: Cannot perform mod 0. Division by zero error.
- earth_walker 5y ago
  This is correct behaviour, depending on the definition of mod. See, for example: https://math.stackexchange.com/questions/516251/why-is-n-mod-0-undefined https://math.stackexchange.com/questions/516251/why-is-n-mod...
  - decafbad 5y ago
    The promise was no runtime errors.
    - earth_walker 5y ago
      You are absolutely right and I missed the point! I believe there are a couple of things in the standard library which should have returned a Maybe (or even better taken a NonZero as an argument). The community Extra libraries tend to offer safe versions of these cases, so it's easy to avoid if you know about it. Another gotcha that will give a runtime error is the stack overflow if you have too many recursions in a function. You can get around it by using builtins like maps and folds, or refactoring for tail-calls. Since recursion is often taught to FP beginners as the go-to replacement for loops without explaining TCO, I think many users are surprised by this early on, and with just the compiler they would otherwise have no warning of this without knowing how and when to test for it. I believe Elm-review is coming out with a method to warn about these cases, so it will be detectable with standard tools. On the whole, though, these are the few avoidable edge cases, and the promise does hold the rest of the time.
    - 1-more 5y ago
      There are two that I can think of: this, and the fact that there's no equality class yet. In practice it just doesn't come up.
    - 5y ago
ferdowsi 5y ago
After the relevations about Elm's dysfunctional leadership culture[1] I have seen vocal discouragement about investing in Elm, and reasonably so. This is a culture where Elm's leaders actively attempt to shut down criticism as "emotional violence"[2], which is just incredibly immature hyperbole. I couldn't imagine investing the future of my job and workplace on an operation like this. [1]https://news.ycombinator.com/item?id=22821447 https://news.ycombinator.com/item?id=22821447 [2] https://www.reddit.com/r/elm/comments/7zk0dy/is_evan_killing_elms_momentum/dur9k1q/#t1_dur9k1q https://www.reddit.com/r/elm/comments/7zk0dy/is_evan_killing...
- StefanWestfal 5y ago
  I had a similar line of thought in the beginning too. If you google Elm these issues pop up. However after some time posts about it lead back a very limited set of occasions and block posts. Which are either criticizing the leadership style or a few events. I view the leadership as a trade off which ensures a high level and guarantees for the core at the cost of a high barrier. For the fee events, I think we are all humans and make mistakes and usually it is a miss communication between two parts more then a real issue.
roebk 5y ago
The pros and cons listed hear mirror my own views of Elm. Although, we’ve only got a handful of small Elm apps in production it’s a joy to work on them. I can rip into them with a fairly big refactor, fix the compiler errors and be confident that it’s all going to work. I do which there were a larger selection of Elm packages to take advantage of, but integrating Web Components into Elm hasn’t been bothersome.
fulafel 5y ago
What are Elm users using on the back end? FP or mainstream languages?
- wolfadex 5y ago
  I have coworkers using Rails for the back end of their Elm app. I think NoRedInk is using some Rails and some Haskell. I've have a friend who uses Python for his back ends. Also heard that some people really like using F#, as well as Node. Or if you want to do Elm full stack there's https://lamdera.com/ https://lamdera.com/ or https://package.elm-lang.org/packages/choonkeat/elm-fullstack/latest/ https://package.elm-lang.org/packages/choonkeat/elm-fullstac....
- danbruder 5y ago
  we are using rust on the backend
  - deleted 5y ago
    [deleted]
- whichdan 5y ago
  We're using Elixir on the backend at Corvus Insurance and it's quite nice.
- girishso 5y ago
  Any back end stack that can provide APIs, we're using .NET.
- lucamug 5y ago
  We use Kotlin
dzonga 5y ago
little anecdote: I did a couple of personal projects in elm in 2017. one thing I'm thankful for it taught me functional programming. Elm was easy to start with for someone new to functional programming. it also taught me, one important lesson - the market doesn't really care. a company when you're looking for a gig doesn't care if you know elm, it wants you to know the 'framework'they're using currently. so yeah, I see elm being a dead end. either people using it already solved product/market fit. but for a startup getting off the ground - elm offers no benefits at all compared to js.
- wolfadex 5y ago
  I had the opposite experience with my last job interview. I didn't know any Ember but I did know Elm (and other languages and frameworks). My enthusiasm about Elm absolutely contributed to my being hired and my lack of Ember knowledge didn't hurt me. This was what the hiring manager told me.
tmm84 5y ago
The part of the article that I was waiting for was how they got it adopted in Japan. Having worked in Japan for almost a decade I can easily say it is not an easy feat to change Japanese corporate mindset when it comes to a programming language or environment. I wonder what the elevator sales pitch was. Other than that I think this was a great article.
- lucamug 5y ago
  Even though Rakuten is a Japanese company and all this happened in Japan, the department where it happened is almost entirely not Japanese, so the "elevator sales pitch" has nothing to do with Japan. There were already several developers that were on board with Functional Programming, this is what helped a lot. As a matter of Japan, there is a very lively Elm community and I know few companies that use Elm in production. Also, I heard that the Japanese academic world is active in Functional Programming research
b7bfcdeaab33 5y ago
"the order in which we write the code doesn’t matter" What do you lose in this trade off?
- lucamug 5y ago
  Interesting question. I feel that I don't lose nothing with this feature, but maybe someone else may have a deeper insight
mchusma 5y ago
Rakuten is basically a scam on merchants right? By that I means they use affiliate links to make money. But most of their referred traffic comes from people checking out and saying "I use rakuten to get a discount at the places I already shop". The stores then don't know how much business rakuten is really bringing them, so are scared to stop it. Consumers keep checking rakuten to see if they get discounts on things they want, because why not? Is this a good summary? Anyone have a more favorable impression of their work (from the store perspective)?
- nopcode 5y ago
  Rakuten is a billion dollar company often referred to as the Amazon of Japan. They have a very different type of presence in different countries.

281 points by dragonsh 5y ago

Interesting breakdown of some pros and cons of using Elm in production. However, it appears the JavaScript codebase they used for comparison was quite bad and maybe not representative of a good or even typical JavaScript app: > Our JavaScript application had global variables everywhere, and debugging was a nightmare Point #3 in their list of cons is especially important for anyone considering Elm: > Because Elm is not a mainstream language, it is sometimes necessary to reinvent something that could otherwise have been acquired by adopting a different technology. This is the biggest downfall of Elm projects that I’ve seen in the real world. Teams end up spending half of their time or more solving problems that could have been accomplished quickly with some off the shelf React libraries with numerous tutorials online. This attracts a lot of developers who enjoy working on libraries and tooling, but it’s not ideal if you’re trying to run a lean team that ships products quickly. Elm is fun, but I wouldn’t use it unless I could afford to hire a relatively huge team to absorb all of the additional complexity and detours that go into building an Elm app. There’s a constant promise of Elm being faster and easier to write for various reasons, but in practice it always seems to get bogged down in endless gotchas and framework shortcomings that need to be addressed before we can get down to getting real work done.

dimitrios1 5y ago
> but it’s not ideal if you’re trying to run a lean team that ships products quickly. Good. The longer I do this, the longer I realize that unless your in a race-to-the-bottom industry (something like vying for eye balls to increase ad spend), then this is categorically a bad thing. I would prefer the quality of engineering required in knowing how to do some of these things yourselves. Take your time. Understand what you are doing. Some of the world class technologies we all know and use daily use minimal dependencies. And with more malicious code entering more package repositories, it might be apt advice more than ever today.
- deleted 5y ago
  [deleted]
- pjlegato 5y ago
  Quality engineering must always be balanced against the reality of finite budgets. Sure, lots of amazing engineering can be achieved in theory, _given infinite funding_. That never happens in the real world. One always has limited time to produce a viable product. There is always some extrinsic constraint to how much time can be spent taking your time and understanding what you're doing. Moreover, if you are operating in any commercially viable product space, you're always competing against other firms for finite market share. If it takes x years to ponder and understand how to build and ship a masterful feat of engineering, while some other company ships a "sort-of-works" product with bugs and engineering flaws in <<< x years, the other company will usually win in the marketplace. Your company usually goes bankrupt, and all the engineers will complain at their next jobs about what a wonderfully designed engineering system they were building, and how awful it is that nobody appreciates such things these days.
  - Silhouette 5y ago
    This is the popular wisdom but I question how universally applicable it is. We all know that having the best technology doesn't necessarily mean you win in a commercial market and we all know that being first mover can be an advantage, but those observations don't tell us what will be successful in the long term. How often does substandard technology and technical debt become a drag on a business not long after that first move, allowing someone else to overtake because the poorly built system couldn't scale to production levels or wasn't adaptable enough for changing requirements or failed so often that the early users drifted away? How often do we see developers advocating shortcuts and showing limited understanding of basic software development or computer science ideas, only to see the product they work on being rewritten within a year or two, or the whole team shut down? You can try to be fastest always. You can often succeed, at first, if you take enough shortcuts. But you can't sustain that pace without enough quality in your people and your code. Planning to throw each implementation away and rewrite with more resources every year or two is a very unicorn-like strategy. It reminds me of VCs whose strategy is to invest liberally, who are fully aware that most of those investments won't work out but they're hoping for one or two in each batch to become the next big hits. Real engineering isn't done in a vacuum and its goal isn't perfection. Real engineering takes issues like costs and timescales and staffing into account and aims to find a solution that is good enough on all counts. But it still has to be good enough. Producing junk but quickly and cheaply is an effective strategy until it's not and the success of any product using that strategy comes down to little more than the luck of the draw.
theobeers 5y ago
From the opening section of the blog post, I wondered why an incremental move to TypeScript wouldn’t have worked for them. The rest seems to be all about Elm (I haven’t read it thoroughly), but I feel there’s a disconnect between the problem they started with and their choice to dive into a wholly new ecosystem. edit: Ah, hold on; I just got to where they comment on this. “TypeScript, which adds optional static typing to JavaScript and is probably one of the best things to happen to JavaScript, can partially mitigate the issues with the JavaScript dynamic type system. But being a superset of JavaScript it needs to compromise on elegance and simplicity. It also has several ‘blind spots.’” etc. I don’t know that I’m 100% convinced.
- cardanome 5y ago
  TypeScript has a slow compiler and horrendous error messages (especially compared to the Elm). Plus it is far away from the no runtime exception guarantees that Elm offers by design. Also TS is just part of a potential solution while Elm comes with all batteries included. You still have to set up your code formater, liner, decide on a framework, state management library and so on and so on. With Elm, you just use elm-format. No arguing about code style, not arguing about how structure your code. There is only way to do it. It is not only a language but a framework. You get everything you need out need out of the box.
  - toastal 5y ago
    Elm also has a sound type system and no side effects because it doesn't need to be compatible with vanilla JavaScript
  - leshow 5y ago
    If you use something like nextjs and strict compiler options for TS a lot of these concerns go away. > You get everything you need out need out of the box. This is specious. There's lots of comments about how you don't get everything out of the box and for the parts that are missing it's a pain. Perhaps your particular use cases are covered, that's great.
- wk_end 5y ago
aranchelk 5y ago
> This is the biggest downfall of Elm projects that I’ve seen in the real world. Teams end up spending half of their time or more solving problems that could have been accomplished quickly with some off the shelf React libraries with numerous tutorials online. This is an important point; I think it applies to varying degrees to any less popular language or framework. It’s a little worse with Elm because of the restrictions they’ve placed on JS interop. I'll add that unless you're very familiar with the framework/language you'll be using, it's pretty hard to estimate scope of work; you'll just encounter surprises during implementation along the lines of "wow I can't be believe they don't have a library for x." On the plus side, since the work of implementing these libraries is very generic with regard to any specific application, it's easy to delegate to other employees or contractors. I’m currently working on a large PureScript project. At various times I’ve had to implement my own base libraries and components, but in many cases I’ve just been able to wrap existing JavaScript code. Some of the key libraries I use, which were developed by other community members are wrapped JavaScript libraries. This has been a pretty powerful mitigation strategy. In the case of PureScript, I also have the benefit of reusing a substantial amount of front end code on the server. For me, on this particular project, the benefits of using a language with advanced features has far outweighed the above mentioned costs, but I think you've got to look at each situation differently and do that evaluation.
- Silhouette 5y ago
  I'll add that unless you're very familiar with the framework/language you'll be using, it's pretty hard to estimate scope of work I think you've just defined a pretty good benchmark for when it's sensible to consider a less popular choice. Are you familiar enough with it to be confident of coming out ahead by using it? Perhaps you have a backup plan like the interop you mentioned if some functionality is missing. Perhaps the tool is so much more productive in general that you are reasonably confident any extra development work to fill in the gaps will be outweighed by the overall benefits. But there should be some clear reason you think the risk is justified.
- platz 5y ago
  curious if you using halogen or react-basic? I've gone with halogen for a small project and it's been fine but sometimes i wonder if react-basic is a better choice.
whateveracct 5y ago
A seasoned small Elm team will probably scale to higher complexity heights than a small JS team in my experience. Same goes for Haskell and the like. The freaking out about "oh no I gotta write a small library myself" is absurdly overblown here. Most of the time I see it, it's people flipping out at the very sight of there not being something available off-the-shelf. The actual cost is much lower than the panic implies. In general, people see ANY time spent in an FP language to solve FP problems as "a waste of time" but they're blind to the wastes of time people treat as "real code" in mainstream languages. But yeah if you're a software efficiency bean counter, maybe you won't like FP. Fair point. My opinion is the long-term technical & cultural benefits and opportunities pay off. And as a developer, I am happy to not optimize my development velocity to the utmost if it means I don't have to waste my brainpower writing imperative code. My mind is in a much better state at the very least :)
- vlunkr 5y ago
  > The freaking out about "oh no I gotta write a small library myself" is absurdly overblown here This isn't a good representation of the argument. People don't want to write libraries because it's more valuable for everyone to spend time writing features using existing libraries, provided there are good libraries available. People aren't "freaking out", they just have deadlines, and you know, other things to do with their lives besides write code that has already been written.
  - mst 5y ago
    I would imagine that it's a good representation of their experience of such things, but a poor representation of the experience of such things of the person they're replying to.
  - whateveracct 5y ago
    Nah it's a pretty good representation. And acting like time should 100% be spent writing features is shortsighted - sometimes it's worth it to pay fixed costs such as filling in a gap of the ecosystem of the language you chose for higher reasons than cranking out business code.
aszen 5y ago
Elm is build on top of solid foundations, and has a good standard library unlike js so it's much easier to reinvent things as you say. One of the core ways to ship products quickly is to ensure you don't break things often, and elm lets u do that provided one learns it well enough
lhorie 5y ago
> Teams end up spending half of their time or more solving problems that could have been accomplished quickly with some off the shelf React libraries with numerous tutorials online. I dunno, having seen both sides, there are pros and cons to each. Teams that reach for libs quickly often think in terms of libraries instead of solutions (one recent example was some folks who were asking for my advice on some over-engineered client-side PDF generation thing, and me suggesting `window.print()` as a solution, considering this was for an internal tool and you effectively want print stylesheets anyways), and often use them as crutches due to a self-fulfilling cycle of "I don't know how to do X, let's use a library so I never need to find out" (and then pulling in a huge lib to do the job of a literal one-liner regex - `uuid.validate()`, looking at you). In my experience, they also often end up buried by their own complexity due to gluing too many things together. But at the same time, it's hard to argue with the ease with which one can plop a modal dialog or a calendar or a collapsible table in a React app. I find that teams working with more exotic technologies tend to be more creative with solutions (e.g. "oh there's no zoomable map UI lib bindings, so let's ask ourselves, do we really need a map library for that contact us page or is a static jpg good enough?") and a have a deeper appreciation for how hard things are to implement. But conversely, UX can suffer from too much "creativity". For example, if care is not taken w/ accessibility concerns for some UI element. Or, as you said, things just take longer to ship because people need to reinvent wheels.
mjaniczek 5y ago
> Elm is fun, but I wouldn’t use it unless I could afford to hire a relatively huge team to absorb all of the additional complexity and detours that go into building an Elm app. There’s a constant promise of Elm being faster and easier to write for various reasons, but in practice it always seems to get bogged down in endless gotchas and framework shortcomings that need to be addressed before we can get down to getting real work done. Is this your experience writing Elm apps in production? I am writing large Elm apps in production and I'm having very different experience to what you just described.

tempest_ 5y ago

Elm looks interesting but when it pops up around here and other places it is usually about how the main dev does not work and play well with others. It is a bit off putting. It is nice to see a different perspective.

z5h 5y ago
I think when something is built by several people, catering to outside interests, you end up with more churn, bloat, inconsistency, instability, etc. But your specific need has a better chance if being addressed. When something (like Elm) is built in a silo, you end up with less churn, bloat, instability, inconsistency. We forget how we got these nice things, and when we want something NOW we get cranky about the development model. So, as a developer with 20+ years of experience I can say that EVERYTHING (tools, languages, paradigms) is shitty in some ways, and I vastly prefer the ways that Elm and ecosystem are shitty.
razze 5y ago
Having worked with "the main dev" I can't say I share this view. It has been very nice to be able to pick his brain and hear his thoughts. It can be exhausting, when you want to improve things now, but come up with a better long term plan. I guess that's a language designer thing.

hitekker 5y ago

The "Elm at Microsoft" link is broken and when I google for it, I can only find an archived package on Github.

pianoben 5y ago
This link works for me: https://elmtown.simplecast.com/episodes/it-just-goes-on-and-on-x_tpWljQ https://elmtown.simplecast.com/episodes/it-just-goes-on-and-...
- hitekker 5y ago
  Hmmm, I think it's my VPN. My bad.
cfors 5y ago
Its right here from the "Other Testimonies" section: https://elmtown.simplecast.com/episodes/it-just-goes-on-and-on-x_tpWljQ https://elmtown.simplecast.com/episodes/it-just-goes-on-and-... Obviously Microsoft is a huge company so they use all of the languages, but I find it surprising given the amount of investment they've made into Typescript.
- Zababa 5y ago
  It's not surprising for a large company. For example, Google uses C++, Rust and Go on Fuchsia. They have Angular with Typescript and Angular with Dart. Big companies are what they are, an association of a lot of people that are all different.

folex 5y ago

Elm is awesome, its compiler is awesome, but its ecosystem is kinda stalling, isn't it? I mean, a lot of libraries aren't updated to the last lang version, debugging JS-Elm interactions been a real challenge for years, yadda yadda. Overall I'd say Elm ecosystem doesn't receive enough attention to survive. I'm not complaining, I'm just sad about that and kinda surprised I didn't found a mention of that in the OP article.

mechelephant 5y ago
I would argue the opposite! The elm slack is very active with people who frequently contribute to the ecosystem. I don't think the "a lot of libraries aren't updated to the last lang version" is true, the vast majority are. Debugging elm-JS interactions is not really a problem when using the standard interop methods of ports and webcomponents. It's just not something that comes up often. Source: have been writing elm professionally for the last 2 and a half years.
- folex 5y ago
  Disclaimer: I'm just describing an annoying technical problem, it's not a blocker for the use of Elm. Elm _is_ great :) I have been using Elm for a kinda-simple project on my work: dashboard for microservices, deployment configs, nodes, etc. One of the biggest time-drains was debugging JS-Elm port interactions, looking whether there is a mismatch in types. Cuz the error looks like this: Elm eventreceiver failed: Error: Trying to send an unexpected type of value through port `collectPeerInfo`: [object Object] I know of no way of even looking into that `[object Object]`. Simply logging its fields would already be a relief, lest telling what field/type caused the error.
jaeming 5y ago
As I understand it, there was a rift in the community over the leadership's tone in messaging and communication. Some Developers also felt like they could not contribute in a meaningful way or have constructive discussion with maintainers. See posts like these for more details and comments: https://news.ycombinator.com/item?id=16510267 https://news.ycombinator.com/item?id=16510267 https://news.ycombinator.com/item?id=22821447 https://news.ycombinator.com/item?id=22821447 There are also several great alternatives now. F# with Fable and Elmish for example: https://zaid-ajaj.github.io/the-elmish-book/#/ https://zaid-ajaj.github.io/the-elmish-book/#/ And Bucklescript TEA with Ocaml or Reason: https://github.com/OvermindDL1/bucklescript-tea https://github.com/OvermindDL1/bucklescript-tea Some others have also gone on to develop new languages taking inspiration from Elm: https://www.mint-lang.com/ https://www.mint-lang.com/

mouzogu 5y ago

Wouldn't it be difficult to find other developers that are experienced using Elm? I don't know much about it tbh. Probably, one of my biggest career mistakes was opting for a little known PHP cms instead of WP as I thought it would be easier for the stakeholders to work with the limited options. Since then, I've always avoided going away from the mainstream toolset.

g_delgado14 5y ago
> Wouldn't it be difficult to find other developers that are experienced using Elm? Yes, however: - Elm has a very small surface area (you can read through the guide [0] in a weekend) - There are many folks who love functional programming && are willing to learn Elm So, given those two facts, the lack of Elm developers compared to other "markets" is not a big issue. For me, personally, the only risk with Elm is its incredibly opaque development. It's led by Elm's BDFL and a few other folks and it's almost as though they go out of their way to make Elm hard to adopt for outsiders. For example, all you have to do is change elm's version to 1.0.0 to signal to outsiders that, yes .. Elm is and has been production ready for quite a while now (years?). Instead "insiders" will reason and rant about how 0.19.1 is fine. ---- [0] - https://guide.elm-lang.org/ https://guide.elm-lang.org/
- blowski 5y ago
  I appreciate that I am biased because of my background, but I've met precisely one person who's used Elm while just about every dev I know has worked with WordPress at some point. For most enterprises I work with, 10 years in production is about close as they're willing to get to the bleeding edge. They don't really care about code quality or features. They want to be safe, secure and future-proof for as low a price as possible. That said, I know very little about Elm and would love to understand more about what it offers that's so exciting. I skim-read the article, will read in more detail later.
  - matsemann 5y ago
    My bias is the opposite, probably because I've worked at an Elm shop. But I know zero people with wordpress experience, in my circles I'm the only one I know of with professional php experience at all. But I need more than my hands to count all elm programmers I know.

aaronchall 5y ago

I'd like to recommend Elm at work but I can't because it's still below a major version of 1, which implies there may be a good deal of rework in the short term. I did get an Elm app upgraded from 0.18 to 0.19 without too much extra work, but I'm concerned a major version release may bring much more changes.

moistoreos 5y ago
https://github.com/elm/compiler/blob/master/roadmap.md https://github.com/elm/compiler/blob/master/roadmap.md

sergiotapia 5y ago

I'll never even consider Elm after they added DRM to the compiler. https://news.ycombinator.com/item?id=27819874 https://news.ycombinator.com/item?id=27819874

jeofken 5y ago
Would it not be to prevent supply chain attacks, and to guarantee the user that all code you run is pure and type safe? They don’t hinder anyone from forking and removing this limitation, allowing any package author to run native code on your machine.
- macintux 5y ago
  > They don’t hinder anyone from forking and removing this limitation, allowing any package author to run native code on your machine. That has arisen a few times here. Yes, they actually do actively discourage forking (to the point of threatening “excommunication” from the community).
  - vmchale 5y ago
    Yeah if anything the need to constantly fork the compiler indicates a problem lol.
    - jeofken 5y ago
      It can be as simple as having a patch and just updating by reapplying the patch over the master branch. You’d have to build from source of course, rather than downloading someone else’s binaries.
  - jeofken 5y ago
    Who cares? It’s a computer program, just have it do what purpose you require
    - macintux 5y ago

agbell 5y ago

For those want to learn Elm, or to learn strongly typed functional programming in very well thought out order @rtfeldman's book "Elm In Action" is super good. His experience working at a teaching company made his book very well structured for new comers.

dmix 5y ago

> We had global variables everywhere, and debugging was a nightmare. ES6 module imports really helped solve this problem and is a giant step forward in the JS ecosystem. Despite being relatively straight forward they were (and are) a big deal. Any JS project before that was a giant dance of complex window namespacing, closure wrappers, and hoping the 3rd party library you’re using doesn’t expect some weird custom thing to ‘import’ it. The next step obviously is fixing bundling and replacing Webpack and Babel (the closest thing to a widespread standard today in JS) with something less magicy and more native. And these are a big reason newbies/non JS devs freak out when they see a thousand packages in starter kits. These two things (importing and bundling/preprocessing) were a big reason why there always seemed to be a never ending output of new build tools. Just having those two to be predictable is a godsend in any JS developers but IRL even the best internal practices was never consistent across libraries, teams, and projects. I’ve always wondered how much frameworks like Elm and similar are motivated simply but attempting to establish best practices and standards in JS projects vs the abstraction/language innovations they provide (like pure FP and reactivity stuff). It’s at least 50% of the value proposition. The big question is whether it will be for long enough to be worth the investment.

hashkb 5y ago
esbuild and TS are a good step you can take incrementally as you move away from webpack/babel. Still the lesser of some evils, but less evil is better.

Existenceblinks 5y ago

I had a problem with perf optimization on Html.Lazy long time ago that I can't solved before I moved on. Since Elm is immutable and lazy render, most of the time, compare underline object reference (referential equality check), the reference (memory location) almost always changes on every update cycle because it needs to update model, thus, a new reference as a result. And that makes Html.Lazy worthless. I had some kind of 1000 html tree nodes, and it rendered every branch every time. I probably did something not right, but I already tried solving that for a few days, no success. If you have the Elm in Action book, that memory location pitfall is explained on the very last page about when memory location of a object changes.

arcade79 5y ago

I wonder if someone will create 'pine' - "pine is not elm". (For younglings: elm was an email client. pine was also an email client. The latter was often thought to be short for 'pine is not elm').

wing-_-nuts 5y ago
I have fond memories of using the pine email client. It was so fast. I know mutt is another one, supposedly, but by the time I was considering switching, I had exclusively moved to web mail.
fatnoah 5y ago
To be honest, I read the article and was expecting this to be about ditching Outlook or Gmail in favor of Elm.

agumonkey 5y ago

anybody using purescript and its streamed ui lib ?

osener 5y ago
Do you have a link for this library?
- agumonkey 5y ago
  I just spent 10 minutes digging google and I cannot find it again. I didn't even try to find about it last year, it seemed the only ui lib for purescript with a tiny docs website (beige / pale themed) Really surprised not being able to find it again.. I'll reply again if I end up finding it
  - dodecaphonic 5y ago
    Maybe you mean Concur? https://purescript-concur.github.io/purescript-concur-react/ https://purescript-concur.github.io/purescript-concur-react/
    - nextaccountic 5y ago
      Or maybe https://flame.asafe.dev/ https://flame.asafe.dev/

StefanWestfal 5y ago

From a self taught view, the compiler helped me a lot and when it compiles it usually works and when not the community is very helpful. Over all I found libraries usually of good quality while also not needing a lot as Elm includes a lot out of the box (i.e. React, Redux, axios, type guards, etc.). Elm-UI made working with styling much easier for me and was the main reason I gave Elm a try. The Evan and the core team seem to have a clear vision of what they want and I can understand that but this is personal opinion. To make a system work well you have to be strict and including new features all the time might introduce complexity down the line. This might seem a bit closed in form the outside. So far I am very happy with it.

GiorgioG 5y ago

The bus factor of 1 makes it a non-starter for me for any serious project.

adelarsq 5y ago
Sad, but true.
G4BB3R 5y ago
I could use Elm as it is today for at least a decade without updates, since it's very stable. Anyway, I am sure there are very competent people from the core devs or from the community that could make a new leadership if that happened.
- GiorgioG 5y ago
  Your assurances don't particularly mean much - no offense. A decade from now I don't want to have a codebase with a toolchain with no future.
frozenlettuce 5y ago
even the docs are written in first person
razze 5y ago
There is a contingency plan for that. According to the core team.

dsiegel2275 5y ago

It is refreshing once again to see an Elm post that looks at the pros and cons of the language and ecosystem, instead of solely focusing on a perceived problem with the way that the community is run.

neals 5y ago

What is Rakuten? Why is it on all my Samsung TV's? How come it works out of the box?

deergomoo 5y ago
> What is Rakuten? A Japanese tech conglomerate. > Why is it on all my Samsung TV's? Because Samsung have no shame and will gladly ruin their own products for a quick buck.

deleted 5y ago

[deleted]

decafbad 5y ago

mkose@casper:~/Desktop$ ./elm repl ---- Elm 0.19.1 ----------------------------------------- > Basics.modBy 0 3 Error: Cannot perform mod 0. Division by zero error.

earth_walker 5y ago
This is correct behaviour, depending on the definition of mod. See, for example: https://math.stackexchange.com/questions/516251/why-is-n-mod-0-undefined https://math.stackexchange.com/questions/516251/why-is-n-mod...
- decafbad 5y ago
  The promise was no runtime errors.
  - earth_walker 5y ago
    You are absolutely right and I missed the point! I believe there are a couple of things in the standard library which should have returned a Maybe (or even better taken a NonZero as an argument). The community Extra libraries tend to offer safe versions of these cases, so it's easy to avoid if you know about it. Another gotcha that will give a runtime error is the stack overflow if you have too many recursions in a function. You can get around it by using builtins like maps and folds, or refactoring for tail-calls. Since recursion is often taught to FP beginners as the go-to replacement for loops without explaining TCO, I think many users are surprised by this early on, and with just the compiler they would otherwise have no warning of this without knowing how and when to test for it. I believe Elm-review is coming out with a method to warn about these cases, so it will be detectable with standard tools. On the whole, though, these are the few avoidable edge cases, and the promise does hold the rest of the time.
  - 1-more 5y ago
    There are two that I can think of: this, and the fact that there's no equality class yet. In practice it just doesn't come up.
  - 5y ago

ferdowsi 5y ago

After the relevations about Elm's dysfunctional leadership culture[1] I have seen vocal discouragement about investing in Elm, and reasonably so. This is a culture where Elm's leaders actively attempt to shut down criticism as "emotional violence"[2], which is just incredibly immature hyperbole. I couldn't imagine investing the future of my job and workplace on an operation like this. [1]https://news.ycombinator.com/item?id=22821447 https://news.ycombinator.com/item?id=22821447 [2] https://www.reddit.com/r/elm/comments/7zk0dy/is_evan_killing_elms_momentum/dur9k1q/#t1_dur9k1q https://www.reddit.com/r/elm/comments/7zk0dy/is_evan_killing...

StefanWestfal 5y ago
I had a similar line of thought in the beginning too. If you google Elm these issues pop up. However after some time posts about it lead back a very limited set of occasions and block posts. Which are either criticizing the leadership style or a few events. I view the leadership as a trade off which ensures a high level and guarantees for the core at the cost of a high barrier. For the fee events, I think we are all humans and make mistakes and usually it is a miss communication between two parts more then a real issue.

roebk 5y ago

The pros and cons listed hear mirror my own views of Elm. Although, we’ve only got a handful of small Elm apps in production it’s a joy to work on them. I can rip into them with a fairly big refactor, fix the compiler errors and be confident that it’s all going to work. I do which there were a larger selection of Elm packages to take advantage of, but integrating Web Components into Elm hasn’t been bothersome.

fulafel 5y ago

What are Elm users using on the back end? FP or mainstream languages?

wolfadex 5y ago
I have coworkers using Rails for the back end of their Elm app. I think NoRedInk is using some Rails and some Haskell. I've have a friend who uses Python for his back ends. Also heard that some people really like using F#, as well as Node. Or if you want to do Elm full stack there's https://lamdera.com/ https://lamdera.com/ or https://package.elm-lang.org/packages/choonkeat/elm-fullstack/latest/ https://package.elm-lang.org/packages/choonkeat/elm-fullstac....
danbruder 5y ago
we are using rust on the backend
- deleted 5y ago
  [deleted]
whichdan 5y ago
We're using Elixir on the backend at Corvus Insurance and it's quite nice.
girishso 5y ago
Any back end stack that can provide APIs, we're using .NET.
lucamug 5y ago
We use Kotlin

dzonga 5y ago

little anecdote: I did a couple of personal projects in elm in 2017. one thing I'm thankful for it taught me functional programming. Elm was easy to start with for someone new to functional programming. it also taught me, one important lesson - the market doesn't really care. a company when you're looking for a gig doesn't care if you know elm, it wants you to know the 'framework'they're using currently. so yeah, I see elm being a dead end. either people using it already solved product/market fit. but for a startup getting off the ground - elm offers no benefits at all compared to js.

wolfadex 5y ago
I had the opposite experience with my last job interview. I didn't know any Ember but I did know Elm (and other languages and frameworks). My enthusiasm about Elm absolutely contributed to my being hired and my lack of Ember knowledge didn't hurt me. This was what the hiring manager told me.

tmm84 5y ago

The part of the article that I was waiting for was how they got it adopted in Japan. Having worked in Japan for almost a decade I can easily say it is not an easy feat to change Japanese corporate mindset when it comes to a programming language or environment. I wonder what the elevator sales pitch was. Other than that I think this was a great article.

lucamug 5y ago
Even though Rakuten is a Japanese company and all this happened in Japan, the department where it happened is almost entirely not Japanese, so the "elevator sales pitch" has nothing to do with Japan. There were already several developers that were on board with Functional Programming, this is what helped a lot. As a matter of Japan, there is a very lively Elm community and I know few companies that use Elm in production. Also, I heard that the Japanese academic world is active in Functional Programming research

b7bfcdeaab33 5y ago

"the order in which we write the code doesn’t matter" What do you lose in this trade off?

lucamug 5y ago
Interesting question. I feel that I don't lose nothing with this feature, but maybe someone else may have a deeper insight

mchusma 5y ago

Rakuten is basically a scam on merchants right? By that I means they use affiliate links to make money. But most of their referred traffic comes from people checking out and saying "I use rakuten to get a discount at the places I already shop". The stores then don't know how much business rakuten is really bringing them, so are scared to stop it. Consumers keep checking rakuten to see if they get discounts on things they want, because why not? Is this a good summary? Anyone have a more favorable impression of their work (from the store perspective)?

nopcode 5y ago
Rakuten is a billion dollar company often referred to as the Amazon of Japan. They have a very different type of presence in different countries.