Rendered at 07:25:11 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
badc0ffee 9 hours ago [-]
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.
tptacek 7 hours ago [-]
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.
brancz 50 minutes ago [-]
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.
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.
hnlmorg 8 hours ago [-]
> 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.
> 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.
atgreen 6 hours ago [-]
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
mickael-kerjean 6 hours ago [-]
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
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.
nathannaveen 3 hours ago [-]
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.
bluejekyll 9 hours ago [-]
I feel like every language has its fans. What invariably happens is that people want their favorite language to work in every situation that they might need to work.
Personally I would choose Rust as well, but I would choose Rust for almost everything I do. I can see why a Go developer would want a similar experience.
Thaxll 7 hours ago [-]
Rust is in the same boat, ebpf is C.
lelanthran 7 hours ago [-]
Why? What value does Rust add here?
itsnowandnever 7 hours ago [-]
spoken like a true go developer ha
razighter777 8 hours ago [-]
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!
hbwang2076 7 hours ago [-]
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.
i2km 7 hours ago [-]
The readme is an immediate giveaway of sloppiness
shirleyquirk 10 hours ago [-]
Sorry, why wouldn’t I write in the native language?
abtinf 9 hours ago [-]
This transpiles to the native language.
r3tr0 2 hours ago [-]
try adding bindings to it from javascript and using it to render jsx in the terminal
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.
This is why National Aeronautics & Space Administration (NASA) guidance is the following:
> Acronyms often confuse readers. Avoid them whenever possible. If an acronym is necessary for future reference, spell the full word and follow with the acronym in parentheses on the first reference. For example, The General Services Administration (GSA).
In fairness to the authors README, there isn't really any other BPFs in this domain and if someone didn't already know what BPF was, then this project wouldn't be of any interest to them (and would be a bad place to start on an BPF journey too).
So I can't blame the project's author for the lack of explanation about what BPF is. Particularly when it's just someone's personal project.
And before anyone complains about this comment: I do think the GP is completely fair in asking for clarification as to what BPF is too. There sometimes seems to be backlash on HN against people asking for a term to be explained. This comment isn't that.
auxiliarymoose 9 hours ago [-]
Sure, but if you are sharing with a general audience (where people aren't necessarily coming from your own domain) it's a good idea to make the writing accessible.
My first thought would have been Band-Pass Filter, which is also a filter potentially related to computer systems.
I work in an industry with a lot of Three-Letter Acronyms (TLAs) and eXtended Three-Letter Acronyms (XTLAs) (sometimes known as Four-Letter Acronyms (FLAs)), and there they are often overloaded in their meanings. So in my experience, being clear about the definition is helpful to readers so they can immediately understand the document without having to triangulate meanings from the rest of the document.
hnlmorg 9 hours ago [-]
But again, this isn't intended for a general audience.
Anyone who might need this would already know what BPF is. And anyone who isn't familiar with the term BPF in this context wouldn't be the target audience for this.
It's also worth noting that BPF isn't ever referred to in it's non-acronym form. Literally no-one in the field calls this "Berkeley Packet Filter". Just like nobody calls PHP "PHP: Hypertext Processor" (or whatever backronym they've decided on this week), nor SQL as Structured Query Language. The name for this technically literally is just referred to as "BPF".
So while I agree with your point in general -- it's not really a fair complaint in this specific occurrence.
auxiliarymoose 9 hours ago [-]
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.
hnlmorg 9 hours ago [-]
> 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 comment. Nor "NASA" in your first reply. Perhaps you should check your own comments before you criticize others for doing the same.
Maybe you should also leave a comment in the Mullvad story (currently #1 on HN) that nobody has explained the VPN acronym there. Likewise for the threads where people reminisce about BASIC, of which there have been many lately. They're also only obvious if you already know the subject matter.
auxiliarymoose 9 hours ago [-]
Thanks for the catch! Fixed :-)
aeonik 9 hours ago [-]
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.
Retr0id 9 hours ago [-]
Spelling out Berkeley Packet Filter doesn't really tell you anything about what eBPF actually is.
ImJasonH 9 hours ago [-]
What's NASA :)
auxiliarymoose 9 hours ago [-]
~Well, if you asked a randomly-chosen person (technical or non-technical) they would probably say NASA is "the organization that does the space things" — it's pretty well-known~
~On the other hand, BPF means different things in different domains, and isn't ubiquitous in the same way~
Edit: I should have written it out, that's on me :-)
knome 9 hours ago [-]
'berkeley packet filters', these days 'extended berkeley packet filters', are little program snippets you can inject into the linux kernel from userland programs to run logic on hooks on various events without the need to switch back to userspace.
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.
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.
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
- 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.
> 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.
[1] https://github.com/mickael-kerjean/filestash/blob/master/ser...
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.
Personally I would choose Rust as well, but I would choose Rust for almost everything I do. I can see why a Go developer would want a similar experience.
https://yeet.cx
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.
This is why National Aeronautics & Space Administration (NASA) guidance is the following:
> Acronyms often confuse readers. Avoid them whenever possible. If an acronym is necessary for future reference, spell the full word and follow with the acronym in parentheses on the first reference. For example, The General Services Administration (GSA).
https://nasa.github.io/content-guide/abbreviations-and-acron...
There is also this longer memo on the NASA Technical Reports Server: https://ntrs.nasa.gov/citations/19950025292
So I can't blame the project's author for the lack of explanation about what BPF is. Particularly when it's just someone's personal project.
And before anyone complains about this comment: I do think the GP is completely fair in asking for clarification as to what BPF is too. There sometimes seems to be backlash on HN against people asking for a term to be explained. This comment isn't that.
My first thought would have been Band-Pass Filter, which is also a filter potentially related to computer systems.
I work in an industry with a lot of Three-Letter Acronyms (TLAs) and eXtended Three-Letter Acronyms (XTLAs) (sometimes known as Four-Letter Acronyms (FLAs)), and there they are often overloaded in their meanings. So in my experience, being clear about the definition is helpful to readers so they can immediately understand the document without having to triangulate meanings from the rest of the document.
Anyone who might need this would already know what BPF is. And anyone who isn't familiar with the term BPF in this context wouldn't be the target audience for this.
It's also worth noting that BPF isn't ever referred to in it's non-acronym form. Literally no-one in the field calls this "Berkeley Packet Filter". Just like nobody calls PHP "PHP: Hypertext Processor" (or whatever backronym they've decided on this week), nor SQL as Structured Query Language. The name for this technically literally is just referred to as "BPF".
So while I agree with your point in general -- it's not really a fair complaint in this specific occurrence.
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 comment. Nor "NASA" in your first reply. Perhaps you should check your own comments before you criticize others for doing the same.
Maybe you should also leave a comment in the Mullvad story (currently #1 on HN) that nobody has explained the VPN acronym there. Likewise for the threads where people reminisce about BASIC, of which there have been many lately. They're also only obvious if you already know the subject matter.
Not quite as much as Radar or Laser, but halfway there.
~On the other hand, BPF means different things in different domains, and isn't ubiquitous in the same way~
Edit: I should have written it out, that's on me :-)
Here you go: https://github.com/pratyushanand/learn-bpf