"The concurrency characteristics of the systems I hack on every day would be much harder to model without GenServers. It's not particularly surprising that Erlang is not the only way to solve a problem in software engineering, there is no silver bullet."

Erlang was at one point the only way to get this sort of structure, though.

Now it isn't. Multiple languages like Go have lightweight coroutine-y type things; if the isolation isn't perfect, you can fix it with programming discipline. There's also Pony, and Rust which has its own thing which is in its own way far stronger than what Erlang offers. Async/await languages are very amenable to setting up lots of little process-like things, to the point that arguably it's the only sane way to structure your programs in such languages. There is a real change in Erlang being almost the only thing on offer, to merely being one choice of a whole bunch and no longer being impressive enough to justify the lockin. (Not that Erlang uniquely has lock in; all languages have lock simply by virtue of the fact that once code is written in X you can't just change it to Y one day. But it's not worth the lock in anymore.)

>Erlang was at one point the only way to get this sort of structure, though.

It still is though! Isolated processes with asynchronous, dynamic message passing requires really heavy libraries in most other languages. Rust is completely different, I can't fathom why you'd compare them in this way.

Because as I've said, I'm not comparing solutions, I'm comparing problems. Rust solves the isolation problem in a completely different way. Go also solves the isolation problem by enforcing it at a language community and best practice level, rather than rigidly enforcing it in the language. Now, I personally wish it had something more like Erlang or Pony, but, at the same time... it's doing fine without it and completely satisfying my Erlang use cases in real code, better than Erlang did. Not perfectly, but fine. (I rather prefer channels as a default to Erlang's message passing, which in both my opinion and experience has the "unbounded buffer" problem in that messages can build up in a queue forever.)

Message buses solve the message passing requirement. You can get a whole range of solutions from "just sling vaguely JSON stuff around" to "here's a whole strongly typed protocol", with a whole array of options on persistence, clustering, language support, etc., a whole array of options around how synchronous they are and what guarantees they provide, rather than Erlang's one exact solution,

You're kind of demonstrating my exact point here... it isn't that the exact Erlang solution shows up in other languages, the point is that the problem space that Erlang covers is now covered in plenty of other languages, in all sorts of ways, many of them better for some task than Erlang's one point in the space that was selected very, very early in the exploration process. This was not the case 20 years ago. It is now. And I don't particularly think Erlang's coverings of the problem space are the best. People not already deep into Erlang aren't evaluating whether or not some solution is exactly like Erlang, they're evaluating whether the solution is a good solution on its own terms, and once you remove the "must be exactly like Erlang" clause there are a lot of better choices for every element of Erlang, except arguably, the integration of all of them together.

I understand your argument, I guess what I'm trying to say is that I don't think these arguments are unique to Erlang, you could make these arguments about the use of any language to solve almost any problem, outside of kernel programming. I choose tools based on how they fit with how I want to solve problems.

> you can fix it with programming discipline

You can write distributed coroutines in assembly with enough programming discipline. What is interesting in a language is not what it lets you do, it's what it prevents you from doing.