Uno de los argumentos de la expositora es que como GO hace automáticamente esto tu ya no te debes preocupar, que Go se encargará de aprovechar al maximo los núcleos en tu CPU y que asi evitas que (usando otra cosa aparte de Go), como programas en un lenguaje que no hace esto automático entonces gastarás mas y mas en hardware.

En primera, si es solo un desarrollador que la hace de arquitecto y programador, que toma las desiciones sobre el lenguaje de programación, base de datos y metodos de programación, que por sus tanates decidió no usar concurrencia y no te interesa, entonces bien merecido lo tienes, paga mas por no involucrarte en tu proyecto.

Si te involucras en tu proyecto te darás cuenta que usando concurrencia probablemente puedas mejorar el rendimiento de tu aplicación/servicio al utilizar mas núcleos y urgirás al desarrollador a que lo haga asi.

Si eres solo el coordinador/lider de proyecto entonces tienes deberías tener conocimientos suficientes para exigir a los desarrolladores que lo hagan de esa forma si lo amerita, recordemos que no por tener 20 nucleos debemos ocupar los 20 nucleos ni todas las tareas requieren de mas de 1 nucleo.

Ahora, si bien Go puede ayudar esto, no deberiamos ser tan egoistas y pensar que solo nuestro servicio va a estar ahi, no debemos depender en que el lenguaje de programación lo va a hacer todo.

Lanzar un proceso nuevo (multiproceso) es muy facil, sobre todo en Unix, algo que incluso en BASH script es facil de hacer, la comunicación entre procesos es algo mas complicado pero lanzar nuevos procesos es fácil. Puede ser “caro” si corre con todo el Stack de memoria por duplicado, ahi es donde se puede optimizar.