Uno de los argumentos de la expositora es que como GO hace autom\u00e1ticamente esto tu ya no te debes preocupar, que Go se encargar\u00e1 de aprovechar al maximo los n\u00facleos en tu CPU y que asi evitas que (usando otra cosa aparte de Go), como programas en un lenguaje que no hace esto autom\u00e1tico entonces gastar\u00e1s mas y mas en hardware.<\/p>\n
En primera, si es solo un desarrollador que la hace de arquitecto y programador, que toma las desiciones sobre el lenguaje de programaci\u00f3n, base de datos y metodos de programaci\u00f3n, que por sus tanates decidi\u00f3 no usar concurrencia y no te interesa, entonces bien merecido lo tienes<\/strong>, paga mas por no involucrarte en tu proyecto.<\/p>\n Si te involucras en tu proyecto te dar\u00e1s cuenta que usando concurrencia probablemente puedas mejorar el rendimiento de tu aplicaci\u00f3n\/servicio al utilizar mas n\u00facleos\u00a0y urgir\u00e1s al desarrollador a que lo haga asi.<\/p>\n Si eres solo el coordinador\/lider de proyecto entonces 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\u00f3n lo va a hacer todo.<\/p>\n Lanzar un proceso nuevo (multiproceso) es muy facil, sobre todo en Unix, algo que incluso en BASH script es facil de hacer, la comunicaci\u00f3n entre procesos es algo mas complicado pero lanzar nuevos procesos es f\u00e1cil. Puede ser “caro” si corre con todo el Stack de memoria por duplicado, ahi es donde se puede optimizar.<\/p>\ntienes<\/del>\u00a0deber\u00edas 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.<\/p>\n