It very much is not. Erlang's primary goal has always been reliability. Not concurrency. Concurrency arose from a subset of the mechanisms Erlang "needed" to implement reliability, but was not a primary focus of the language (just look how long Erlang lived without an SMP-able runtime).
Yet this concurrency is pretty much the only Erlang feature that was ported to Go, in a much less reliable manner.
Now I picked out Erlang because it has ... garbage collection. I was replying to the parent saying that GC is utterly incompatible with a systems language.
Go and Rust are the new Erlangs in that they are the go-to language for system services above kernel level.
Erlang disallows shared memory in favour of per-process gc. Whether or not this is a good tradeoff in general is debatable but it is what makes the gc acceptable in soft-realtime environments. Go makes a different set of tradeoffs (shared mutable memory, whole process gc, no hot code reloading) which place it in a different niche to erlang.
> Wrong. Concurrency is not some accidental bolt-on in Erlang
You might want to read my comment correctly and avoid injecting things which are not in it. I did not say concurrency was "bolted on", I said it was not a primary goal of Erlang's design, it was merely one of the tool deployed to reach the over-arching goal of reliability.
> I was replying to the parent saying that GC is utterly incompatible with a systems language.
Can't say I've ever seen Erlang called a systems language. But in any case Erlang's design and VM structure does make it suitable for soft real-time (per-process shared-nothing[0] heaps independently GC'd with configurable initial heaps, allowing such things as never GC'ing a process at all). Go still's no Erlang.
It very much is not. Erlang's primary goal has always been reliability. Not concurrency. Concurrency arose from a subset of the mechanisms Erlang "needed" to implement reliability, but was not a primary focus of the language (just look how long Erlang lived without an SMP-able runtime).
Yet this concurrency is pretty much the only Erlang feature that was ported to Go, in a much less reliable manner.