gobee
Dev tools
code generator
SHOW HN2026
112points
52comments
#605of 4,366 in 2026
Top 14%of 2026 by points
How HN took it
MixedNo clear lean
2 positive, 5 neutral or asking, 2 mixed, 7 critical, out of 16 comments about the project. Thread score -0.29.
Idea: 1 for, 4 againstExecution: 1 for, 1 againstDocs: 0 for, 2 against
The thread, comment by comment
Each row is a top-level comment and its replies, in HN's order. Select a cell to open that comment on HN.
positive neutral or mixed critical about another commenter or something else the maker
What HN said
What people liked
Good idea for sharing types between kernel and userspace code
From 2 comments
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…
danudey on HNI'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…
nathannaveen on HN
Objections
C is the better fit for eBPF; Go adds no value
From 3 comments
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…
badc0ffee on HNRemember, 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…
razighter777 on HNI'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…
nathannaveen on HN
Go's runtime features don't apply in kernel eBPF
From 2 comments
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…
badc0ffee on HNRemember, 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…
razighter777 on HN
Requests
Use TinyGo or LLVM directly instead of transpiling to C
From 2 comments
> 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…
hnlmorg on HNWell tinygo takes some go bindings they implemented for llvm, https://github.com/tinygo-org/go-llvm, uses the Go standard library for parsing, and wires it up to a LLVM IR…
vetrom on HN
Questions
Why not WebAssembly in the kernel?
From 1 comment
Noob question: why did they not choose to use WebAssembly in the kernel instead?
7373737373 on HN
Alternatives named
Aya (Rust)
From 2 comments
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…
tptacek on HNNitpick: 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…
tuetuopay on HN
Writing plain C eBPF
From 2 comments
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…
badc0ffee on HNWe 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…
brancz on HN
Whistler (Common Lisp)
From 1 comment
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…
atgreen on HN
Solod
From 1 comment
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.
jamesog on HN