I think that it would be helpful if you provided examples about those things, good and bad. As it is it's mostly "erlang's" bad - perhaps if you offer the counterparts to what would be a better pick we could have a discussion - and then perhaps see how far the tree of dependencies goes on each side? And also what you would loose by picking up those solutions?
Just taking on some random stuff:
> Trivial pattern matching is replaced by this, and to be honest, non-trivial pattern matching is probably a code smell if not an antipattern; if you're reaching three levels down into a data structure
If the data structure is being accessed in a module to deal with it specifically then that is part of the knowledge of the module. And you can't escape that with or without pattern matching, since you'll have to codify those things in code anyway, be it long chains of ifs, switches, or whatever, you'll always have to write the code with the same level of knowledge about the data structure to express the same conditions?
> Modern Erlang performance is meh;
This I'm not sure. I've seen libs written in elixir beat libs written in C++ and they had to start a VM to be run. Obviously there will be plenty of stuff that a low level language can do more efficiently and faster I don't think anyone disagrees with that - but I think sometimes people sell erlang and elixir's speed short.
> but the entire gen_server set up, with its initialization phase and its three proscribed ways to call it and the need for an explicit "gen_server" module type are largely the creation of Erlang in the first place
I haven't seen any language with the concept of an independent program, that has a synchronous interface (mailbox), but can be modelled entirely asynchronously, and can't block whatever running loop. (and I read your other reply and thread).
There's also a reason why some things have a particular way of being set up inside the beam, and that's mostly related to the guarantees it provides and with the fact that processes are transparent across nodes. If you take out the impossible to block scheduling and network transparency you'll be of course able to spin up something similar to a GenServer without the same "ritual" - but it no longer has anything to do with the former perhaps except its API?
> A modern message bus like Kafka or the dozen other choices doesn't impose an implementation language on you, nor does it impose that implementation language being the only one.
Given that you can have any socket, tcp or not, and easily handle it, this doesn't seem to be a fair point. On kafka or any other message bus the implementation language will be that of the sources and sinks communicating with kafka? Or you just write kafka and the other programs wake up as insects in a bed?
> Mnesia, a clustered DB was a neat idea, but in 2021 is so poorly featured and unreliable it doesn't even qualify as one anymore; nobody in their right mind would bring up an Erlang cluster just to back some other language's code to Mnesia as a database
I haven't used mnesia at scale and indeed heard people complaining about it, more than once so there's probably some issues there - having said that, in terms of similar db's (KV based and not SQL,etc) even db's like MongoDB and such need expensive and usually paid managing solutions right? And can still loose data unless you really cover your redundancy?
> But in 2021, you can do not just "better" than Erlang for all of them, you can do much better.
Could you tell us succinctly how? As a, usually, solo developer I would be really interested in knowing, and I'm not asking sarcastically.
I also don't understand how it's difficult to integrate Erlang with other things, it basically has a standard lib very accommodating of sockets and inter process communication through STDIN/OUT, with effective monitoring on top.