4 ms·

Yeah, Go has the worst possible model for concurrency there is - shared memory multithreading. Hopefully more and more companies will realize how bad this model

Yeah, Go has the worst possible model for concurrency there is - shared memory multithreading. Hopefully more and more companies will realize how bad this model really is and start looking into languages with decent concurrency models, like Erlang and Elixir or at least stick to event loops.

43224gg252 9y ago
>Go has the worst possible model for concurrency there is I don't know a single person who would agree with this. The reason companies don't use Elixir and Erlang is because they're a pain in the ass to use and maintain. They have to spend six months looking for a decent dev and if he ever quits no one will ever be able to maintain the code base again. Companies hire Go developers because Go is a language that makes them extremely productive, makes it hard for developers to write bad code and make mistakes (compared to other languages) and if you use the go tools and follow Go standards then every Go code base looks really similar, it doesn't matter if the dev quits because anyone will be able to maintain their code. Plus Go devs are much easier to train. The list could just go on and on.
innocentoldguy 9y ago
That is exactly why I use Erlang and Elixir, and not Go. Also, Go processes are 10 times the size of those in Elixir.
- billrobertson42 9y ago
  What are you measuring? Memory use?
falcolas 9y ago
I give you Python and Ruby as worse - shared memory and an interpreter lock to limit concurrent operations. That said, Go is the best of the C-style concurrency breed; having typed message passing and green threads built into the language.
twic 9y ago
The worst possible model? Oh my dear fellow, not even close: http://catb.org/esr/intercal/ick.htm#Multithreading-using-COME-FROM http://catb.org/esr/intercal/ick.htm#Multithreading-using-CO...
- rrdharan 9y ago
  My favorite is still the multithreaded apartment model... https://blogs.msdn.microsoft.com/larryosterman/2004/04/28/what-are-these-threading-models-and-why-do-i-care/ https://blogs.msdn.microsoft.com/larryosterman/2004/04/28/wh...

43224gg252 9y ago

>Go has the worst possible model for concurrency there is I don't know a single person who would agree with this. The reason companies don't use Elixir and Erlang is because they're a pain in the ass to use and maintain. They have to spend six months looking for a decent dev and if he ever quits no one will ever be able to maintain the code base again. Companies hire Go developers because Go is a language that makes them extremely productive, makes it hard for developers to write bad code and make mistakes (compared to other languages) and if you use the go tools and follow Go standards then every Go code base looks really similar, it doesn't matter if the dev quits because anyone will be able to maintain their code. Plus Go devs are much easier to train. The list could just go on and on.

innocentoldguy 9y ago

That is exactly why I use Erlang and Elixir, and not Go. Also, Go processes are 10 times the size of those in Elixir.

billrobertson42 9y ago
What are you measuring? Memory use?

falcolas 9y ago

I give you Python and Ruby as worse - shared memory and an interpreter lock to limit concurrent operations. That said, Go is the best of the C-style concurrency breed; having typed message passing and green threads built into the language.

twic 9y ago

The worst possible model? Oh my dear fellow, not even close: http://catb.org/esr/intercal/ick.htm#Multithreading-using-COME-FROM http://catb.org/esr/intercal/ick.htm#Multithreading-using-CO...

rrdharan 9y ago
My favorite is still the multithreaded apartment model... https://blogs.msdn.microsoft.com/larryosterman/2004/04/28/what-are-these-threading-models-and-why-do-i-care/ https://blogs.msdn.microsoft.com/larryosterman/2004/04/28/wh...