They are mostly okay but I find their caveats tiring to mentally keep track of.
As a fairly experienced dev I prefer the technology to slap me hard on the cheek and not make me triple check things.
But Golang's concurrency is definitely a big step up from all the naked multithreading we had to endure and groom for decades -- that is unequivocally true!
I still find Erlang/Elixir's message passing paradigm superior though. Plus every "process" there (a fiber / green thread basically) is being transparently parallelized on another CPU core without you thinking about it at all.
As a personal scoreboard:
1. Erlang/Elixir's messages.
2. OCaml's "domain" effects (mutable shared state managed by multiple threads in a safe manner).
I'll add - the synchronous by default, typed nature of Golang creates a massive amount of bookkeeping, as well as some fault tolerance issues you can walk into trying to build a robust service. It's definitely better than handling raw threads, but Erlang/Elixir beat it hands down.
As a fairly experienced dev I prefer the technology to slap me hard on the cheek and not make me triple check things.
But Golang's concurrency is definitely a big step up from all the naked multithreading we had to endure and groom for decades -- that is unequivocally true!
I still find Erlang/Elixir's message passing paradigm superior though. Plus every "process" there (a fiber / green thread basically) is being transparently parallelized on another CPU core without you thinking about it at all.
As a personal scoreboard:
1. Erlang/Elixir's messages.
2. OCaml's "domain" effects (mutable shared state managed by multiple threads in a safe manner).
3. Golang's channels and messages.