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.
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 :)
> 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.
> 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.
> 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.
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.
> 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.
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
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.
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:
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.
I'm not an Elm veteran like a lot of the folks here, but I think an aspect of Elm is that a lot of the traditional ways that people expand ecosystems are discouraged by Elm's approach. For instance, components are hard to do in Elm and are discouraged in the documentation[1].
So my own personal Elm projects have involved a lot of reading other code and often copying and modifying open source code, but it's hard to wholesale import components in the way that JavaScript and other languages do it. My experience with the language is that it is very easy to do what I want in it, but it seems more difficult to share that as an open source contribution in Elm than in similar languages.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
> 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.
FWIW our experience has been:
- finding devs with experience is hard
- finding great devs who want to use interesting tooling is easy
In the end, we hire interesting, curious devs, and ask them to use tooling (elm) that has a pretty shallow learning curve.
I think bootstrapping a project in Elm without any experience on the team could be tough, but once you have some expertise, the seeds you plant in yield abundant fruit. At NoRedInk it's been a great success -- especially with regards to "finding other developers".
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.
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.
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.
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
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.
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.
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.
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.
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.
[+] [-] PragmaticPulp|4 years ago|reply
> 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.
[+] [-] whateveracct|4 years ago|reply
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 :)
[+] [-] aranchelk|4 years ago|reply
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.
[+] [-] dimitrios1|4 years ago|reply
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.
[+] [-] lhorie|4 years ago|reply
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.
[+] [-] theobeers|4 years ago|reply
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.
[+] [-] mjaniczek|4 years ago|reply
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.
[+] [-] aszen|4 years ago|reply
[+] [-] folex|4 years ago|reply
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.
[+] [-] jaeming|4 years ago|reply
See posts like these for more details and comments:
https://news.ycombinator.com/item?id=16510267
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/#/
And Bucklescript TEA with Ocaml or Reason: 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/
[+] [-] mechelephant|4 years ago|reply
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.
[+] [-] aeturnum|4 years ago|reply
So my own personal Elm projects have involved a lot of reading other code and often copying and modifying open source code, but it's hard to wholesale import components in the way that JavaScript and other languages do it. My experience with the language is that it is very easy to do what I want in it, but it seems more difficult to share that as an open source contribution in Elm than in similar languages.
[1] https://guide.elm-lang.org/webapps/structure.html
[+] [-] agbell|4 years ago|reply
His experience working at a teaching company made his book very well structured for new comers.
[+] [-] arcade79|4 years ago|reply
(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').
[+] [-] fatnoah|4 years ago|reply
[+] [-] wing-_-nuts|4 years ago|reply
[+] [-] ferdowsi|4 years ago|reply
[1]https://news.ycombinator.com/item?id=22821447 [2] https://www.reddit.com/r/elm/comments/7zk0dy/is_evan_killing...
[+] [-] StefanWestfal|4 years ago|reply
[+] [-] dmix|4 years ago|reply
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|4 years ago|reply
[+] [-] StefanWestfal|4 years ago|reply
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.
[+] [-] dsiegel2275|4 years ago|reply
[+] [-] roebk|4 years ago|reply
[+] [-] mouzogu|4 years ago|reply
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|4 years ago|reply
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/
[+] [-] MichaelGlass|4 years ago|reply
In the end, we hire interesting, curious devs, and ask them to use tooling (elm) that has a pretty shallow learning curve.
I think bootstrapping a project in Elm without any experience on the team could be tough, but once you have some expertise, the seeds you plant in yield abundant fruit. At NoRedInk it's been a great success -- especially with regards to "finding other developers".
[+] [-] tempest_|4 years ago|reply
It is a bit off putting.
It is nice to see a different perspective.
[+] [-] z5h|4 years ago|reply
[+] [-] razze|4 years ago|reply
[+] [-] tmm84|4 years ago|reply
[+] [-] lucamug|4 years ago|reply
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
[+] [-] Existenceblinks|4 years ago|reply
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.
[+] [-] GiorgioG|4 years ago|reply
[+] [-] G4BB3R|4 years ago|reply
[+] [-] razze|4 years ago|reply
[+] [-] adelarsq|4 years ago|reply
[+] [-] frozenlettuce|4 years ago|reply
[+] [-] dzonga|4 years ago|reply
[+] [-] wolfadex|4 years ago|reply
[+] [-] mchusma|4 years ago|reply
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)?
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] neals|4 years ago|reply
[+] [-] deergomoo|4 years ago|reply
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.
[+] [-] agumonkey|4 years ago|reply
[+] [-] osener|4 years ago|reply
[+] [-] aaronchall|4 years ago|reply
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|4 years ago|reply