Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

21–30 of 58 posts

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

#21

Post by auxiliarymoose »

hnlmorg wrote: post #19
auxiliarymoose wrote: post #18

Earlier quoted context omitted.

Well, it's posted on Hacker News which is a general audience including people working on electrical/signal/audio/radio-frequency systems among other things (not just low-level network code) where BPF has a different meaning, so I think disambiguation is appropriate.

> Well, it's posted on Hacker News which is a general audience including people working on electrical/signal/audio/RF systems among other things (not just low-level network code) where BPF has a different meaning, so I think disambiguation is appropriate. And it's been explained on HN exactly what it is. So problem solved. By the way, I noticed you didn't follow your own recommendation for the "RF" acronym in your co…

Thanks for the catch! Fixed :-)

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

#22

Post by hnlmorg »

> 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.

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

#23

Post by razighter777 »

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!

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

#24

Post by tptacek »

badc0ffee wrote: post #5

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 alread…

It's the same situation with Aya in Rust. It's sort of a "same language on the backend and the frontend" kind of deal, like with Javascript.

I agree though, I think it makes more sense just to write the C code. The hard part of eBPF isn't writing the code; it's getting it past the verifier.

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

#30

Post by mickael-kerjean »

hnlmorg wrote: post #22

> 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 langua…

I did work on a plugin system for Filestash leveraging wasm. Plugins made with tinygo were 10x slower than the same code in rust or c compiled to wasm

[1] https://github.com/mickael-kerjean/filestash/blob/master/ser...

Post reply on HN