--- title: When the Hard Languages Stopped Being Hard description: eBPF, DWARF, custom crypto, and the hard languages used to be gated by years of earned intuition. Then agents started walking through the same territory without flinching, and the moat between organs and algorithms began to thin. summary: The hard languages used to gatekeep by friction. Agents are walking through that territory now, and the moat is thinning. date: 2026-11-04T00:00:00.000Z heroImage: src: /_astro/hero.CC1MMxq4.webp width: 1376 height: 768 format: webp tags: - AI - Go - Rust - eBPF - Linux - Optimization - Gatekeeping categories: - Technology Bites - Personal published: true featured: true draft: false author: Jad href: /posts/when-the-hard-languages-stopped-being-hard/ slug: when-the-hard-languages-stopped-being-hard --- The first time I tried to write an eBPF program, I gave up inside an hour. This was a few years ago. I had a specific question about a network path on a Linux box, and someone on a forum pointed me at `bpftrace` with the confidence of a person who had forgotten what it feels like to not know things. I opened the documentation. I read about verifier constraints, about BTF, about CO-RE relocations, about the difference between a program that runs in kernel context and one that the verifier will quietly refuse. I closed the tab. It was not that the material was impossible. It was that it was *accented*. You either spoke the dialect, earned over years of living inside the kernel, or you were locked out. There was no middle path. The knowledge was not written down so much as absorbed, the way a language is absorbed, and the people who had it were not always generous with it. I remember the feeling clearly because I grew up with it. In Amman in the early 2000s, the hard systems knowledge lived somewhere else: in mailing lists whose time zone I was never in, in documentation that assumed a mentor I did not have, in a dialect of computing that felt gated by distance as much as by difficulty. You could get in. But you paid a tax in loneliness that the people closer to the center never had to pay. What I have been watching this year is that tax quietly coming down. ## The vibe shift toward small and fast There is a reason Go, Rust, and Zig suddenly feel less like a cult and more like a reasonable answer, and it is not only aesthetic. Go 1.26 shipped a redesigned NUMA-aware work-stealing scheduler that cuts per-goroutine context-switch cost from roughly 120ns to 45ns and lifts goroutine throughput by about 2.1x over 1.25. The "Green Tea" garbage collector reduced stop-the-world pauses to the point where they are negligible for most web workloads. The practical effect is strange and interesting: teams are now *dropping* frameworks like Gin and Fiber and moving back to the standard library's `net/http`, because native routing caught up to Gin's radix tree and the GC erased the allocation pressure that made Fiber worth the friction. The bottleneck moved off the runtime and onto application logic. The framework layer thinned. That is the kind of optimization that used to require a senior engineer's decade of runtime intuition to even *notice*, let alone act on. Now an agent can read a profile, point at the allocation hot path, and suggest the `sync.Pool` reuse before a human has finished making coffee. The trick did not get easier. The *access* to the trick got easier. This is the part I keep coming back to. Language choice used to be a moat built from personal familiarity: you reached for what you had earned fluency in, and you avoided what you had not. Now language marketing drives adoption more than personal expertise does, because the friction of unfamiliar syntax is no longer the friction of *building*. The agent absorbs the syntax. You supply the intent. The moat moved. ## When the kernel met the agent The moment that made all of this feel real to me came from a place I did not expect: the 2026 Linux Storage, Filesystem, Memory-Management, and BPF Summit. Alexei Starovoitov, who maintains the BPF subsystem, gave a talk that LWN described as "less of a presentation, more of a scream of realization." His argument was that BPF has to change, or be swept away, because of the way coding agents are now writing and iterating on programs. The verifier (the thing that once made me close the tab) was never going away, because BPF can never crash the kernel, that is the whole point. But he proposed something that would have sounded absurd five years ago: a well-intentioned BPF program written in Rust, one that passes the Rust compiler without `unsafe` gymnastics, should also pass the verifier without errors. The mistakes should be caught in user space, by the language, before they ever reach the kernel. Read that twice. The kernel people are redesigning the feedback loop *because of how agents write code now*. At the same summit's orbit, there was a related thread at Linux Plumbers 2026: native CO-RE support in the Rust compiler, the last missing piece for Rust eBPF to reach developer-experience parity with C. Until now, a Rust eBPF program that read `task_struct` was pinned to the kernel layout it was built against: an upgrade could silently turn a security boundary into a no-op. The work to emit BTF relocations from `rustc` is the kind of deep-toolchain effort that used to be the exclusive province of a handful of people who had been inside both the compiler and the kernel for a decade. It is being designed in the open, with pre-RFCs on Rust Internals, and the conversation is legible to anyone willing to read it. This is what I mean when I say the tax is coming down. eBPF, DWARF, custom crypto: these were the gated domains. The gatekeeping was not always malicious; a lot of it was just the brute reality that the prerequisite knowledge was scattered, unwritten, and expensive to acquire alone. Now the prerequisites are being assembled by agents that can hold the whole context at once and explain it back to you in the dialect you speak. The gate does not disappear. It gets thinner. And more people can walk through it. ## Organs and algorithms A friend said a phrase to me recently that I have not been able to put down: *organs and algorithms*. There is an old line of thought, going back to Ernst Kapp in the 19th century, that technical devices are extensions of human organs. The hammer extends the fist. The telescope extends the eye. The library extends memory. The tool is not separate from the body; it grows out of it, takes its shape from it, and is meaningless without the body that wields it. Knowledge worked the same way for a long time. The eBPF maintainer's intuition was *organ-like*, grown into the hands over years, situated in a specific machine, a specific kernel version, a specific room. You could not transfer it by handing someone a document. You could only grow it in them, slowly, the way a language grows. An algorithm is the opposite shape. It is transferable, placeless, indifferent to the body that runs it. It does not accrue. It does not situate. It executes. When I watch an agent walk a stranger through writing a BPF program in an afternoon, what I am watching is organ-like knowledge being translated into something algorithmic, detachable from the decade of context that produced it, reattached to a new person through a prompt. I do not think this is a tragedy. From the edge of the network, where I have spent most of my computing life, the thinning of that gate is a gift I would have killed for at twenty. I wrote about the shape of that distance in [Latency Is Political When You Live Far from the Center][latency-post], and the same logic applies here: the people closest to the centers of technical culture have always been the ones who could afford to treat earned knowledge as a birthright. Everyone else had to pay for it in isolation. If the cost is falling, the people who benefit first are the ones who were never let in. But I also do not want to be naive about it. Fluency is not judgment, as I learned the hard way [working with coding agents on real codebases][jules-post]. An agent that can write a BPF program is not the same thing as a person who understands *why* that program is safe to run in kernel context. The verifier exists precisely because fluency without judgment is dangerous in the place where a mistake crashes the machine. The [open-source AI rebellion][rebellion-post] is, at its best, about exactly this tension: lowering the gate without removing the discipline that made the gated knowledge worth having in the first place. So here is the thread I am sitting with, and I do not have a clean answer for it. When the entry cost collapses, what happens to the value of the thing behind the gate? Does the craft survive the loss of the moat, or does it get sharper, because the people who now enter are entering for the work itself rather than for the status of having gotten in? Is the organ-like knowledge (the kind that grows into a body over years, that carries the smell of the room it was learned in) something we are losing, or something we are about to see a lot more of, because more bodies are now invited to grow it? I keep thinking about the eBPF program I gave up on. I could probably write it now, with an agent beside me, in an afternoon. That should feel like progress. Mostly it does. But somewhere underneath the progress there is a quieter question, the one the phrase keeps pointing at: when knowledge stops being organ-like and becomes algorithmic, what exactly is being transferred, and what is being left behind in the room where it was grown? [latency-post]: /posts/latency-is-political-when-you-live-far-from-the-center/ [jules-post]: /posts/power-of-jules/ [rebellion-post]: /posts/open-source-ai-rebellion/