Noob question: why did they not choose to use WebAssembly in the kernel instead?
eBPF has much stronger constraints than WebAssembly.
Show HN: Write your BPF programs in Go, not C
51–58 of 58 posts
Re: Show HN: Write your BPF programs in Go, not C
#52Noob question: why did they not choose to use WebAssembly in the kernel instead?
if you crash in wasm, your tab dies. if you crash in ebpf, your server dies. different stakes.
Re: Show HN: Write your BPF programs in Go, not C
#53I'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.
I think the real benefit here is being able to share structures, etc. with userspace and keep them in sync.
If this was compiling the Golang to BPF then yeah, that would feel ridiculous, but given that it's transpiling instead then, assuming that it's generating correct and reasonable code, I think this is certainly fine enough. Especially if you're just writing a proof of concept or something pretty basic, there's no reason not to start here.
If you're doing something like trying to filter 40Gbps of network traffic in eBPF then you'd probably want to consider something more hand-tuned/low-level, but that might well be a premature optimization for all I know.
Re: Show HN: Write your BPF programs in Go, not C
#54Noob question: why did they not choose to use WebAssembly in the kernel instead?
eBPF has a lot more checks in the verifier, which you could read about here if you're interested in learning more: https://docs.kernel.org/bpf/verifier.html
Since you don't want to handle any kind of crash, out of bounds exception, etc., the eBPF verifier does a ton of impressively paranoid stuff. It ensures that the program doesn't loop (or if it loops that the loop is provably bounded and cannot be infinite), it guarantees that you don't read from a register that might not have been written to, etc.
Basically, it needs to be able to mathematically prove without a doubt that the program behaves as it's supposed to or the verifier refuses to load it at all. WASM doesn't do that, since WASM is a general-purpose 'machine' and WASM programs could theoretically just run forever in entirely reasonable cases.
Re: Show HN: Write your BPF programs in Go, not C
#55Lately I’ve been using Go for a personal project and I am so so happy about it. So so happy.
I hate writing in Golang, I really do, but I cannot deny that it does what it set out to do extremely well.
The tooling is phenomenal and fast. It won't let me accidentally not use a variable, meaning that it won't let me foo, err := something() and not check err. It makes a lot of stuff explicit (e.g. there's no `array.add(item)`, just `array = append(array, newitem)` which makes it more obvious that I might be creating a lot more arrays than just the one I'm trying to work with, but it lets me do `make([]string, 5000)` to pre-allocate the length I want if I know what I need.
Every variable type has a default 'empty' value that is a valid value; an int with no value assigned is 0, a string with no value assigned is "", so you never get corrupted or random data when one of your branches doesn't set the value.
It has a lot of nice thread-safety stuff, since goroutines are such a thing. There's built-in functionality to say "Spawn all these goroutines and then wait until they're done", but there's also functionality to say "Here's a function, it should be called at most once across the lifetime of the program" so that you don't have to manually synchronize "did I do this initialization yet? Is it done yet? Get a lock and then check everything and then set everything."
And it's fast. It's really, really fast. It's so fast that I was testing a GOCACHEPROG program to cache intermediate compilation results instead of recompiling them and in at least some cases it was faster to recompile than to use the cache. The cache was a cloud storage bucket in another country, mind you, but with Rust or C++ that would still be a huge win. With Golang I had to work really, really hard to get cloud storage of intermediate artifacts to be faster than just recompiling on my laptop.
So yeah, I hate Golang and I hate writing Golang but... yeah, it's pretty good.
Re: Show HN: Write your BPF programs in Go, not C
#56> 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'm curious if Solod https://github.com/solod-dev/solod would be a good fit. It's not "real" Go, but you write Go and generate C.
Re: Show HN: Write your BPF programs in Go, not C
#57Earlier quoted context omitted.
To be honest BPF is one of those acronyms that I think might be more recognizable as the acronym than what it actually stands for. Not quite as much as Radar or Laser, but halfway there.
And today I learned this has a name, anacronym! An acronym that has become so common, it's treated as a word instead of an acronym.
And to be really pedantic about it, an acronym is pronounceable, like "NASA", so BPF is actually an initialism!
Re: Show HN: Write your BPF programs in Go, not C
#58Earlier quoted context omitted.
And today I learned this has a name, anacronym! An acronym that has become so common, it's treated as a word instead of an acronym.
And to be really pedantic about it, an acronym is pronounceable , like "NASA", so BPF is actually an initialism!
An initialism, yet now an aninitialism.