I presume you’re refering to the part at 32:33 when I say that “BEAM distribution is plagued with a bunch of serious issues”. This definitely came out stronger than I intended (I guess I got carried away in the heat of the moment 
), and somewhat sloppy. What I wanted to say is that there are some issues & challenges with distributed BEAM (aka distributed Erlang). I talked about those issues during the Q&A, which is unfortunately not recorded, but you can find the summary in this Redis response.
First, it’s worth noting that distributed BEAM is not the only way how you can build distributed systems running on multiple machines. Many other languages don’t even have such high-level support for that, and people still build distributed systems with them, using various techniques such as coordinating through 3rd party services (e.g. database, message queue, k-vs such as etcd or Redis, …), and/or building their own in-cluster communication protocol on top of TCP or HTTP.
Nothing stops you from doing the same with BEAM languages, i.e. bypassing distributed BEAM completely. For example, you could use Oban to distribute jobs accross multiple instances of BEAM nodes which are not even connected into a cluster. A few months ago I advised one client to do exactly that, instead of trying to coordinate things using distributed BEAM, because I believe that in this particular case such approach would simplify things significantly. Over the past years I’ve seen various reports of people building large-scale distributed systems with Erlang and Elixir, but without using distributed BEAM. It’s worth mentioning Partisan as an example of this approach.
That said, I also acknowledged that people use distributed BEAM in production. I don’t think I’ve seen a single BEAM-focused conference where there wasn’t at least one talk about distributed BEAM in practice. So I definitely don’t think that distributed BEAM is not usable, it’s just that I think it’s not as simple as it could be, or as it look like in the demo (though admittedly, distributed systems are never easy).
Finally, in the talk I also mentioned that distributed BEAM issues are mechanical, and that they can be fixed with time and effort. Only a few days after I gave the talk, OTP 22 has been released with one important improvement in this area. I’ve seen some improvements in the ecosystem too. For example, I’m excited about the ra library, which seems like a really solid and well tested Raft implementation in BEAM. While this is still relatively low-level, I feel it could be used as a toolkit for building simpler-to-use higher-level abstractions for distributed systems.
So tl;dr I never said “don’t use Elixir for distributed systems”, and that’s definitely not what I meant to communicate when I mentioned that there are some issues
