(2) and if Go is lacking in the concurrency department and loses to Erlang in latency. Why don't people use Erlang/Elixir for servers and Python/etc for client side?
In reply to your first question, I don't think it does. Go and Rust were both initially marketed as "systems" languages, but in reality they make very different design trades. I would say that Go lines up more with Java or C# than it does with C or Rust. I would guess that having both Rust and Go in your toolkit will be a benefit in the future.
Because Erlang is different. It's not just the syntax, even though that throws many people uncomfortable with much that's not a direct descendant of C syntax; it's the whole programming model which requires a real shift in perspective that simply isn't easy.
It's worth it once you start to "get it", but that can take a bit.
I do think Elixir gives the Erlang VM a better shot at the big time, because it lessens the syntax obstacle for many people.
> an extremely robust, highly opinionated event loop with its very own DSL
It's very reductive. Erlang is a distributed platform with a functional programming language, lightweight processes communicating through distributed asynchronous shared-nothing message passing, preemptive scheduler, etc.
(2) People tend to follow the path of least resistance even if not the most optimal. Erlang requires more effort in the beginning, but pays off immensely later on. It's easier to start learning go because it's not as strange. This is also why node.js became so popular. It has the lowest barrier to entry.
(1) where does Rust fit in this?
(2) and if Go is lacking in the concurrency department and loses to Erlang in latency. Why don't people use Erlang/Elixir for servers and Python/etc for client side?