You raised some valid points, and I can see how various issues combined can lead to frustration. I’ve been using BEAM languages for the past decade, and while I’m in general a happy user, I agree that there’s a lot of room for improvement 
In particular, I think that the lack of strong typing is a big deficiency, and I’m hoping that some of the ongoing initiatives will address this. If projects such as Gleam reach enough maturity I could see myself migrating to them, at least partially.
I also agree that ecosystem is far from perfect, in terms of size, as well as support. It is indeed worrying that some of the prominent libraries are developed as a private effort of a few individuals, with lot of the work probably done outside of working hours.
All that being said, I’m still in general a very happy user of BEAM languages, and I believe that they are by far the most suitable options for building fault-tolerant soft real-time backends of any size and complexity. Projects such as WhatsApp have demonstrated that BEAM can take us very far, but at the same time, in my experience BEAM languages, especially Elixir, excel at building small scale simpler systems. I’ve worked on a couple of such systems which were implemented completely in a single BEAM language, as a single project, running as a single standalone OS process in production, requiring no external dependency at all. One interesting example was a proprietary CI server, a sort of hard-coded Circle/Travis/Jenkins, which had to deal with all of the standard CI challenges, such as monitoring changes in a remote repo, running multiple concurrent builds, managing load and concurrency, dealing with docker containers, caching, running scheduled jobs, persisting state, etc. All of that was implemented as a single standalone Elixir OTP app, using nothing else on the side. I’m not aware of any other technology that would allow me to reduce the operational complexity so much.
As a smaller-scale example of the kind of simplification we can get with BEAM, take a look at my site_encrypt library, which I’ve also showcased in this blog post. Again, I’m not certain that such level of operational simplification can be achieved outside of BEAM, at least not with the similar set of guarantees.
It’s probably impossible to asses objectively, but I personally believe that these benefits are much more important than the downsides I’ve experienced. For example, when I was building a CI, I needed to interact with GitHub graphql API, and had to implement the client from scratch. It took me about a day to research the docs and get a working prototype, and then a few more days to write a proper solution. In a richer ecosystem I might be able to find a library and solve this in a matter of an hour or so. This seems like a radical time overhead, but in the grand scheme of things it was insignificant, because the bulk of the time was spent on the essential domain logic where no library could help me. Such has been my general experience in the past decade of working with BEAM. Sure, I occasionally had to reimplement some wheel manually, such as a basic client for an external service. But usually most of the work was spent on the actual domain logic, and so this occasional overhead didn’t add up to anything significant.
In the end, it comes down to how each of us values given pros & cons, and it depends on what are the challenges we’re trying to solve. For example, I agree that BEAM is not a good fit for some domains, such as GUI apps, CLIs, fast numerical processing, etc, and I usually advise people to look for something else for such domains. But, like @josevalim, I’m not sure that any language/runtime will be a good at everything. I believe that BEAM is a great fit for fault-tolerant soft real-time systems precisely because this is the thing it focuses on.
In any case, while I may disagree with some of your points, I still think you raised valid concerns, and that’s always a good thing.
One final minor comment to the point from your gist:
Umbrellas as a project structure are an extremely permeable form of “isolation” and in my mind provide neutral or negative value to one’s architecture. Elixir has no concept of module-level privacy or hierarchy, only public and private functions
I share your sentiments about umbrellas, and I’ve never used them myself. The boundary project is my attempt to tackle this issue in a different way. Feedback is welcome
