Purego entra en beta para llamar a funciones C desde Go sin Cgo
La librería de Ebitengine permite invocar símbolos de bibliotecas compartidas en tiempo de ejecución, sin compilador de C y con el respaldo de Cgo si hace falta.
Purego ya está en beta. La librería, mantenida por el equipo de Ebitengine, sirve para llamar a funciones C desde Go sin pasar por Cgo: abre la biblioteca compartida con Dlopen, registra el símbolo que interesa y lo invoca como si fuera una función Go más. El proyecto avisa de que siendo beta habrá errores y posibles cambios de API, aunque cada publicación va etiquetada para que nadie se rompa por sorpresa.
El origen está en Windows. Cuando Ebitengine se portó a Go puro en esa plataforma, compilar para Windows desde cualquier otro sistema se redujo a poner GOOS=windows. Purego nació para llevar esa misma idea al resto de plataformas que soporta el motor.
Qué gana quien lo use
El argumento principal es que sin C no hace falta un compilador de C para compilar. Eso simplifica la compilación cruzada y permite cachear builds enteros en Go. También adelgaza los binarios: Cgo genera una función envoltorio en C por cada función C que se llama, y aquí no hay ninguna. A eso se suma el enlace dinámico, es decir, cargar símbolos en tiempo de ejecución y usarlo como sistema de plugins, y la posibilidad de llamar a otros lenguajes compilados en objetos compartidos.
El respaldo de Cgo sigue funcionando con CGO_ENABLED=1, así que se puede migrar código de forma incremental. Lo mismo ocurre con arquitecturas que no están soportadas de forma nativa: siguen funcionando salvo en el paso de argumentos y valores de retorno en coma flotante.
El uso típico con libc en Linux o macOS queda en dos llamadas: una a Dlopen y otra a RegisterLibFunc para enganchar puts. Basta con compilar con CGO_ENABLED=0. El ejemplo completo del repositorio cubre además FreeBSD y Windows, que necesitan un tratamiento distinto.
Plataformas
El proyecto separa dos niveles. En el nivel 1 están Android (amd64, arm64), iOS (amd64, arm64), Linux (amd64, arm64), macOS (amd64, arm64) y Windows (amd64, arm64). Ahí un fallo crítico bloquea la publicación hasta que se arregle. Las variantes de Android, iOS y Windows requieren CGO_ENABLED=1 para compilar.
El nivel 2 es soporte según esfuerzo disponible y no bloquea versiones: Android 386 y arm, FreeBSD amd64 y arm64, NetBSD amd64 y arm64, Windows 386 y arm, y en Linux 386, arm, loong64, ppc64le, riscv64 y s390x. Algunas de esas combinaciones van a dejar de necesitar Cgo a partir de Go 1.27; otras ya no se soportan desde Go 1.26.
Parte del código procede del runtime de Go y va bajo licencia BSD-3, con los archivos de runtime/cgo copiados y, en algún caso, modificados.
Para quien mantiene envoltorios de bibliotecas C o pelea con compiladores cruzados en CI, la propuesta es atractiva: menos piezas móviles y builds más rápidos. Lo que frena es el estado beta. Una API que puede cambiar obliga a fijar versión y a leer las notas antes de actualizar, y la cobertura por arquitecturas tiene agujeros conocidos.
