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

This summarizes it perfectly. We are not saying “we don’t need redis”, we are rather saying that redis is not a strong requirement from day one as seen elsewhere. As a platform, Erlang/OTP gives the ability to reduce operational complexity in some cases, and to accept this complexity as a starting point because “that’s the way everyone does things” or because “we already have so much complexity anyway” would be a mistake. Of course there are still many situations were Redis is useful, and it is productive to everyone to double-check when that’s actually the case.

I also dispute the perception these operational tools are ignored by the community. There is Redix (maintained by an Elixir Core Member). Tristan, myself, and others have written about k8s+Erlang and there is bonny for k8s control. brod (from Klarna) and broadway_kafka for Kafka, etc. Phoenix includes a Dockerfile in its official deployment guides and it will ship with a Dockerfile generator in the next release. Of course we don’t support everything under the sun but we definitely recognize that they are necessary for a wide range of applications and systems.

Sometimes it feels we are trapped in this three-year old rhetoric that “Elixir/Erlang does not like k8s/Docker/etc” while a large chunk of the community has moved on to recognize and accept its pros and cons.

So supposedly making a REST request is complicated and requires advanced technical expertise, but dealing with nginx, sidekiq (which requires running an external worker), and redis isn’t? I’m gonna have a very hard time accepting that

The (admittedly not fully realized) potential of BEAM is the fact that you need to only learn the programming language and that can take you very far. This reduces the amount of technologies that needs to be mastered, and simplifies the life for everyone on the team. But beyond that, less external technologies reduce the disconnect between dev, test, and prod. Perhaps I was on wrong teams, but none of us usually ran nginx or sidekiq locally. This led to occasional production bugs b/c the stuff not running locally or on CI is the stuff untested.

In contrast, Phoenix can handle many of the reverse proxy features you mentioned. It is used equally on all machines (dev, staging, prod), requires minimum extra operational overhead, and is easily testable.

If you want to obtain an SSL certificate via Let’s Encrypt, take a look at site_encrypt. You can get it working in a matter of minutes and it won’t require installing anything else on the side. And you use the language you normally use to work with it, so no need to learn a special flavour of yaml, ini, or anything like that. That language is compiled, so syntax errors are immediately detected during compilation, while semantic errors (e.g. misspelling of the domain name) can be detected in tests. Since the interface is a programming language, there’s a lot of flexibility (like e.g. fetching input parameters from OS env or some secure store), and the stuff works equally well in local dev and test without requiring anything running on the side. Since site_encrypt periodically renews the certificate it runs a periodic job without requiring any extra OS process or external component. Using vanilla OTP supervision tree, the job scheduler binds itself to the Phoenix endpoint, so if the endpoint is stopped, the job will be stopped too, thus avoiding running a certification that is bound to fail. For more details see this post on site_encrypt and this post on periodic jobs.

Compared to using nginx + certbot this gives me simpler usage, simpler operation (less moving parts), reduced dev/prod mismatch, better testability, and more flexibility. To me these are the very important benefits, and this is where I see a huge potential of BEAM. I’ve had enough first hand practical evidence of it to be convinced. I’ve also had the pleasure of working on systems powered by a bunch of moving parts, and I don’t feel like going back to that

Just to be clear I don’t hesitate to use external components where it makes more sense. I agree that external database is frequently needed (though oddly enough I managed to get away without it on a few occasions), but other than that I think that many projects can do just fine without needing reverse proxies, redises, external message queues, cronjobs, & such. I’m not saying that these tools are bad per se, but I prefer exploring more lightweight built-in options and move to these tools only when there’s justified need.