A diferencia de Python o Java, Go compila directamente a instrucciones de máquina, produciendo un binario nativo. Esto no es un archivo de bytecode que necesita una máquina virtual (como la JVM) para funcionar, sino código que tu procesador entiende de forma directa. Gracias al enlace estático (static linking), el compilador empaqueta todas las librerías necesarias para que el programa funcione dentro de un único archivo ejecutable. Esta arquitectura es la que te permite, cuando llegues a producción, desplegar usando contenedores de Docker extremadamente ligeros con la instrucción FROM scratch, ya que el binario no necesita que instales Go ni ninguna otra herramienta en el servidor. Sin embargo, ten en cuenta que este binario es específico para la arquitectura donde se compiló; si lo construyes para Windows e intentas ejecutarlo en Linux, fallará. Además, si usas cgo para llamar a código en C, el binario dejará de ser totalmente autónomo y dependerá de librerías dinámicas del sistema operativo host, perdiendo esa ventaja de portabilidad absoluta.

package main

import (
	"fmt"
	"runtime"
)

func main() {
	// El paquete runtime nos permite inspeccionar el entorno en el que
	// se está ejecutando el binario nativo actual.
	fmt.Printf("Sistema operativo: %s\n", runtime.GOOS)
	fmt.Printf("Arquitectura de CPU: %s\n", runtime.GOARCH)

	fmt.Println("Este binario es nativo y no requiere un intérprete externo.")
}

Cuando ejecutas go build sobre este código, el compilador genera un archivo ejecutable que ya contiene toda la lógica para hablar con el kernel del sistema operativo. Fíjate en cómo utilizamos el paquete runtime para obtener runtime.GOOS y runtime.GOARCH: estas variables nos confirman que el binario “sabe” exactamente en qué máquina está corriendo porque ha sido diseñado para ese hardware específico.

Si tomas este archivo resultante y lo llevas a otro servidor con el mismo sistema operativo y arquitectura, funcionará de inmediato, incluso si en ese servidor no está instalado Go. Es importante que no confundas go run con el proceso real de producción; go run lo que hace es compilar en una carpeta temporal y ejecutarlo al instante, pero en un entorno real, siempre querrás el binario generado por go build.

El error frecuente

Un error común al intentar simplificar el despliegue es usar cgo para integrar librerías de C sin darte cuenta de que estás rompiendo la naturaleza estática de Go.

package main

/*
#include <stdio.h>
*/
import "C"

func main() {
    // Esto requiere que la librería de C esté instalada en el sistema host.
    C.printf("Hola desde C\n")
}

Si compilas este código, el binario resultante no será “autónomo”. Al intentar moverlo a una imagen de Docker FROM scratch (que está totalmente vacía), el programa fallará con un error de tipo library not found, porque buscará archivos .so o .dylib que no existen en el contenedor.

N° 2