eBPF Language Battle: Full-Stack Comparison of C, Rust, and Zig

The previous articles on OOM tracing all used C for eBPF kernel-space programs. This is natural — C is eBPF’s “native language,” with the verifier, CO-RE, and libbpf toolchain all designed around C. But if you’ve followed the eBPF ecosystem, you’ll notice a clear trend: more and more people are writing eBPF in languages other than C. Rust’s Aya framework is already used in production by the Solana validator and Kubernetes Gateway API; meanwhile, Zig is trying to bring a new development experience with comptime, explicit allocation, and first-class C interop.

This article shifts perspective: instead of focusing on a specific scenario, we’re doing a full-stack comparison — for the same eBPF program, how would you write it in C, Rust, and Zig? How do kernel-space programs compile? How do user-space loaders work? Where’s the real technical dividing line among the three?

Timeline note: This article is based on the toolchain state as of June 2026. Zig’s BPF CO-RE support remains a Post-1.0 goal, and Aya’s compiler-level CO-RE relocation is also in progress — these are evolving rapidly, and some conclusions may change with version updates.

eBPF Full-Stack Development Model

Regardless of the language, a complete eBPF tool consists of two parts: the BPF program running in kernel space, and the control program running in user space. Understanding this model is prerequisite for comparing the three languages.

flowchart LR
    subgraph 用户态["用户态 User Space"]
        LD["Loader<br/>打开 .o、加载、attach"]
        POLL["控制循环<br/>读 maps / ringbuf"]
    end
    subgraph 内核态["内核态 Kernel"]
        HOOK["Hook 点<br/>kprobe / tracepoint / xdp"]
        BPF["BPF 程序<br/>verifier 校验后运行"]
        MAP["Maps / RingBuf<br/>内核 ↔ 用户数据通道"]
    end
    LD -- "bpf 系统调用" --> BPF
    BPF -- "挂载到" --> HOOK
    HOOK -- "事件触发执行" --> BPF
    BPF -- "读写" --> MAP
    MAP -- "用户态读取" --> POLL
    classDef user fill:#3b82f6,color:#fff
    classDef kern fill:#f59e0b,color:#fff
    class LD,POLL user
    class HOOK,BPF,MAP kern

Two pieces of code, two targets, one ELF file binding them together:

• Kernel-space program compiles to a BPF ELF object (.o), containing bytecode, map definitions, and BTF information. It must pass verifier validation before running.
• User-space loader is responsible for loading this .o into the kernel, handling CO-RE relocation, attaching to specific hook points, then reading maps/ringbuf to retrieve data.

The difference among the three languages is essentially what language to use for these two pieces of code, and what toolchain to glue them together.

C + libbpf: Unshakable Baseline

C is the de facto standard for eBPF. Kernel docs, Cilium, bcc, Tetragon, BPF tools in all major distributions — all C + libbpf. Later arrivals take it as their reference.

The typical development paradigm is libbpf-bootstrap: compile kernel-space programs with Clang, access kernel structures through the BPF_CORE_READ macro (this is CO-RE), then use bpftool gen skeleton to generate type-safe loader skeletons.

Kernel-space program (C + libbpf):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

#include "vmlinux.h"
#include <bpf/bpf_helpers.h>
#include <bpf/bpf_tracing.h>

struct {
    __uint(type, BPF_MAP_TYPE_ARRAY);
    __uint(max_entries, 1);
    __type(key, u32);
    __type(value, u64);
} counter SEC(".maps");

SEC("kprobe/do_sys_openat2")
int count_open(struct pt_regs *ctx)
{
    u32 key = 0;
    u64 *val = bpf_map_lookup_elem(&counter, &key);
    if (val)
        __sync_fetch_and_add(val, 1);
    return 0;
}

User-space loader (libbpf skeleton):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

#include "probe.skel.h"

int main(void)
{
    struct probe_bpf *skel = probe_bpf__open_and_load();
    probe_bpf__attach(skel);

    while (1) {
        u32 key = 0;
        u64 val = 0;
        bpf_map_lookup_elem(bpf_map__fd(skel->maps.counter), &key, &val);
        printf("open count: %llu\n", val);
        sleep(1);
    }
    return 0;
}

vmlinux.h is all kernel structure definitions generated by bpftool btf dump from the target kernel. Combined with BPF_CORE_READ, one program can run on different kernel versions without recompilation — this is CO-RE (Compile Once, Run Everywhere). The C path’s CO-RE is compiler-native and most complete, which is why it remains unshakable to this day.

Rust + Aya: Strongest Challenger for Memory Safety

Aya is the eBPF framework in the Rust ecosystem. As of June 2026, aya-rs/aya has 4.6k stars, with the latest version at v0.14.0. Its biggest selling point is pure Rust, no C toolchain dependencies: kernel-space programs use aya-ebpf (compiled with #![no_std]) to BPF bytecode, user-space programs use aya to load, all without Clang, libbpf, or kernel headers.

Kernel-space program (Aya, #![no_std]):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

#![no_std]
#![no_main]

use aya_ebpf::{
    helpers::bpf_get_current_pid_tgid,
    macros::{kprobe, map},
    maps::Array,
    programs::ProbeContext,
};

#[map]
static COUNTER: Array<u64> = Array::pinned(1, 0);

#[kprobe]
pub fn count_open(ctx: ProbeContext) -> u32 {
    let _pid = bpf_get_current_pid_tgid() as u32;
    if let Some(val) = COUNTER.get(0) {
        let _ = COUNTER.set(0, val + 1, 0);
    }
    0
}

#[cfg(not(test))]
#[panic_handler]
fn panic(_info: &core::panic::PanicInfo) -> ! {
    loop {}
}

User-space loader (Aya):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

use aya::{
    include_bytes_aligned,
    maps::Array,
    programs::KProbe,
    Ebpf,
};

fn main() -> anyhow::Result<()> {
    let mut ebpf = Ebpf::load(include_bytes_aligned!(
        concat!(env!("OUT_DIR"), "/probe")
    ))?;

    let prog: &mut KProbe = ebpf.program_mut("count_open")?.try_into()?;
    prog.load()?;
    prog.attach("do_sys_openat2", 0)?;

    let counter: Array<_, u64> = Array::try_from(ebpf.map("COUNTER").unwrap())?;
    loop {
        println!("open count: {}", counter.get(&0, 0)?);
        std::thread::sleep(std::thread::Duration::from_secs(1));
    }
}

Aya’s real production strength isn’t in the code itself, but in its user roster: the Solana validator’s XDP fast packet retransmission (agave-xdp), Kubernetes SIGs’ L4 load balancer blixt, Red Hat’s bpfman, and Deepfence’s ebpfguard. This is currently the only non-C solution validated at large production scale.

Aya also brings things the C path lacks: type-safe map access, tokio-native async (AsyncFd directly interfaces with ringbuf), and the ownership system blocking a class of errors at compile time.

Zig + zbpf: Explorer with Potential and Limitations

Zig is the youngest attempt of the three. The Zig toolchain itself supports BPF targets — zig cc -target bpfel can compile BPF ELF objects, and Zig’s source code src/target.zig explicitly lists bpfel/bpfeb as LLVM-supported target architectures. But the official platform support page lists BPF as “Additional Platforms,” not within the Tier rating system, meaning available but correctness isn’t guaranteed.

1
2
3
4
5

# Compile C code to BPF object (using zig cc as Clang)
zig cc -target bpfel -O2 -c probe.bpf.c -o probe.o

# Or compile Zig source directly to BPF (freestanding, no std)
zig build-exe -target bpfel-freestanding probe.zig

The most mature in the community is tw4452852/zbpf (275 stars). It doesn’t go the old @cImport(libbpf) route, instead implementing a pure Zig user-space loader: built-in ELF parsing, BTF parsing, CO-RE relocation, skeleton code generation, zero external dependencies (no libelf, libbpf, libz).

Kernel-space program (Zig + zbpf, schematic):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

// Refer to zbpf samples API style, specific interfaces vary by version
const bpf = @import("zbpf");

pub var counter = bpf.ArrayMap(u64).init(1);

// zbpf uses comptime for type safety: accessing non-existent fields errors at compile time
export fn count_open() void {
    const val = counter.get(0) orelse 0;
    counter.update(0, val + 1);
}

User-space loader (Zig + zbpf):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

const std = @import("std");
const zbpf = @import("zbpf");

pub fn main() !void {
    var gpa = std.heap.GeneralPurposeAllocator(.{}){};
    defer _ = gpa.deinit();
    const allocator = gpa.allocator();

    // Pure Zig loader: parse ELF, load BTF, do CO-RE relocation, pass verifier
    var obj = try zbpf.BpfObject.open(allocator, @embedFile("probe.o"));
    defer obj.close();
    try obj.load();

    const prog = obj.findProgram("count_open") orelse return error.NotFound;
    try prog.attachKprobe("do_sys_openat2");

    const map = obj.findMap("counter") orelse return error.NotFound;
    while (true) {
        std.debug.print("open count: {d}\n", .{map.get(u64, 0) orelse 0});
        std.time.sleep(std.time.ns_per_s);
    }
}

Zig’s appeal lies in language features: comptime for compile-time type checking, explicit allocators making memory sources crystal clear, @cImport making C interop nearly zero-cost. One build command zig build zbpf -Dbpf=probe.zig -Dmain=main.zig packages kernel-space and user-space into a single binary, cross-compile with zero config.

But writing eBPF in Zig has one unavoidable hard deficiency.

CO-RE: Technical Dividing Line Among Three Languages

This is the most critical part of the article. CO-RE isn’t a binary choice of “have or not,” but a three-tier “at which layer to implement,” determining whether your program can run across kernel versions.

The essence of CO-RE is: when BPF programs access kernel structure fields, they don’t hardcode offsets but encode them as BTF relocation records, which the user-space loader rewrites instructions based on the target kernel’s actual layout at load time. To do this, the compiler must emit a special LLVM intrinsic (llvm.preserve.struct.access.index etc.).

C’s advantage is native: Clang directly understands CO-RE, BPF_CORE_READ is a first-class citizen, cross-kernel operation is compiler-guaranteed.

Aya is in transition: According to the 2026 FOSDEM talk, Rust can already produce correct BTF for all types, but compiler-side BTF relocation intrinsics aren’t complete yet. Currently Aya does relocation in user-space (aya-obj) to compensate, so it’s usable but not yet compiler-native guaranteed. This route is officially in progress.

Zig is stuck at the hardest step: Codeberg issue #35324 explicitly states the Zig compiler won’t emit intrinsics required for CO-RE, so “cannot realistically be used to write eBPF programs.” zmitchell is implementing these intrinsics in Air.zig, but Andrew Kelley marked it as a Post-1.0 milestone — meaning it won’t be considered until after 1.0, with no current timeline. zbpf’s CO-RE is an ELF-layer manual workaround, usable but not a compiler-guaranteed equivalent; accessing complex nested structures may still be limited.

This layer difference is the fundamental reason Zig can’t yet stand alongside C and Aya as equals.

Full-Stack Comparison

Maturity Assessment and Practical Selection

Honestly:

• C + libbpf: Production-ready, industry standard. CO-RE most complete, ecosystem thickest, most documentation. Without special reasons for new projects, it’s still the default choice. The cost is tolerating C’s memory unsafety and heavier toolchain.
• Rust + Aya: Production-usable, the only non-C solution today that can replace C for writing production eBPF. If your team already uses Rust, or needs memory safety + async, Aya is the clear choice. The only caveat is compiler-level CO-RE is still on the way; complex scenarios need testing.
• Zig + zbpf: Experimental. Technical exploration is imaginative (pure Zig loader, zero dependencies, comptime type safety), but missing compiler-level CO-RE means no guarantee of cross-kernel operation, and the ecosystem is too small (single maintainer). Suitable for learning, technical research, contributing to the community, but not recommended for production.

A pragmatic judgment: if you’re choosing a non-C language for eBPF today, there’s only one answer — Rust + Aya. Zig’s story is attractive, but its key piece (CO-RE) is still on the Post-1.0 roadmap, not a production option at least short-term. However, zbpf’s pure Zig loader implementation is worth every eBPF enthusiast reading — it reimplements libbpf’s core in one language,本身就是对 eBPF 工具链最好的深度学习.

Summary

This article outlined three eBPF development paths from the language ecosystem perspective:

• C + libbpf remains the baseline, compiler-native CO-RE is its moat
• Rust + Aya is the only production-usable non-C solution, memory safety + async is real value
• Zig + zbpf is an explorer with potential, but stuck at compiler-level CO-RE, currently only suitable for experimentation

The true dividing line among the three languages isn’t syntax, but at which layer CO-RE is implemented — compiler-native, user-space relocation, or ELF layer workaround. Understanding this, you can see the maturity ceiling of each project.

The eBPF language battle is just beginning. Later I’ll continue exploring in this direction — might actually write a tool with zbpf, or dissect Aya’s CO-RE relocation implementation. This series will keep going.