From Python to Go: el cambio mental siendo SRE

No fue difícil. Fue incómodo.

Hace unos meses decidí aprender Go de verdad. No el típico “hola mundo”, sino meterse en serio. Y lo que descubrí es que Go no es simplemente “Python con otra ropa”. Es como cambiar de coche: la primera semana todo te duele, no encuentras nada, y te preguntas por qué no te quedaste con el tuyo.

Pero al final te das cuenta de que está diseñado de forma completamente diferente.

El primer shock: los errores no explotan

En Python, si algo falla, Python te lanza una excepción a la cara y punto. Boom. El programa se detiene, ves un error rojo gigante, y listo.

En Go, los errores son… tranquilos. Devuelven un valor como si nada.

archivo, error := os.Open("config.json")
if error != nil {
    // Tú decides qué hacer
}

La primera vez que ví esto pensé: "¿Eso es todo? ¿Dónde está el drama?"

Pero aquí viene lo raro: Go te obliga a decidir. ¿Qué haces si el archivo no existe? ¿Lo intentas de nuevo? ¿Lo loggueas? ¿Le das un valor por defecto? Go dice: “Tú decides. Yo solo te aviso que pasó algo.”

Al principio es molesto. Escribes if error != nil cien veces y piensas “¿por qué no me lo hace automático?” Pero cuando trabajas en producción a las 3 AM buscando por qué se cayó un servicio, descubres que Go te regalo el lujo de saber exactamente dónde falló.

El segundo shock: los threads son gratis

En Python, crear un thread es como comprar un Rolex. Son caros. Pesados. Y si creas muchos, el programa va al traste.

En Go, crear un “thread” (que aquí se llama goroutine, pero es básicamente lo mismo) es como comprar un chicle. Gratis. Ligero.

for i := 0; i < 1000000; i++ {
    go hacer_algo()
}

Eso funciona. Un millón de goroutines corriendo en paralelo sin problema. Prueba eso en Python y el ordenador se quema.

Lo loco es que Go fue diseñado específicamente para eso. Los tíos que lo crearon pensaron: “¿Y si la gente pudiera crear threads como si nada?” Y pasó lo que tenía que pasar: la gente crea un montón sin miedo.

El tercer shock: la comunicación entre threads es rara pero funciona

En Python, si dos threads necesitan hablar, te duele la cabeza. Necesitas locks, semaforos, toda una coreografía.

Go dice: “¿Sabes qué? No vamos a compartir datos. Vamos a que un thread le pase información al otro como si estuviera mandando un mensaje.”

Se llama “channel” y es básicamente un tubo.

mensajes := make(chan string)

go func() {
    mensajes <- "Hola desde otra goroutine"
}()

msg := <-mensajes

Uno escribe en el tubo, otro lee. Simple. Sin locks. Sin que dos hilos pisotéen el mismo dato al mismo tiempo.

Es contraintuitivo. ¿Pasar datos entre threads sin proteger el dato? Sí. Porque el dato no está compartido — se mueve de uno a otro. Cuando lo piensan con esa mentalidad, tiene sentido.

Lo que aprendí

Aprender Go no fue un problema de sintaxis. Fue un problema de forma de pensar.

Python te enseña: “Haz lo que quieras, rápido, y si explota lo debugueamos después.”

Go te enseña: “Piensa primero. ¿Qué pasa si esto falla? ¿Cómo comunicas entre procesos? ¿Realmente necesitas eso?”

Es menos libertad. Pero es más seguridad. Y en un sistema que corre 24/7 sin que puedas resetear cada 5 minutos, esa seguridad es oro.

¿Debería aprenderlo?

Si trabajas en infraestructura o DevOps, sí. Todas las herramientas que usamos — Kubernetes, Docker, Prometheus — están escritas en Go. Entender Go es entender cómo funcionan esas herramientas.

Si eres programador y quieres entender un lenguaje diseñado de forma diferente a lo que conoces, definitivamente sí.

¿Será cómodo? No. Los primeros dos meses te va a frustrar. Vas a escribir código que Go rechaza porque “eso no se hace así”. Vas a buscar en Stack Overflow “por qué Go es tan terco” (spoiler: no es terco, solo honesto).

Pero del otro lado hay un lenguaje pensado para sistemas que tienen que funcionar. Sin excusas. Sin “pero es que falla a veces”. Sin drama.

Y eso, al final, vale la pena.