Elm at Rakuten

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.

That has arisen a few times here. Yes, they actually do actively discourage forking (to the point of threatening “excommunication” from the community).

On top of this, the community is run like a dictatorship. Dissent is silenced and banned, and faux positivity is spread far and wide. I got sick of it and was banned from the Elm subreddit after I expressed my frustration. That's pretty much when I gave up on the language, years ago, on version 0.18 (fwiw, they're on version 0.19 now, that's how slow updates are)

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.

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 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.