BPF en Go: escribir programas sin C

Si trabajas con Linux, observabilidad o networking, probablemente ya sabes que BPF y eBPF son potentes, pero escribirlos en C no siempre se siente práctico. Entre helpers, mapas, verificación del kernel, compilación cruzada y tooling alrededor de clang, el costo mental sube rápido. No es que C sea malo; es que para muchos equipos la fricción termina siendo más alta que el valor inicial que querían obtener.

Ahí entra la idea de gobee: escribir programas BPF en Go en lugar de C. La propuesta no elimina la complejidad del kernel, pero sí intenta mover parte del trabajo a un lenguaje que muchos devs de sistemas ya conocen, con tooling más familiar, tipado más cómodo y una experiencia de desarrollo menos áspera. Para observabilidad, networking y seguridad, eso puede cambiar bastante la forma en que prototipas y mantienes este tipo de código.

Qué problema intenta resolver BPF en Go

BPF y eBPF se usan para observar procesos, filtrar paquetes, medir latencias, inspeccionar syscalls y construir herramientas de seguridad. El problema no es la idea, sino la experiencia de desarrollo. En muchas organizaciones, el flujo típico sigue siendo algo así: escribes C, compilas con clang, generas artefactos auxiliares, cargas el programa con una librería en user space y luego depuras diferencias entre el kernel real y tu entorno local.

Ese flujo funciona, pero no siempre escala bien cuando quieres iterar rápido. Si tu equipo ya hace backend en Go, tener que cambiar a C para una pieza de infraestructura suele meter ruido. No solo por la sintaxis, también por el modelo mental: punteros, layout de structs, restricciones del verificador y detalles de compatibilidad con versiones del kernel.

La propuesta de gobee apunta justo a esa fricción. La idea es que tú escribas la lógica BPF en Go y el proyecto se encargue de traducirla al formato que el kernel puede cargar. Eso no significa que el kernel “entienda Go” de forma nativa. Significa que el lenguaje de autoría cambia, mientras el resultado sigue siendo un programa BPF compatible con el ecosistema Linux.

Por qué C se vuelve una barrera práctica

C sigue siendo el lenguaje clásico para BPF porque encaja con el nivel bajo que exige el kernel. Pero en la práctica, muchos equipos no quieren adoptar C solo para una parte pequeña de su stack. Si tu observabilidad vive al lado de servicios Go, Kubernetes o tooling interno, mantener una isla de C puede aumentar el costo operativo.

Además, el ciclo de prueba suele ser más lento de lo que parece. Cambias una estructura, recompilas, vuelves a cargar, revisas si el verificador aceptó el programa y repites. Cuando el objetivo es instrumentar una latencia de 20 ms o detectar conexiones salientes sospechosas, cada minuto de fricción cuenta.

Gobee se mete en ese hueco: no promete magia, pero sí una experiencia más cercana a cómo ya desarrollas software en Go.

Cómo funciona la idea de gobee

Según el repositorio del proyecto, gobee permite escribir programas BPF en Go y producir artefactos que luego se usan en el kernel. La pieza clave no es solo el lenguaje, sino el flujo completo: escribir, compilar, empaquetar y cargar con menos trabajo manual. Eso es lo que hace interesante al proyecto para devs de sistemas.

La ventaja potencial no está únicamente en “usar Go”. Está en poder reutilizar hábitos que ya tienes: módulos, tooling conocido, tests, organización de paquetes y una sintaxis que suele ser más legible para equipos que ya viven en ese ecosistema. Si tu equipo ya mantiene servicios en Go, la curva de adopción puede bajar bastante.

Ahora bien, conviene poner límites. BPF sigue siendo BPF: hay restricciones de memoria, de loops, de acceso a estructuras y de verificación. Es decir, no vas a escribir una app normal de Go y esperar que el kernel la ejecute sin adaptaciones. La diferencia está en que el proyecto intenta abstraer parte de esa complejidad.

Qué cambia frente al flujo tradicional

En un flujo clásico con C, normalmente separas el programa BPF del loader en user space. Eso implica coordinar dos piezas, mantener compatibilidad entre estructuras y pensar en detalles de serialización. Gobee busca reducir esa distancia, al menos para el lado de autoría.

Un ejemplo práctico: si quieres contar eventos por PID o por puerto, en C puedes hacerlo, pero el código suele incluir bastante ceremonia. En Go, la intención de negocio puede verse más clara. Eso ayuda cuando varias personas del equipo revisan el código y no todas tienen experiencia profunda en C de kernel.

También hay un efecto de tooling. Go ya trae un ecosistema de testing, linting y formatos muy estandarizado. Si el proyecto encaja bien con eso, puedes tener una experiencia más homogénea que la que suele aparecer en proyectos BPF clásicos.

Dónde puede servir de verdad

No todo caso de uso merece cambiar el lenguaje de autoría. Pero hay escenarios donde esta propuesta sí tiene sentido, sobre todo si buscas velocidad de iteración y mantenibilidad dentro de un equipo que ya vive en Go.

Por ejemplo, observabilidad de servicios internos, detección de patrones de red, métricas de syscalls, tracking de latencias por proceso y reglas simples de seguridad. En esos casos, muchas veces el programa BPF no es enorme; es una pieza pequeña que necesita ser confiable y fácil de modificar.

También puede ser útil en organizaciones donde el equipo de plataforma no quiere depender de especialistas en C para cada ajuste. Si tú ya tienes devs con experiencia en Go, mover la lógica al mismo lenguaje puede simplificar revisiones, onboarding y mantenimiento.

Casos concretos de uso

1. Observabilidad de procesos: contar ejecuciones de binarios, medir tiempos de arranque o registrar aperturas de archivos.
2. Networking: inspeccionar conexiones salientes, filtrar tráfico o medir latencia por puerto.
3. Seguridad: detectar syscalls específicas, vigilar accesos a rutas sensibles o registrar patrones anómalos.
4. Plataformas internas: instrumentar entornos Linux donde ya usas Go para agentes, control planes o tooling.

Si tu caso depende de lógica muy compleja, estructuras compartidas grandes o integración profunda con features específicas del kernel, C todavía puede ser la opción más directa. La propuesta de gobee brilla más cuando quieres reducir fricción sin abandonar el terreno de BPF.

Aquí conviene pensar en costo total, no solo en elegancia técnica. A veces una solución “menos pura” pero más mantenible gana por goleada en equipos reales.

Lo que ganas y lo que sigues pagando

La idea de escribir BPF en Go suena bien, pero no elimina las restricciones del dominio. El kernel sigue mandando. Si el verificador no acepta tu programa, no importa cuánto te guste el lenguaje. Si tu target tiene una versión vieja de kernel, también vas a chocar con límites de compatibilidad.

Aun así, hay beneficios claros. El primero es la legibilidad. El segundo es la posibilidad de atraer a más gente del equipo a tocar este tipo de código sin pedirles que se vuelvan expertos en C de un día para otro. El tercero es la coherencia con un stack que ya usa Go para backend, agentes y tooling.

Beneficios prácticos para equipos de sistemas

• Menos cambio de contexto entre servicios Go y código BPF.
• Mejor onboarding para devs que no trabajan en C a diario.
• Tooling más familiar para formateo, tests y organización de proyecto.
• Posibilidad de prototipar más rápido reglas de observabilidad o red.
• Menor fricción para mantener pequeños programas de kernel con ciclos cortos de cambio.

Costos y límites que no desaparecen

• Sigues dependiendo de compatibilidad con el kernel.
• El verificador de BPF sigue imponiendo restricciones.
• Algunas optimizaciones de bajo nivel pueden requerir más cuidado.
• No todo el ecosistema BPF existente está pensado para Go.
• La madurez del proyecto importa más que la idea.

Si quieres ver cómo se documenta el ecosistema BPF a nivel oficial, vale la pena revisar la documentación de BPF en el kernel Linux. También puedes mirar la documentación de eBPF en Cilium para aterrizar mejor los casos de uso más comunes.

Comparación rápida con el flujo clásico en C

Para aterrizarlo mejor, aquí va una comparación simple entre escribir BPF en C y probar una alternativa como gobee. No es una batalla de “mejor o peor”, sino de qué te reduce más fricción en tu contexto.

La tabla no dice que Go sustituya a C en todo. Dice algo más útil: si tu equipo ya vive en Go, quizá no necesitas cargar con C para cada pieza pequeña de instrumentación. Eso cambia la conversación interna cuando decides dónde invertir tiempo.

Cómo probarlo sin meterte en un pozo

Si quieres evaluar una herramienta así, no empieces por el caso más complejo que tengas en producción. Empieza por algo pequeño, medible y fácil de validar. En BPF, eso suele significar contar eventos, registrar syscalls o capturar una señal simple de red.

Un enfoque razonable sería este:

1. Elige una métrica concreta, por ejemplo conexiones por proceso.
2. Define el resultado esperado en números, como contar eventos por minuto.
3. Prueba primero en un entorno local con un kernel compatible.
4. Compara el tiempo que te toma implementar la misma idea en C y en Go.
5. Revisa si el mantenimiento real mejora, no solo el prototipo.

Ese último punto importa mucho. Muchas herramientas se sienten bien en la demo, pero fallan cuando pasan a manos del equipo que las va a mantener durante seis meses. Si el proyecto reduce el costo de cambio y no solo el tiempo de arranque, ya tiene una ventaja real.

Señales de que sí te conviene evaluarlo

Si tu organización ya usa Go para agentes o tooling, si el equipo de plataforma no quiere depender de especialistas en C, o si estás armando observabilidad interna para Linux, vale la pena hacer una prueba. También tiene sentido si tu objetivo es iterar rápido sobre ideas de networking o seguridad y no construir desde el inicio una librería BPF de largo aliento.

En cambio, si necesitas compatibilidad máxima con tooling existente, soporte amplio de ejemplos y una ruta muy conocida para producción, C y el ecosistema tradicional siguen siendo una base más segura. No hay que forzar la adopción solo porque el enfoque suena más cómodo.

Tabla resumen

La idea central es simple: si ya usas Go en tu stack, escribir BPF en Go puede bajar bastante la fricción de entrada. No resuelve todas las limitaciones del kernel, pero sí puede hacer más llevadero el trabajo diario. Y para herramientas de observabilidad o networking, esa diferencia práctica vale mucho.