{"id":376,"date":"2026-11-06T08:41:23","date_gmt":"2026-11-06T12:41:23","guid":{"rendered":"https:\/\/juredev.com\/blog\/?p=376"},"modified":"2026-11-07T13:55:04","modified_gmt":"2026-11-07T17:55:04","slug":"go-lenguaje-simplicidad-infraestructura-moderna","status":"publish","type":"post","link":"https:\/\/juredev.com\/blog\/2026\/11\/go-lenguaje-simplicidad-infraestructura-moderna\/","title":{"rendered":"Go: el lenguaje que eligi\u00f3 la simplicidad y conquist\u00f3 la infraestructura moderna"},"content":{"rendered":"\n

A finales de la d\u00e9cada de 2000, compilar una base de c\u00f3digo grande en Google pod\u00eda tardar minutos\u2026 y a veces bastante m\u00e1s. Multiplica esa espera por todo un equipo de ingenieros y de repente tienes un problema caro, frustrante y que se come la productividad. Para colmo, a medida que los proyectos crec\u00edan, el software se volv\u00eda cada vez m\u00e1s dif\u00edcil de leer y de mantener.<\/p>\n\n\n\n

Go<\/a> naci\u00f3 precisamente en ese contexto pr\u00e1ctico, no en un laboratorio acad\u00e9mico. Lo dise\u00f1aron Robert Griesemer, Rob Pike y Ken Thompson, y su meta nunca fue crear el lenguaje m\u00e1s expresivo ni el m\u00e1s innovador sobre el papel. Quer\u00edan algo m\u00e1s modesto y, sobre todo, m\u00e1s \u00fatil: resolver problemas reales de productividad y escalabilidad en sistemas de gran tama\u00f1o.<\/p>\n\n\n\n

En este art\u00edculo vamos a repasar las decisiones que definen a Go<\/a> (incluidas las que dej\u00f3 fuera a prop\u00f3sito) y por qu\u00e9 termin\u00f3 convirti\u00e9ndose en una pieza clave de la infraestructura actual.<\/p>\n\n\n\n

Simplicidad como decisi\u00f3n de dise\u00f1o<\/h2>\n\n\n\n

Go es peque\u00f1o a prop\u00f3sito. En lugar de ir acumulando caracter\u00edsticas sint\u00e1cticas cada vez m\u00e1s complejas, se queda con un conjunto reducido de piezas. As\u00ed, un programador que ya tiene experiencia en otros lenguajes puede volverse productivo en d\u00edas, no en semanas.<\/p>\n\n\n\n

La l\u00f3gica es bastante directa: cuantas menos abstracciones innecesarias haya, m\u00e1s f\u00e1cil resulta leer, entender y mantener el c\u00f3digo de otras personas. En equipos grandes y bases de c\u00f3digo que viven muchos a\u00f1os, esa legibilidad deja de ser un detalle est\u00e9tico y se convierte en una verdadera ventaja competitiva.<\/p>\n\n\n\n

Goroutines: concurrencia casi gratis<\/h2>\n\n\n\n

El modelo de concurrencia es una de las mayores aportaciones de Go. En vez de depender de los hilos pesados del sistema operativo, el lenguaje ofrece goroutines: unidades de ejecuci\u00f3n muy ligeras que se lanzan simplemente anteponiendo la palabra clave go a una llamada de funci\u00f3n.<\/p>\n\n\n\n

go procesarTarea(datos)<\/code><\/pre>\n\n\n\n
Con esa sola palabra, la funci\u00f3n empieza a correr de forma concurrente. El runtime de Go se encarga de repartir las goroutines sobre un n\u00famero reducido de hilos del sistema, as\u00ed que es posible mantener miles (e incluso cientos de miles) de tareas simult\u00e1neas con un impacto m\u00ednimo en memoria y recursos.<\/p>\n\n\n\n
Lanzar mil tareas a la vez es tan simple como un bucle. Y con sync.WaitGroup esperamos a que todas terminen:<\/p>\n\n\n\n
var wg sync.WaitGroup\n\nfor i := 1; i <= 1000; i++ {\n    wg.Add(1)\n    go func(id int) {\n        defer wg.Done()\n        procesarTarea(id)\n    }(i)\n}\n\nwg.Wait() \/\/ bloquea hasta que terminen las 1000 goroutines<\/code><\/pre>\n\n\n\n
Channels: comunicar en lugar de compartir<\/h2>\n\n\n\n
Lanzar miles de goroutines sirve de poco si no tienes una forma limpia de coordinarlas. Para eso existen los channels<\/strong> (canales), inspirados en el modelo de Communicating Sequential Processes<\/em>. Permiten que las goroutines intercambien datos de forma segura y desacoplada.<\/p>\n\n\n\n
resultados := make(chan string)\n\ngo func() {\n    resultados <- procesarTarea(datos) \/\/ env\u00eda el resultado por el canal\n}()\n\nfmt.Println(<-resultados) \/\/ espera y recibe<\/code><\/pre>\n\n\n\n
La filosof\u00eda que hay detr\u00e1s la resumi\u00f3 Rob Pike en una frase que ya se ha convertido en un proverbio del lenguaje:<\/p>\n\n\n\n
\n
\u00abDon’t communicate by sharing memory; share memory by communicating.\u00bb<\/p>\n<\/blockquote>\n\n\n\n
Traducido a la pr\u00e1ctica: en lugar de sincronizar el acceso a memoria compartida (que suele ser una fuente habitual de bugs dif\u00edciles de reproducir), las goroutines se pasan mensajes de forma expl\u00edcita. El resultado es c\u00f3digo concurrente m\u00e1s predecible y mucho m\u00e1s f\u00e1cil de razonar.<\/p>\n\n\n\n
Un patr\u00f3n muy habitual es el worker pool: varias goroutines toman trabajo de un mismo canal y devuelven sus resultados por otro.<\/p>\n\n\n\n
func worker(tareas <-chan int, resultados chan<- int) {\n    for t := range tareas {\n        resultados <- t * 2\n    }\n}\n\nfunc main() {\n    tareas := make(chan int, 100)\n    resultados := make(chan int, 100)\n\n    for w := 0; w < 3; w++ {\n        go worker(tareas, resultados)\n    }\n\n    for i := 1; i <= 10; i++ {\n        tareas <- i\n    }\n    close(tareas)\n\n    for i := 1; i <= 10; i++ {\n        fmt.Println(<-resultados)\n    }\n}<\/code><\/pre>\n\n\n\n
Y con select<\/code> podemos esperar a varios canales a la vez, por ejemplo para poner un l\u00edmite de tiempo:<\/p>\n\n\n\n
select {\ncase r := <-resultados:\n    fmt.Println(\"listo:\", r)\ncase <-time.After(2 * time.Second):\n    fmt.Println(\"tiempo agotado\")\n}<\/code><\/pre>\n\n\n\n
Lo que Go decidi\u00f3 no tener<\/h2>\n\n\n\n
La identidad de Go se define tanto por lo que incluye como por lo que dej\u00f3 fuera de forma consciente:<\/p>\n\n\n\n