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

31–40 of 58 posts

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

#31

Post by atgreen »

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…

Here's another option.. I created an optimizing eBPF compiler in Common Lisp for a lisp-ish DSL. It's nice because you can compile and load your eBPF code all in-process in lisp (even from your REPL) without any external tooling. https://github.com/atgreen/Whistler

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

#32

Post by nathannaveen »

sparrc wrote: post #3

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.

I'm also primarily a Go developer, and I will also defend the language in almost all use cases, but I personally feel that C is the best for writing eBPF. I just feel that you get all of the original functionality with C, and you don't have to hack your way around weird issues that you would encounter when using Go or Rust.

Note that we at Bomfather have our userspace code written in Golang and our eBPF code written in C.

But, either way, this is a really cool solution/idea and could make writing eBPF code a lot easier.

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

#35

Post by brancz »

We write quite a bit of BPF at work for the Parca-Agent project[1]. And we find that even C is sometimes too high level of a language paired with modern optimization techniques as the code you write often doesn’t come out that way the other and and we have to resort to weird hacks or write assembly directly to appease the verifier.

Apart from that, the usual qualms one might have about C are not really relevant in eBPF land, so I’ve actually found it the nicest experience writing C I’ve ever had, the verifier is just the price we have to pay.

[1] https://github.com/parca-dev/parca-agent

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

#36

Post by bflesch »

r3tr0 wrote: post #33

try adding bindings to it from javascript and using it to render jsx in the terminal https://yeet.cx

after going through the docs this looks quite useful, but I'd prefer if the AI features were optional.

assuming it's your project here is some unsolicited feedback:

(1) imprint missing, no idea where the company is operating based on name or tld, cannot rule out it is in adversary country

(2) not a fan of curl | sh, looks way more professional if some prebuilt packages for common distros are also offered. maybe remove the yellow box and add some distro logos "available on your favorite distro"

(3) On landing page I think the last section with the cost comparison should actually be at the very top. No sysadmin wants to have AI chat on their machines. The cost comparison chart shows well-known tools that every sysadmin knows (splunk etc), and directly relates yeet to it - this is very good.

(4) the main landing page hero text is not really explanatory - linux ops is a big term, and there was not a lot of info I got out of it. Further down there is "yeet gives you kernel level visibility with featherweight overhead. Nothing gets dropped.", which I'd personally prefer. Maybe instead of "yeet is a JavaScript runtime for Linux Ops." use something like "yeet is a Javascript runtime for your linux kernel".

Generally the sysadmins I know are not looking for AI chats or agent toolkits, and right now these are "features" that might make people close the tab. But sysadmins want to easily get custom analytics and reduce SaaS costs, these features are looked for.

Maybe it makes sense to more clearly split up the "specialized Javascript for linux Kernel" thing from the AI features. No manager bats an eye if I install a new Javascript runtime that allows better LOCAL-FIRST (!) linux kernel analytics, but a lot of explanation needs to be done if there are "agents" or "AI chats" which can potentially exfiltrate data.

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

#37

Post by bjackman »

brancz wrote: post #35

We write quite a bit of BPF at work for the Parca-Agent project[1]. And we find that even C is sometimes too high level of a language paired with modern optimization techniques as the code you write often doesn’t come out that way the other and and we have to resort to weird hacks or write assembly directly to appease the verifier. Apart from that, the usual qualms one might have about C are not really relevant in eB…

Yeah I actually advocate for dropping to assembly quite a lot in BPF:

- portability isn't a concern

- BPF ASM syntax is quite readable

- it can often let you write simpler code by directly doing what the verifier needs instead of dancing around trying to make Clang do it for you.

I think the most exciting alternative BPF language would be one where the compiler interacts with the verifier. E.g. if the program included a logical proof of correctness that the verifier could check more efficiently than its limited builtin analysis.

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

#38

Post by hnlmorg »

mickael-kerjean wrote: post #30
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...

Yeah I’m not surprised by that. TinyGo might leverage LLVM but it still has all of the Go conveniences that would make it benchmark slower compared to C and Rust. Though I’m sure that gap could be closer if TinyGo had the same level of investment that Rust or Googles Go compiler had.

What I was more curious about was how TinyGo compared with Googles Go compiler and whether TinyGo’s LLVM compiler is compatible with vanilla LLVM compilers (eg can TinyGo compile to all the same targets that, for example Rust, could?)

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

#39

Post by tuetuopay »

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…

Nitpick: you definitely can do loops as long as the verifier can prove they're bounded.

At my previous job, I've written production eBPF exclusively in Rust using Aya (mentioned by a sibling comment), and it's been a blast. Being able to share the type definitions between the kernel-space and the user-space code is a blessing to avoid subtle issues when going through the maps. And, at least in Rust, you can re-use crates and types that make you gain time. As a (simple) example, being able to use the standard library's IpAddr types or the ipnet crate to not have to roll your own IP and network manipulation libraries is a (small) timesave. It's main value is not needing to onboard new developers.

The Rust type system is a good helper in keeping the verifier happy. Slices, iterators, match statements, etc are very good in my experience (e.g. Option is a godsend to ensure you stay withing the bounds of the input packet, esp. slice::split_at when parsing headers).

But you're right that reading C is non-negotiatable, especially since pretty much all example code on the internet is in C.

Post reply on HN