Show HN: Write your BPF programs in Go, not C

In eBPF-land you're going to be calling C functions in the kernel, and using (generally) C data types like structs and null-terminated strings. You can't do loops (loops are unrolled by the compiler), you can't do variadic functions, and you definitely can't take advantage of all the cool Go stuff like goroutines, select, context, etc.

I'm not really sure why you'd want to use this. If you're writing eBPF, you already need to know how to read C kernel source.

> Why transpile, not generate BPF directly

> gc, the Go compiler, has no LLVM-based BPF backend. Adding one is a multi-year compiler project. rustc is built on LLVM and that's why Aya works. So gobee emits C and reuses clang's BPF backend, which gives us mature codegen, BTF, and CO-RE relocations for free.

I wonder if TinyGo (https://tinygo.org/) might be a better fit here:

> TinyGo brings the Go programming language to embedded systems and to the modern web by creating a new compiler based on LLVM.

I've not played with TinyGo much so would be interested to hear other peoples experiences.

I'm primarily a Go developer and love the language and will defend it for most use-cases, but to be honest BPF seems like Rust's place to shine.

Remember, a lot of the memory safety benefits from go and rust and eBPF don't apply to the kernel eBPF! Kernel eBPF enforces semantics that verify array and loop bounds, memory accesses, and correctness of programs via the verifier. I think for most usecases, it is still best to write eBPF in C!

Clean implementation. One thing I always look for: how does this degrade when things go wrong? Good error handling is what separates weekend projects from tools people actually use.

The readme is an immediate giveaway of sloppiness

Sorry, why wouldn’t I write in the native language?

What is BPF?