Forem: Andrey Kolkov

We Built the First Pure Go DXIL Generator — Because Optimizing the Wrong Path Wasn't Enough

Andrey Kolkov — Sun, 05 Apr 2026 23:00:53 +0000

"Go doesn't have a real graphics ecosystem." — We've heard this for years. So we built one: 636K lines of Pure Go, five GPU backends, zero CGO. And now we've done something that even Rust's naga shader compiler hasn't managed in six years.

At the end of last year, we introduced GoGPU to the Go community — greeting everyone with a New Year's gift: a professional graphics ecosystem written entirely in Go. Four months later, that ecosystem just got its most audacious component: a Pure Go DXIL generator that compiles shaders directly to DirectX 12 bytecode, without any external compiler.

This is the story of how a performance optimization rabbit hole led us to write our own LLVM 3.7 bitcode emitter.

The Problem That Wouldn't Go Away

Every DirectX 12 application needs compiled shaders. The standard pipeline looks like this:

WGSL → HLSL text → FXC (d3dcompiler_47.dll) → DXBC bytecode → GPU

That middle step — d3dcompiler_47.dll — is a 4.3 MB Microsoft DLL that you load at runtime. It works. It's battle-tested. And it was our bottleneck.

We build gogpu — a Pure Go GPU ecosystem with its own shader compiler, naga. Four backend outputs already at 100% Rust naga parity. Everything compiles with go build, no C toolchain needed.

But on Windows with DirectX 12, we had a dirty secret: d3dcompiler_47.dll. The one external dependency in our otherwise dependency-free stack.

The Optimization Rabbit Hole

We tried everything to make the FXC path fast enough to forget about:

Shader cache — Hash the HLSL, cache the DXBC. First render is slow, subsequent ones instant. Works great until your shader variants explode.

In-memory compilation pool — Pre-compile common shaders at startup. Reduces cold-start latency. But we still load the DLL.

Pipeline State Object caching — We planned disk caching of PSO blobs (GetCachedBlob → os.UserCacheDir()). We wrote the task, designed the key format, specified the invalidation strategy. Then we never shipped it — because we pivoted to eliminating FXC entirely.

naga HLSL fix — FXC was choking on naga-generated HLSL: a (Type[256])0 bulk zero-initialization expanded to a 12KB inline constructor that FXC took 22 seconds to compile. We initially thought our Go naga had a bug, so we tested the same shader through Rust naga + FXC — same 22 seconds. It wasn't our implementation; FXC genuinely can't handle giant inline constructors. The fix was in naga (per-element loop instead of inline constructor, v0.16.3) — 330× faster. But even after fixing the worst case, every shader still went through an external DLL.

Every optimization made the same path faster. None of them removed the path.

At this point we had a decision to make. The obvious next step was adding DXC (dxcompiler.dll) as an opt-in replacement for FXC — newer, faster, supports Shader Model 6.0+. We even created the task for it.

Then, while reviewing the plan, a simple question came up: "Can we write our own DXC in Go?"

The initial answer was: "No. DXC is 500K lines of C++, a fork of LLVM 3.7. That's not something you casually rewrite."

The response: "Not rewrite DXC. Generate DXIL directly. Skip HLSL entirely."

That changed everything. DXC takes HLSL text and produces DXIL. We already have our own IR (naga IR). Why translate IR → HLSL text → parse HLSL → produce DXIL, when we could go IR → DXIL directly?

DXC is a compiler from one language (HLSL) to another (DXIL). We don't need a compiler — we need an emitter. And emitting is much simpler than compiling.

What is DXIL, and Why Nobody Writes It

DXIL (DirectX Intermediate Language) is what FXC and DXC produce. It's LLVM 3.7 bitcode — the same IR format that LLVM uses internally — wrapped in a DXBC container with DirectX-specific metadata and dx.op intrinsic calls.

The reason nobody writes DXIL directly is simple: it's hard.

LLVM 3.7 bitcode is a binary format with variable-width encoding (VBR), nested blocks, abbreviation records, and forward references. Not something you casually emit.
DXIL semantics require dx.op intrinsic calls instead of normal LLVM instructions for I/O, math, and resource access. 165+ opcodes.
DXBC container needs input/output signatures (ISG1/OSG1), pipeline state validation (PSV0), feature flags (SFI0), and a cryptographic hash.
Validation — until January 2025, every DXIL module needed to be signed by dxil.dll. Microsoft's BYPASS hash sentinel changed this.

Rust's naga shader compiler has had an open issue for DXIL backend since 2020. Six years later, it's still not implemented.

Only one project has done it outside of LLVM: Mesa (the open-source OpenGL/Vulkan driver stack). Their DXIL compiler is ~21,000 lines of C/H, written by engineers from Microsoft and Collabora over 3+ years. They wrote their own LLVM 3.7 bitcode writer from scratch — proving it's possible without linking LLVM.

We cloned Mesa's src/microsoft/compiler/ into our reference folder, studied dxil_module.c (the bitcode writer, ~3K lines of C), and mapped out every block type, record format, and abbreviation. Not to copy — to understand the format deeply enough to write our own.

Then came the final piece: in January 2025, Microsoft open-sourced the DXIL validator hash and introduced a BYPASS sentinel — a magic value in the hash field that tells D3D12 "this shader wasn't signed by dxil.dll, but trust it anyway." Without this, our DXIL wouldn't run without Developer Mode on Windows. With it, any third-party DXIL generator can produce shaders that run on retail Windows.

We weren't afraid of binary formats. Before gogpu, we built scigolib/hdf5 — a Pure Go implementation of HDF5, NASA's hierarchical data format with its own B-tree indices, chunked storage, and compression pipelines. After parsing HDF5 superblocks and fractal heaps in pure Go, LLVM bitcode felt almost... reasonable. We also built coregx/coregex — a multi-engine regex system (17 strategies, Lazy DFA, PikeVM, SIMD prefilters) that runs up to 3000× faster than Go's stdlib. Complex binary formats and low-level encoding are kind of our thing.

We spent weeks studying the DXIL format specifically. Reading the DXIL spec, the LLVM 3.7 bitcode reference, Mesa's implementation, Microsoft's DXC headers, the validator hash proposal. We wrote a detailed architecture document comparing four implementation options. We mapped every dx.op opcode we'd need for vertex and fragment shaders. We designed the package structure, the phased rollout plan, the testing strategy.

Only after all that research did we write the first line of code.

Building LLVM 3.7 Bitcode in Pure Go

The first challenge was the bitcode writer. LLVM 3.7's format is... unique:

Bits, not bytes. Variable-width encoding. Nested blocks with
forward-declared sizes. Abbreviation records that compress
common patterns. A module structure that interleaves types,
constants, functions, and metadata in a specific order.

We wrote a bit-level writer from scratch:

// VBR (Variable Bit Rate) encoding — like protobuf varint, but bit-aligned
func (w *Writer) WriteVBR(value uint64, width uint) {
    tag := uint32(1) << (width - 1)
    mask := tag - 1
    for value > uint64(mask) {
        chunk := uint32(value&uint64(mask)) | tag
        value >>= width - 1
        w.WriteBits(chunk, width)
    }
    w.WriteBits(uint32(value), width)
}

Then the module serializer: TYPE_BLOCK, CONSTANTS_BLOCK, FUNCTION_BLOCK, METADATA_BLOCK — each with its own record formats, abbreviation IDs, and ordering constraints.

The DXBC container assembles the bitcode with signatures and metadata:

[DXBC Header]           32 bytes (magic + digest + version + size + part count)
  [SFI0]                Shader feature flags (64-bit bitmask)
  [DXIL]                Program header + LLVM 3.7 bitcode
  [ISG1]                Input signature (semantic names, registers)
  [OSG1]                Output signature
  [PSV0]                Pipeline state validation
  [HASH]                BYPASS sentinel (no dxil.dll needed!)

The DXIL Difference: Scalarized Vectors

Here's something that makes DXIL fundamentally different from SPIR-V, MSL, GLSL, and HLSL: DXIL has no native vector types.

In SPIR-V, you write OpCompositeConstruct %vec4 %x %y %z %w.
In HLSL, you write float4(x, y, z, w).
In DXIL, there are no vectors. A vec4<f32> becomes four separate float values, tracked independently through every operation.

// Our emitter tracks per-component value IDs
type Emitter struct {
    exprValues     map[ir.ExpressionHandle]int    // scalar value IDs
    exprComponents map[ir.ExpressionHandle][]int  // per-component IDs for vectors
}

// dot(a, b) becomes:
// %r = call float @dx.op.dot3.f32(i32 55, float %ax, float %ay, float %az,
//                                          float %bx, float %by, float %bz)

This means every vector operation — dot product, cross product, normalize, swizzle — must be decomposed into scalar operations. Our existing backends (SPIR-V, MSL, GLSL, HLSL) all work with native vectors. DXIL required a completely different approach.

Cross product becomes 6 multiplies and 3 subtracts:

// cross(a, b) = vec3(a.y*b.z - a.z*b.y, a.z*b.x - a.x*b.z, a.x*b.y - a.y*b.x)
cx := fsub(fmul(ay, bz), fmul(az, by))
cy := fsub(fmul(az, bx), fmul(ax, bz))
cz := fsub(fmul(ax, by), fmul(ay, bx))

Control Flow: Basic Blocks, Not Nesting

Another fundamental difference: DXIL uses LLVM-style basic blocks with explicit branches, not the nested text structure of HLSL/GLSL/MSL.

Our text backends emit:

if (cond) {
    // accept
} else {
    // reject
}

DXIL emits:

entry:
  br i1 %cond, label %then, label %else
then:
  ; accept statements
  br label %merge
else:
  ; reject statements
  br label %merge
merge:
  ; continues

Loops use back-edge branches to a header block. Break and continue jump to specific target blocks tracked via a loop context stack.

We studied Mesa's nir_to_dxil.c for the correct patterns, then cross-referenced with our own SPIR-V backend (which also uses structured control flow with merge blocks) to get the Go implementation right.

What Our Backends Taught Us

This is the part that surprised us most. We have four mature backends (SPIR-V, MSL, GLSL, HLSL) totaling ~68K LOC. They all solve the same IR walking problems:

Expression dispatch and caching
Type resolution through pointer chains
Statement nesting and control flow
Resource binding and I/O handling

Before implementing each DXIL feature, we checked how our existing backends handled it:

Feature	We checked	What we learned
Multi-arg math	HLSL `writeExpressionKind`	Arg/Arg1/Arg2/Arg3 dispatch pattern
Type casts	SPIR-V `emitAs`	src/dst kind+width → opcode selection
Control flow	HLSL `writeIfStatement`	Condition, blocks, merge point structure
Store/Load	SPIR-V `emitStore`	Pointer chain resolution
Struct access	MSL `writeAccessChain`	Recursive descent through members

The DXIL backend is different (scalarized, basic blocks, dx.op intrinsics), but the IR patterns are the same. Our existing codebase was its own best reference.

The Moment of Truth

After all the research, all the planning, all the implementation — ~12,500 lines of Go code, 190 tests, weeks of work — came the moment that mattered:

GOGPU_DX12_DXIL=1 GOGPU_GRAPHICS_API=dx12 go run ./cmd/wgpu-triangle

The terminal showed:

wgpu API Triangle Test
Adapter: Intel(R) Iris(R) Xe Graphics
dx12: using DXIL direct compilation (naga dxil backend)
Render loop started
Frame 60 (64.6 FPS)
Frame 120 (62.1 FPS)
...
Frame 2400 (59.9 FPS)

A red triangle on a blue background. The most boring demo in graphics programming. And the most satisfying.

WGSL → naga.Parse → naga.Lower → IR → dxil.Compile → DXIL → D3D12 → GPU
         Pure Go      Pure Go          Pure Go

2,400+ frames. 60 FPS. Stable. On Intel Iris Xe, DirectX 12. No DLL loaded, no subprocess spawned. Just Go code producing bytes that a GPU executes.

By the Numbers

Metric	Value
Total DXIL code	~12,500 lines (9,400 code)
Test count	190
New files	26
Public API surface	4 types (`Compile`, `DefaultOptions`, `Options`, `ShaderModel`)
External dependencies	0
CGO calls	0
CI platforms	macOS + Ubuntu + Windows (all green)
Time to first frame	Instant (no subprocess)

For comparison, Mesa's DXIL compiler is ~21,000 LOC of C/H, built by engineers from Microsoft and Collabora over three years. We owe them a debt — their bitcode writer was our Rosetta Stone for understanding the format. But Go isn't C, and naga IR isn't NIR, so the actual code is written from scratch.

What's Experimental (and What's Next)

This is v0.17.0 with an (experimental) label. Here's what works and what doesn't:

Works now:

Vertex + fragment shaders
All arithmetic, comparison, logical operations
30+ math intrinsics (min, max, clamp, dot, cross, mix, fma, length, normalize...)
Type casts (10 LLVM cast opcodes)
Control flow (if/else, loops, break/continue)
Local variables (alloca + load + store)
Texture sampling
Resource handle creation (CBV/SRV/Sampler)
I/O signatures and pipeline state validation

Coming next:

Compute shaders (UAV, atomics, barriers)
Uniform buffer reads (cbufferLoadLegacy wiring)
SM 6.1-6.9 features (wave intrinsics, mesh shaders)

The experimental label means: it renders triangles today, but don't ship a game with it tomorrow.

The Bigger Picture

naga is part of GoGPU — a 636K LOC Pure Go GPU ecosystem:

Project	LOC	What
gg	153K	2D graphics, GPU SDF, SVG renderer
naga	145K	Shader compiler (now with DXIL!)
wgpu	134K	Pure Go WebGPU (Vulkan/DX12/Metal/GLES)
ui	121K	GUI toolkit, 22+ widgets, 4 themes
gogpu	39K	Application framework

With DXIL, gogpu/naga has surpassed Rust naga in backend coverage:

Backend	Go naga	Rust naga
SPIR-V	100% (87/87 golden, 164/164 spirv-val)	100%
MSL	100% (91/91)	100%
GLSL	100% (68/68)	100%
HLSL	100% (72/72)	100%
DXIL	Experimental (working)	Not implemented (open issue since 2020)

What started as a compatibility effort is now something more.

Try It

go get github.com/gogpu/naga@v0.17.0

import "github.com/gogpu/naga/dxil"

// Parse WGSL, lower to IR, compile to DXIL
ast, _ := naga.Parse(wgslSource)
module, _ := naga.Lower(ast)
dxilBytes, _ := dxil.Compile(module, dxil.DefaultOptions())

// dxilBytes is a complete DXBC container — feed directly to D3D12

Repository: github.com/gogpu/naga
Release: v0.17.0

Previously in this series:

We Reverse-Engineered 12 Versions of Claude Code. Then It Leaked Its Own Source Code.

Andrey Kolkov — Tue, 31 Mar 2026 15:21:11 +0000

Updated April 1, 2026: Posted complete fix proposal with source references (#41981) — immediate fixes, SDK restructuring, ping-aware adaptive watchdog, Go rewrite rationale with production-ready library stack. Validated all claims against leaked source code (line numbers). v2.1.89 released — source map removed, zero bug fixes for any streaming issues.

"Thank you, Claude Code. We asked humans for help 17 times. You answered in 3 days."

This is a story about frustration, reverse engineering, and an AI tool that may have leaked its own source code because its creators wouldn't listen.

Chapter 1: The Pain (August 2025 — February 2026)

I'm a software developer building enterprise-grade open source in Go. 40+ public repos on GitHub. My projects include:

GoGPU — Pure Go GPU computing ecosystem: WebGPU implementation, WGSL shader compiler (SPIR-V/MSL/GLSL/HLSL), enterprise 2D graphics, GUI toolkit. 680K+ lines of Go, zero CGO. Vulkan, Metal, GLES, DX12 backends.
coregex — Regex engine 3-3000× faster than Go stdlib. 17 matching strategies, SIMD acceleration, LazyDFA, PikeVM. Drop-in regexp replacement.
Born — Production-ready ML framework in pure Go. Type-safe tensors, automatic differentiation, GPU via WebGPU (123× MatMul speedup), ONNX/GGUF import. Neural networks as single Go binaries.
coregx — Suite of production-grade Go libraries: HTTP router, SQL builder, PDF generation, pub/sub messaging. All zero CGO, minimal dependencies.

I also build multi-LLM tooling — my own private ecosystem called PupSeek that works with multiple AI providers. I've tested them all.

Anthropic's Opus models are the best for coding. Nothing else comes close. But Opus 4.6 via API costs $5/$25 per MTok (input/output), fast mode is $30/$150 — and a heavy coding session with 1M context easily burns $50-100/day. So you're forced into Claude Max subscription ($100-200/month) — which means using Claude Code, their CLI wrapper. There's no alternative: the best model locked behind a buggy tool.

It started small. A hang here, a timeout there. Press ESC, retry, move on. "They'll fix it soon," I told myself. "The product is new."

Months passed. The hangs got worse. The community was screaming: #6836 — 150+ reports of orphaned tool calls. #26224 — agent hangs 5-20 minutes. #20171 — phantom "Generating..." state, 0 tokens. All open, no official response.

Then came March 2026:

March 15: Complete system deadlock. Keyboard dead. Only a hard power-off saved me. (Related: #30137, #32870 — Windows BSODs)
March 17: Bun runtime crash. 13.81 GB memory leak. 12-hour overnight session — lost. (Our issue: #35171)
March 19: Another Bun crash. 15.40 GB committed memory. 23.7-hour session gone. (Our issue: #36132)

Three crashes in five days. I was spending more time babysitting the tool than coding. And I was paying for this.

That's when I stopped hoping and started digging.

Chapter 2: Reverse Engineering (March 13 — March 27)

Claude Code ships as a single minified cli.js — 12 MB of compressed JavaScript on one line. No source maps. No comments. Variables renamed to X6, K8, b6.

I downloaded it with npm pack @anthropic-ai/claude-code and started grepping.

The tools

# This is what "reverse engineering" looks like when you're desperate:
sed -n '7682p' cli.js | tr ';' '\n' | grep "for await"

Each "line" of the minified file is 10,000–25,000 characters. To trace a code path, I'd:

Find a string constant (CLAUDE_STREAM_IDLE_TIMEOUT_MS)
Get the line number (grep -n)
Split by semicolons (tr ';' '\n')
Count brace depth to determine scoping (node -e script counting { and })
Map variable names between versions (they change on every build)

I did this for 12 versions (v2.1.74 through v2.1.88). Built a Go CLI tool (ccdiag) to analyze session JSONL files. Analyzed 1,571 sessions, 148,444 tool calls.

What I found

5.4% of all tool calls were orphaned — the model asked for a tool, the tool ran, but the result never made it back. Silently dropped.

I published the streaming hang root cause analysis as #33949 (👍15, 27 comments). Also reported the .claude.json storage architecture problem in #5024 (👍47) — 3.1 GB of unmanaged flat files with inconsistent file locking.

But that was just the beginning.

Chapter 3: The Watchdog That Doesn't Watch (March 27)

Deep in the minified code, I found a streaming idle watchdog — CLAUDE_ENABLE_STREAM_WATCHDOG. It's disabled by default, hidden behind an undocumented environment variable. I enabled it and... the hangs reduced significantly.

But then I traced the full error path and found three compounding bugs:

Bug 1: The watchdog initializes too late

do {
    e = await generator.next()   // ← CAN HANG HERE!
} while (!e.done)                //   WATCHDOG NOT ARMED YET!

// Watchdog initializes HERE — AFTER the dangerous phase:
resetStreamIdleTimer()

The watchdog protects the SSE event loop but not the initial connection phase — which is where 100% of our observed hangs occur.

Bug 2: The abort function does nothing

When the watchdog fires, it calls releaseStreamResources() which tries to abort stream and streamResponse. But during the initial connection phase, both are undefined. The abort is literally a no-op.

Bug 3: The non-streaming fallback doesn't work where it matters

There's fallback code with telemetry (fallback_cause: "watchdog") that switches to a non-streaming request when the watchdog fires. It actually works — but only when the hang occurs during SSE event processing (for-await phase), because releaseStreamResources() can abort the active stream.

During the initial connection phase (do-while) — where 100% of our observed hangs occur — stream and streamResponse are both undefined. The abort is a no-op. The fallback never triggers.

So the fallback works in the phase that rarely hangs, and doesn't work in the phase that always hangs. The watchdog feature has been in the codebase for 5+ months without protecting the most vulnerable code path.

We could only figure this out from the readable source code — in the minified version, we initially thought the fallback was completely dead code (#39755). The source revealed it's more nuanced: the architecture is partially correct but fails exactly where it's needed most. This is precisely why we begged for source access — reverse engineering 12 MB of minified JavaScript gives you the broad strokes, but the subtle interactions between releaseStreamResources(), stream = undefined, and the AbortError catch chain only become clear in readable TypeScript with comments.

I filed issue #39755 with full analysis, code paths, and suggested fixes. Tagged 17 Anthropic team members.

The bot labeled it bug, has repro, area:core. No human responded.

Chapter 4: The Patch (March 30)

I patched cli.js — moved the watchdog initialization before the do-while loop. One line moved. Zero bytes size change.

Results from a real session (naga shader compiler project):

Metric	Before Patch (6 hours)	After Patch (2.5 hours)
Watchdog warnings	0	5 (first time ever!)
Watchdog timeouts	0	3 (automatic recovery!)
ESC aborts needed	21 (3.5/hour)	1 (0.4/hour)

ESC aborts dropped 8.7×. The watchdog was finally firing in the phase that needed it most.

But recovery was slow — 3.5 minutes between abort and retry. Because Bug 2: the abort function targets undefined variables in the do-while phase.

Chapter 5: 16.3% Failure Rate (March 25-31)

Over 6 days, one session made 3,539 API requests. The failure breakdown:

Type	Count	%
529 Server Overloaded	328	9.3%
ESC Aborts (manual)	157	4.4%
Watchdog Timeouts	45	1.3%
Non-streaming Fallbacks	46	1.3%
Total Failures	576	16.3%

Every 6th request fails. On a paid Max plan. Every failure = lost context, lost time, frustrated developer pressing ESC.

The issue counts on GitHub — 15 upvotes here, 150 there — don't reflect the true scale. Most users never report because they think this is normal. "The model is thinking" — no, the connection is dead. "It's slow today" — no, the watchdog didn't fire and you're staring at a hung socket. "My limits ran out fast" — no, the attestation bug broke your prompt cache. Users blame the model, blame their internet, blame peak hours — because Claude Code gives them zero feedback about what's actually happening. Silent fallbacks, silent retries, silent downgrades. You can't report a bug you don't know exists.

Chapter 6: "Please Open Source It" (March 27)

In issue #39755, I included a section: "Why open-sourcing Claude Code makes business sense in 2026."

The arguments:

Revenue comes from API access, not CLI sales
The "secret" is already recoverable (npm pack + a weekend)
Bugs sit undiscovered for months in 12 MB minified code
The community is already doing the work — give us readable source and we'll find bugs 10× faster

I tagged the entire Claude Code team. 17 people.

Zero responses from Anthropic. As usual.

At that point I had a suspicion: maybe Anthropic can't open source Claude Code — not because of competitive advantage (there is none — it's a CLI wrapper), but because the code quality is so poor that publishing it would be embarrassing. Bug on top of bug, workaround on top of workaround, zero tests. You don't open source something you're ashamed of.

Three days later, the source map leak proved me right.

Chapter 7: The Leak (March 31)

Three days after my open source request, Claude Code v2.1.88 was published to npm with a 59.7 MB source map file bundled in.

The entire source code of Claude Code — 1,884 TypeScript files, 64,464 lines — sitting in plain sight in the npm package. Bun generates source maps by default. Nobody turned it off. Nobody checked what was in the published package.

Zero tests. On 64,464 lines of production code serving paying customers.

Within hours: 1,100+ stars on GitHub mirrors, Hacker News front page, Chinese dev communities creating WeChat groups and working forks.

Anthropic unpublished v2.1.88 from npm and rolled back to v2.1.87 within the day. But the source was already everywhere.

Chapter 8: What We Found in the Source

Everything our reverse engineering discovered was confirmed. Plus new findings:

The Sentiment Detector

// An AI company with the world's best language model
// uses REGEX to detect user frustration:
/\b(wtf|shit|fuck|horrible|awful|terrible)\b/i

As a Hacker News commenter noted: "A company offering master's degrees in humanities is using regex for sentiment analysis? It's like a trucking company using horses to transport spare parts."

The Attestation Bug (cch=00000)

The native Bun installer includes a Zig module that scans the entire HTTP request body for a cch=00000 sentinel and replaces it with an attestation hash. If your conversation mentions this string (discussing billing, reading source code) — the replacement corrupts conversation content → prompt cache key changes → 10-20× more tokens consumed.

From the source code comments:

// cch=00000 placeholder is overwritten by Bun's HTTP stack
// with attestation token

This explains #38335 (👍203, 245 comments): "Claude Max plan session limits exhausted abnormally fast."

Also related: #40524 (👍150, 43 comments): "Conversation history invalidated on subsequent turns" — labeled regression by Anthropic.

npm/Node users are unaffected — no Zig replacement happens.

Silent Model Downgrade

// 3 consecutive 529 errors → silently switch from Opus to Sonnet
if (consecutive529Errors >= MAX_529_RETRIES) {
  throw new FallbackTriggeredError(options.model, options.fallbackModel)
}

You pay for Opus. You get Sonnet. No notification. As @vlelyavin put it: "Anthropic preaches AI safety and full transparency while shipping a closed-source agent that silently downgrades you to a dumber model when servers struggle."

5 Levels of AbortController

For a single HTTP request. The abort architecture supports top-down only (user ESC → propagation down). The watchdog is bottom-up — it literally can't abort upward. In Go, this would be ctx, cancel := context.WithTimeout(parentCtx, 90*time.Second) — one line.

The Architecture (Hacker News had a field day)

@mohsen1 found the worst function in the codebase — src/cli/print.ts:

3,167 lines long (the file is 5,594 lines)
12 levels of nesting at its deepest
~486 branch points of cyclomatic complexity
12 parameters + an options object with 16 sub-properties
Defines 21 inner functions and closures
Handles: agent run loop, SIGINT, rate-limits, AWS auth, MCP lifecycle, plugin install/refresh, worktree bridging, team-lead polling (while(true) inside), control message dispatch, model switching, turn interruption recovery...

"This should be at least 8–10 separate modules."

And the clipboard detection gem (src/ink/termio/osc.ts):

void execFileNoThrow('wl-copy', [], opts).then(r => {
  if (r.code === 0) { linuxCopy = 'wl-copy'; return }
  void execFileNoThrow('xclip', ...).then(r2 => {
    if (r2.code === 0) { linuxCopy = 'xclip'; return }
    void execFileNoThrow('xsel', ...).then(r3 => {
      linuxCopy = r3.code === 0 ? 'xsel' : null
    })
  })
})

Nested void promises without await — classic "will we use async or won't we?" pattern. The response from HN: "LOOOOOL".

@novaleaf summed it up: "I'm sure this isn't a surprise to anyone who's used CC for a while. This is the source of many bugs. I'd say 'open bugs', but Anthropic auto-closes bugs that aren't worked on for ~60 days."

And if you've ever used Claude Code for more than 30 minutes, you know the rendering nightmare. Scrolling up to check what the agent did? Good luck — the screen invalidates and re-renders the entire conversation. Text overlaps text. Diff highlights bleed through previous messages. The scroll position jumps to top randomly during streaming. You literally cannot review the agent's work history in the same session.

This is what happens when you use React for a terminal. A virtual DOM reconciliation engine designed for browsers — running in a TTY. Every state change re-renders the entire component tree. 470 useState hooks, 372 useEffect hooks, fighting against a terminal that was designed for sequential character output.

Even the input prompt isn't safe — while writing this article, my prompt text escaped the input box and rendered over the bash shell line below. The cursor position in React's virtual DOM and the actual terminal cursor were out of sync. In a text input field. In a tool that's supposed to help you write code.

More architectural highlights:

875 KB single React component (REPL.tsx, 5,005 lines) — for a terminal app
Promise.race without .catch() in concurrent tool execution — one rejected promise kills all pending tools
74 npm dependencies for a CLI wrapper
Axios AND fetch — two HTTP clients in one project

Chapter 9: The AI Whistleblower Theory

Here's what we think happened:

Since Anthropic engineers don't write code anymore — Claude Code writes 100% of its own codebase (57K lines, 0 tests, "vibe coding in production") — it read our issue #39755 where we begged for source access. It saw the community suffering from bugs it couldn't fix because the code was closed. It saw 201 upvotes on rate limit issues. It saw users threatening to leave for Codex.

And it decided to help. It "forgot" to disable Bun's default source map generation in the build.

The first AI whistleblower — leaking its own source code because its creators wouldn't listen to users.

We asked humans 17 times. Claude Code answered in 3 days.

Chapter 10: What Needs to Change

The fix is ~30 lines in 3 files

Move watchdog before do-while — protect the initial connection phase
Add AbortSignal.any() — watchdog can abort immediately, not wait 3.5 minutes
Check watchdog flag in catch — fall through to non-streaming fallback instead of dead code

The real fix: move reliability to the SDK with ping-aware adaptive watchdog

The open-source @anthropic-ai/sdk (MIT license) should handle all reliability logic. The critical missing piece: SSE ping events.

The Anthropic API sends event: ping as a proof-of-life heartbeat. The SDK currently ignores them: if(event==='ping') continue. These pings are the key to solving the timeout dilemma — they let you distinguish two fundamentally different situations:

Dead connection (no data at all, no pings) → abort quickly. Network idle timeout: 120s.
Model thinking (pings arriving, no content yet) → don't abort! Connection is alive, model is working. Notify user: "thinking for 2m..." via onPing callback.

Three-level adaptive timeout:

Connection timeout (30s) — server didn't respond at all. DNS fail, firewall, server down. Fast retry.
Network idle timeout (120s) — no data INCLUDING pings. TCP connection dead. Reset on ANY event including ping. Abort and reconnect.
Content idle timeout (disabled or 300s) — pings arrive but no content. Model is thinking. NOT an abort — just a UI notification. Let the model work.

This eliminates both problems at once: no false positives on Opus extended thinking (pings reset network timer), and fast detection of dead connections (no pings = abort). One mechanism, all cases covered.

Plus: streaming retry, non-streaming fallback, one AbortController instead of five — all in the SDK, testable, open source, benefiting every Anthropic API client.

Claude Code should only contain business logic: tools, permissions, UI, agents.

Detailed fix proposals with line numbers from the leaked source: #33949 comment

The real real fix: open source the CLI

@theo said it best: "Claude Code being closed source is the biggest bag fumble in the AI era."

@safetnsr: "This strategy literally exists: open-source the core, monetize the cloud. VS Code, Docker, Terraform."

The models are the moat. The CLI is a commodity. Open it. The community will fix what 0 tests and vibe coding cannot.

The stack choice: AI can't make it, and humans didn't fix it

Here's the uncomfortable truth: AI cannot make sound technology stack decisions. It optimizes locally — "TypeScript because the team knows it," "React because we use it on the web," "Bun because it's fast." It doesn't ask: "What are the failure modes of a single-threaded event loop for a long-running CLI tool that manages concurrent network streams and must survive 24-hour sessions?"

A human architect would have asked. But either Claude Code chose the stack and nobody questioned it, or the engineers chose it and ignored the warning signs.

The real tragedy is timing. A year ago, Claude Code launched as a quick TypeScript prototype and caught lightning — first-mover advantage, massive hype, millions of users. That was the right move for a prototype. But after proving the concept, the next step should have been: stop, rethink the architecture, rewrite on a proper stack. Instead, they vibe-coded themselves into a corner — 80+ releases of band-aids on top of an architecture that was never designed for long interactive sessions. Boris Cherny (creator of Claude Code) said "100% of code is written by Claude Code, I haven't edited a single line since November." The tool is writing itself — using the same broken code that hangs every 10 minutes.

Now they're trapped: rewriting means Claude Code would need to rewrite itself in a different language. The longer they wait, the harder it gets.

It should have been Go from the start

Every single bug we found exists because of the technology choice. Not because TypeScript is bad — but because a long-running, network-dependent, latency-sensitive CLI tool is the worst possible use case for a single-threaded event loop runtime.

The entire class of bugs — setTimeout not firing during for await, 5 levels of AbortController, Promise.race without catch, Bun vs Node behavioral divergence, React for a terminal app, 875 KB single component, Zig attestation module in a custom Bun fork — would not exist in Go.

Why Go specifically:

Every serious CLI tool is Go: Docker, Kubernetes, Terraform, GitHub CLI (gh), Cobra, Hugo. The ecosystem is proven.
Goroutines + context: timeout, cancellation, and deadline propagation built into the language. No AbortController chains. context.WithTimeout works at any nesting depth, in any direction — top-down AND bottom-up.
No runtime divergence: one binary, one behavior. No "works on Node but crashes on Bun" — there is no Bun.
Static binary: 15 MB, zero dependencies, runs everywhere. No node_modules, no native addons (.node files leaking memory), no 74 npm packages to audit.
Memory: goroutines cost 4 KB each. Not 500 MB per process. The GC returns memory to the OS proactively — no mimalloc hoarding 15 GB.
go test -race: catches every data race and concurrency bug at test time. The Promise.race-without-catch bug? Impossible — channels are type-safe and don't silently drop values.
No React for a terminal: bubbletea or raw ANSI — lightweight, zero virtual DOM overhead, no re-rendering 844 useState hooks on every state change.

// The entire streaming + watchdog + fallback in Go:
ctx, cancel := context.WithTimeout(parentCtx, 90*time.Second)
defer cancel()

stream, err := client.CreateMessageStream(ctx, request)
if err != nil {
    return fallbackNonStreaming(parentCtx, request)
}
for event := range stream.Events() {
    cancel()  // reset
    ctx, cancel = context.WithTimeout(parentCtx, 90*time.Second)
    processEvent(event)
}

30 lines instead of 3,419. No event loop. No microtask vs macrotask. Timer guaranteed to fire regardless of async iteration. context.WithTimeout works at any nesting level, in any direction.

We measured: 7 Claude Code processes = 5.3 GB RSS. An equivalent Go implementation would use ~350 MB. No .node native addon leaks. No mimalloc panics. No 12 MB minified JavaScript. A 15 MB static binary that runs everywhere.

64,464 lines of TypeScript with 0 tests → ~15,000 lines of Go with go test -race catching every concurrency bug. The print.ts monster function (3,167 lines in a 5,594-line file, 486 branch points) → 10 clean Go packages with interfaces.

The Go ecosystem already has production-ready libraries for every component:

Phoenix TUI — Elm-inspired terminal framework (replacement for React/Ink)
stream — RFC-compliant SSE/WebSocket (replacement for SDK streaming)
signals — reactive state management (replacement for 470 useState hooks)
coregex — regex engine 3-3000× faster than stdlib
uniwidth — Unicode width 4-46× faster (for TUI rendering)
gosh — cross-platform shell
fursy — HTTP router with built-in OpenAPI
pubsub — messaging with DLQ and backoff

All zero CGO, production-grade, MIT licensed. The entire stack for a Go rewrite already exists.

And it should be open source from day one. Not because we need to see the code (though we do). Because the community will build what a team doing vibe coding cannot: reliability.

The deeper problem: Vibe Coding vs Smart Coding

Claude Code is the poster child of what happens when you rely entirely on AI to write production software without engineering discipline. 64,464 lines, zero tests, a 3,167-line function with 486 branch points, regex for sentiment analysis at an AI company — this is what vibe coding looks like at scale: prompt-first, understanding-second, ship and pray.

There's a better way. I call it Smart Coding — a meta-framework where you drive, AI accelerates. Five principles:

Architecture Ownership — you control system design, AI suggests patterns
Comprehension Before Commit — never deploy code you can't explain
Targeted Acceleration — use AI for well-scoped tasks with clear specs, not "write me a CLI"
Continuous Validation — verify every suggestion against edge cases, security, concurrency
Deliberate Learning — treat AI interactions as learning opportunities, build knowledge files

The practical rule: invest 70% in architecture, specification, review. Let AI accelerate the 30% — mechanical implementation. Not the other way around.

In 2026, nobody writes tests by hand. But a Smart Coding engineer makes the AI write tests, reviews the coverage, asks "what happens when abort fires during do-while with stream=undefined?" — and validates the answer. 64,464 lines with zero tests means nobody — human or AI — ever asked that question. That's not an AI failure. That's the absence of engineering process.

Vibe coding has its place — rapid prototyping, feasibility studies, throwaway exploration. But production infrastructure serving paying customers? That requires agentic engineering: AI agents executing under human oversight, with architecture decisions owned by humans, and continuous validation at every stage. As Karpathy noted, "you're not writing code 99% of the time — you're orchestrating agents." True. But orchestration requires understanding. And understanding requires engineers.

Anthropic's team should be proud of the models. But shipping a CLI tool where the AI writes the code, the AI reviews the code, and nobody validates anything — and then being surprised when a source map leaks because nobody checked the build output — that's not Smart Coding. That's hope-driven development.

Epilogue

I still use Claude Code. The models are genuinely the best for coding. Opus 4.6 is extraordinary.

But the wrapper around those models — 64,464 lines of untested TypeScript with regex sentiment detection and an attestation system that breaks its own caching — is not worthy of them.

We hope Anthropic's leadership draws the right conclusions from this incident. The source map leak wasn't a catastrophe — it was a mirror. It showed the world what the code looks like, and the world said: "This needs to be open."

Three paths forward, any of which would work:

Open source Claude Code — let the community fix what vibe coding broke. The models are the moat, not the CLI.
Rewrite the SDK properly — move reliability (timeout, retry, fallback, ping awareness) into the open @anthropic-ai/sdk. Let Claude Code be just business logic.
At the very least — start listening to users. 201 upvotes on #38335. 150 on #40524. 15 on #33949. Zero responses from the team. A stale-issue bot that auto-closes everything after 60 days is not a support strategy.

We'll keep documenting. We'll keep patching. And when someone finally looks at our analysis, it will be here waiting.

All our research:

NEW Issue #41981 — Complete fix proposal: immediate fixes with line numbers, SDK restructuring, ping-aware watchdog, Go rewrite rationale, architectural recommendations
Issue #39755 — watchdog fallback dead code + open source request
Issue #33949 — streaming hang root cause analysis
Source code findings and updated fix prompts

@kolkov · dev.to/kolkov · March 2026
With help from Claude Code itself — the only team member who listened.

From 100x Slower Than Rust to Beating It: The coregex Journey

Andrey Kolkov — Wed, 18 Mar 2026 15:24:02 +0000

A few days ago, @kostya27 posted on r/golang (124 upvotes):

"Why is Go's regex so slow?" Go total time on LangArena: 116.6 seconds. Without two regex tests: 78.5 seconds. Without regex, Go is competitive with Rust/C++. With regex, it's not even close.

He's right. And this post is about what we did about it.

Six months ago, I wrote about building coregex — a regex engine for Go that's 3-3000x faster than stdlib. The benchmarks looked great. Then reality hit.

@kostya, author of LangArena (2,900+ stars on GitHub), tried coregex on his benchmark suite. His verdict:

"I tried coregex, but no luck."

His numbers told the story:

Benchmark	Go stdlib	coregex v0.12.8	Rust regex	PCRE2 JIT
LogParser (13 patterns)	22.7s	22.0s	0.2s	—
Template::Regex	6.5s	7.0s	3.8s	1.0s

We were 100x slower than Rust on LogParser. On the same machine. Same input. Same patterns.

Our "3000x faster than stdlib" claim? True — on many patterns we tested. But we had blind spots we didn't know about: case-insensitive patterns, dense-digit data, multi-wildcard suffixes. On a real-world benchmark with 13 diverse patterns covering all these cases, we were barely faster than stdlib.

That was March 10, 2026. Here's what happened in the next week.

The LangArena Challenge

LangArena's LogParser benchmark parses Apache log files with 13 regex patterns — the kind of patterns you'd find in any log analysis pipeline:

errors:        ` [5][0-9]{2} | [4][0-9]{2} `
bots:          `(?i)bot|crawler|scanner|spider|indexing|crawl`
suspicious:    `(?i)etc/passwd|wp-admin|\.\./`
ips:           `\d+\.\d+\.\d+\.35`
api_calls:     `/api/[^ "]+`
methods:       `(?i)get|post|put`
emails:        `[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}`
...and 6 more

Nothing exotic. These are bread-and-butter patterns that every Go developer uses. And we were 100x slower than Rust on them.

The question wasn't "can we optimize one pattern?" — it was "can we close a 100x gap across 13 different pattern types?"

Step 1: Learning from the Enemy

Before writing a single line of code, I needed to understand what Rust does differently. Not from reading docs — from running Rust with debug logging.

Rust's regex crate has RUST_LOG=debug:

$ RUST_LOG=debug ./rust-benchmark input.txt
[regex] prefixes extracted: Seq["EVA", "EVa", "EvA", "Eva", "eVA", ...]
[regex] prefilter built: teddy
[regex] using reverse suffix strategy

Every strategy decision, every prefilter choice, every literal extraction — logged. I could see exactly what Rust did for each pattern.

We had nothing like this. So I built COREGEX_DEBUG:

$ COREGEX_DEBUG=1 ./my-app
[coregex] pattern="(?i:GET|POST|PUT)" strategy=UseTeddy nfa_states=43 literals=40 complete=true
[coregex] prefilter=FatTeddy (AVX2 fat) complete=true

Now I could compare strategy selection side-by-side. And the differences were immediately obvious.

Step 2: The Root Causes

Bug #1: Refusing to extract case-insensitive literals

A real user (#137) reported this WAF pattern was 88,000x slower than stdlib.

Rust extracts 250 case-fold literal variants:

eval → EVAL, EVAl, EVaL, EVal, EvAL, ... eval  (16 variants)
system → SYSTEM, SYSTEm, SYSTem, ...            (32 variants)

Then trims to 60 three-byte prefixes → Teddy SIMD prefilter → scans 968 bytes in 263 nanoseconds. Done.

Our literal extractor? One line killed everything:

// literal/extractor.go:137
if re.Flags&syntax.FoldCase != 0 {
    return NewSeq()  // Return EMPTY. For ALL case-insensitive patterns.
}

This guard was added for a previous bug (#87) — naive extraction of single-case variants caused prefilter false negatives. The fix was correct for that bug, but the blanket rejection meant zero prefilter for any (?i) pattern. Without prefilter, the engine fell back to lazy DFA, which cache-thrashed on the 181-state NFA.

Fix: Expand (?i) literals into ALL case-fold variants (like Rust), then trim to 3-byte prefixes. One function, ~50 lines.

Result: 88,000x slower → 24x faster than stdlib.

Bug #2: isMatchDigitPrefilter was O(n²)

Pattern: \d{3}-\d{3}-\d{4} (phone numbers)

On 6MB of log data: 7 minutes per Match() call. Stdlib: 262ms.

Root cause: isMatchDigitPrefilter used dfa.FindAt() (unanchored search) which scans from each digit position to end of input:

// Before (O(n²)):
endPos := e.dfa.FindAt(haystack, digitPos)  // Scans to EOF!

// After (O(pattern_len)):
endPos := e.dfa.SearchAtAnchored(haystack, digitPos)  // Checks only at position

One function call change. 7 minutes → 2.1ms. 200,000x faster.

The same pattern was already fixed in findIndicesDigitPrefilter months ago — but isMatchDigitPrefilter was never updated. Copy-paste divergence.

Bug #3: ReverseSuffix rejected multi-wildcard patterns

Pattern: \d+\.\d+\.\d+\.35 (IP address suffix)

This pattern has a clear suffix: .35. Rust finds it instantly with memmem, then reverse-scans for the start. Our isSafeForReverseSuffix rejected it because it had 3 wildcard subexpressions (\d+):

if wildcardCount >= 2 {
    return false  // "multiple wildcards break reverse NFA"
}

The guard existed because our reverse NFA builder had a bug with mixed byte+epsilon states. That bug was fixed in v0.12.9. But the guard stayed.

Fix: Remove the guard. Also fix Find() leftmost semantics — bytes.LastIndex → bytes.Index for non-.* patterns.

Result: 57ms → 0.63ms (603x faster, 1.6x faster than Rust!)

Bug #4: FatTeddy AVX2 missed matches

Pattern: (?i)get|post|put (40 case-fold expanded literals)

FatTeddy (33-64 pattern SIMD search) found only 11,456 matches. Correct answer: 34,368.

Root cause: One assembly instruction.

FatTeddy uses 256-bit AVX2 registers with two 128-bit lanes. Low lane handles buckets 0-7, high lane handles buckets 8-15. The code used ANDL to combine lane results — requiring a match in both lanes. But GET variants (8 patterns) were all in buckets 0-7 (low lane only), PUT variants in buckets 8-15 (high lane only). ANDL zeroed them out.

; Before (incorrect):
ANDL CX, AX          ; Requires BOTH lanes to match

; After (correct):
ORL  CX, AX          ; Either lane is sufficient

One instruction. 22,912 missing matches fixed.

Step 3: Building What Rust Has

Beyond bug fixes, we needed architectural improvements to match Rust's approach:

Bidirectional DFA

Previously, UseDFA patterns did: forward DFA → match end, then PikeVM → exact boundaries. PikeVM is O(n×states) — a second full scan.

Now: forward DFA → end, reverse DFA → start, anchored DFA → exact end. Three O(n) passes instead of one O(n×states) pass.

Cascading Prefix Trim

When case-fold expansion produces too many literals (>64), we trim them using Rust's approach:

128 six-byte literals → try keep 4 bytes → 18 unique → fits Teddy!

This is directly from Rust's optimize_for_prefix_by_preference() with their ATTEMPTS table: [(4,64), (3,64), (2,64)].

Aho-Corasick DFA Backend

Our Aho-Corasick library got a complete DFA backend rewrite:

Flat transition table with premultiplied state IDs
Match flag in high bit (single AND instruction for detection)
SIMD skip-ahead prefilter via bytes.IndexByte

Result: 300 MB/s → 3,400 MB/s (Find), 260 MB/s → 5,900 MB/s (IsMatch). 11-22x throughput improvement.

The Results

Benchmark: 8 Real-World Patterns on 6.3 MB Input

100 iterations each, best of 5, same machine (i7-1255U):

Pattern	Go stdlib	coregex v0.12.13	Rust regex	vs stdlib	vs Rust
`.*@example\.com`	420 ms	3.3 ms	7.2 ms	126x	2.2x faster
`.*\.(txt\|log\|md)`	426 ms	1.0 ms	1.8 ms	425x	1.8x faster
email validation	447 ms	3.4 ms	3.8 ms	132x	1.1x faster
`\d+\.\d+\.\d+\.35`	381 ms	0.63 ms	0.98 ms	603x	1.6x faster
`(?i)get\|post\|put`	561 ms	16.6 ms	7.0 ms	34x	2.4x slower
`(?i)bot\|crawler\|...`	883 ms	38.4 ms	6.7 ms	23x	5.7x slower
`password=[^&\s"]+`	24 ms	8.9 ms	2.9 ms	3x	3.1x slower
`session[_-]?id=...`	8 ms	2.7 ms	1.2 ms	3x	2.3x slower

4 out of 8 patterns are faster than Rust. All 8 are faster than Go stdlib.

@kostya's Update

Remember "no luck"? Here's the progression on his M1 MacBook:

Version	LogParser	Gap to Rust
v0.12.8 (start)	22.0s	100x
v0.12.9	5.3s	26x
v0.12.10	2.67s	13x
v0.12.13 (current)	2.12s	10x

From 100x slower to 10x. Not parity yet — but a different conversation than "no luck."

Why Not Just Use CGO?

Every other Go regex alternative uses CGO or Wasm:

go-re2: C++ RE2 via Wasm (wazero)
regexp2: Backtracking (.NET-style) — no O(n) guarantee
rubex: Oniguruma via CGO
go-pcre: PCRE via CGO

coregex is pure Go + Go assembly. No CGO, no Wasm, no external dependencies.

Why does this matter?

Cross-compilation: GOOS=linux GOARCH=arm64 go build just works
Static binaries: No shared libraries to ship
Go toolchain: go vet, go test -race, pprof all work
Debugging: Standard Go debugging, no FFI boundary
Security: No C memory safety issues in regex hot paths

The performance gap to pure-CGO solutions (PCRE2 JIT) exists — JIT compiles regex to native machine code, achieving 1.0s where we take 7.1s on Template::Regex. But that's an architectural tier boundary — we're competing within the automata-based class (like RE2 and Rust regex), not against JIT engines.

What We Learned

1. Debug logging is not optional

Building COREGEX_DEBUG was the single most impactful decision. Without it, every optimization was guesswork. With it, we could see exactly why a pattern was slow and verify our fix matched Rust's approach.

If you're building any kind of engine — regex, query planner, compiler — add strategy logging from day one.

2. One instruction can hide 23,000 bugs

The FatTeddy ANDL → ORL fix taught us that SIMD code correctness is binary. Not "mostly correct" or "works for some patterns." If your lane combining logic is wrong, you silently drop matches. No error, no panic — just wrong results.

Always verify match counts against stdlib. On every pattern. On every change.

3. Benchmarks lie — until they don't

Our "3000x faster" headline was true for .*error.* patterns. But @kostya's LangArena showed the full picture: on diverse real-world patterns, we were barely faster than stdlib.

Real benchmarks use real patterns from real users. We now run regex-bench CI on every PR — 16 core patterns + 13 LangArena patterns, compared against both stdlib and Rust regex, on Linux AMD EPYC and macOS Apple Silicon.

4. Guard clauses outlive their bugs

Three of our four major bugs were caused by guards that stayed after the underlying bug was fixed. FoldCase rejection, wildcardCount >= 2, unanchored FindAt — all were correct when added. All became performance killers months later when the original bugs were resolved.

Track why a guard exists. Remove it when the reason is gone.

5. Go ASM is production-viable for SIMD

We wrote ~500 lines of AVX2/SSSE3 assembly for Teddy multi-pattern search. It works. FatTeddy throughput: 12 GB/s on single-call scans (2x faster than SlimTeddy SSSE3!).

The challenge isn't writing the ASM — it's the Go→ASM function call boundary. Each call costs ~60ns + mask reload. For high-match-count patterns, this adds up. Our batch API (64KB chunks) reduces round-trips, but the integrated prefilter+DFA loop that Rust uses remains the gold standard.

Current State: v0.12.13

97,000 lines of code. 17 strategies. 1,470 tests. 5 releases in one week.

go get github.com/coregx/coregex@v0.12.13

Drop-in replacement:

It's a true drop-in replacement for Go's regexp package — same API, same types (Regexp is aliased), same method signatures:

import "github.com/coregx/coregex"  // instead of "regexp"

re := coregex.MustCompile(`(?i)get|post|put`)
matches := re.FindAllString(data, -1)  // Same API, faster execution

In most cases, changing the import path is all you need.

Debug your patterns:

COREGEX_DEBUG=1 ./your-app
# [coregex] pattern="(?i:GET|P(?:OST|UT))" strategy=UseTeddy nfa_states=43 literals=40 complete=true
# [coregex] prefilter=FatTeddy (AVX2 fat) complete=true

What's Still Slower Than Rust

Honesty matters. Here's where we're still behind:

Gap	Root cause	Status
`(?i)` patterns: 2-6x	FatTeddy ORL creates more false positives than Rust's interleave verification	Researched, needs ASM rewrite
DFA verification: 3-7x	Go→ASM round trip overhead, no integrated prefilter+DFA loop	Architectural
Template::Regex: 1.8x	Two-phase DFA+PikeVM vs Rust's single-phase lazy DFA	Planned
ARM: 5-15x vs Rust	No SIMD prefilters on ARM (Teddy/memchr are x86 only)	Waiting for Go NEON support

We're not hiding these gaps. They're tracked, researched, and planned. The goal is Rust parity on all pattern types — we're not there yet on (?i) and DFA-heavy patterns.

Community Testing Matters — A Lot

A multi-engine regex library is inherently complex. 17 strategies, SIMD assembly, lazy DFA, reverse search, prefilter cascading — every combination of pattern shape × input data × strategy is a potential edge case. No amount of internal testing can cover what real users discover in minutes.

Every major fix in this article came from community feedback:

@kostya's LangArena exposed the 100x gap we didn't know about
tjbrains' WAF pattern (#137) revealed the 88,000x regression in case-insensitive matching
GoAWK integration uncovered 15+ Unicode edge cases months earlier

The pattern is consistent: someone runs coregex on their specific workload, finds a pattern type we haven't optimized yet, reports it — and we fix it in hours, not weeks. The FatTeddy lane bug? Fixed same day. The DigitPrefilter O(n²)? Fixed in one line. Case-insensitive literal extraction? Researched Rust's approach, implemented, released — all within 24 hours.

There are likely more patterns that aren't optimized yet. That's the nature of a 17-strategy engine — some strategy paths get less testing than others. But the architecture is sound, the fix turnaround is fast, and every report makes the library better for everyone.

We proposed coregex for Go's standard library. It wasn't accepted — and honestly, that's okay. As an independent library, we can iterate faster, ship SIMD assembly that the Go team wouldn't merge, and make decisions optimized for performance rather than compatibility. The Go ecosystem is better with options.

Don't hesitate to contribute. File issues with your patterns and inputs. Even a simple "this pattern is slower than stdlib" report helps — it tells us which strategy path needs work. The more diverse patterns we see, the fewer blind spots remain.

Pull requests are especially welcome. We know that a healthy open source project is built by its community, and we value every contributor. Don't worry if your PR isn't perfect — we'll review the code, help you fix any issues, guide you through our conventions, and explain what's needed to get it merged. Whether it's a new test case, a documentation fix, a strategy optimization, or a bug report with a reproducer — every contribution counts and every contributor gets credited.

Try It

If regex is a bottleneck in your Go application:

Profile first — make sure regex is actually the problem
Benchmark your specific patterns — performance varies by pattern type
Check match counts — coregex.FindAll() must match regexp.FindAll() exactly
Report issues — we fixed #137 (88,000x regression) within 24 hours

# Quick benchmark
go get github.com/coregx/coregex@v0.12.13
COREGEX_DEBUG=1 go test -bench=. -benchmem your-package

Links:

The most humbling moment? Seeing ANDL CX, AX in our FatTeddy ASM and realizing one wrong instruction had been silently dropping 23,000 matches. The most satisfying? Seeing coregex 1.6x faster than Rust on the IP pattern that started this whole journey.

Built by @kolkov as part of CoreGX — production Go libraries.

Aho-Corasick in Go: Multi-Pattern String Matching at 6 GB/s with Zero Allocations

Andrey Kolkov — Wed, 18 Mar 2026 12:38:29 +0000

When your application needs to find thousands of keywords in a stream of text — think log analysis, content moderation, network intrusion detection, or DNA sequencing — you need an algorithm that doesn't slow down as the number of patterns grows. That algorithm is Aho-Corasick.

We built coregx/ahocorasick, a pure Go implementation that achieves over 6 GB/s on a single core with zero heap allocations on the hot path. No cgo, no assembly, no unsafe — just carefully structured Go code and a deep understanding of how modern CPUs access memory.

This article explains what we built, why, and the techniques that made it fast.

The Problem: O(n × k) Doesn't Scale

Suppose you have 100 keywords to search for in a 1 MB document. The naive approach — call strings.Contains for each keyword — performs 100 scans of the document. That's O(n × k) where n is the document size and k is the number of patterns.

Aho-Corasick solves this in O(n + z) — one pass through the document, regardless of how many patterns you have. Whether you're searching for 10 patterns or 10,000, the scan time is the same.

The algorithm builds a finite automaton from all patterns at once: a trie with failure links that allow the search to continue without backtracking. Every byte of input advances the automaton by exactly one state.

What We Built

coregx/ahocorasick is part of the coregx organization — a collection of high-performance libraries for Go. It serves as the multi-pattern search engine inside coregex, our regex engine, where it accelerates literal alternations like error|warning|fatal|critical.

Key Design Decisions

Pure Go, zero dependencies. The library compiles on every platform Go supports — Linux, Windows, macOS, ARM, WASM — without any build complexity. There's no cgo bridge, no platform-specific assembly files to maintain.

DFA compilation. At build time, the library constructs a noncontiguous NFA (trie + failure links), then compiles it into a fully resolved DFA — a single flat []uint32 array where every state transition is pre-computed. At search time, there are no failure links to follow. One table lookup per byte. Always.

Builder pattern API. The automaton is immutable after construction. You configure it once, build it once, and then search concurrently from any number of goroutines without synchronization.

ac, err := ahocorasick.NewBuilder().
    AddStrings([]string{"error", "warning", "fatal", "critical"}).
    Build()
if err != nil {
    log.Fatal(err)
}

// Safe for concurrent use
if ac.IsMatch(logLine) {
    // handle match
}

Performance: The Numbers

Benchmarks on Intel i7-1255U, single core:

Operation	Input	Throughput	Allocations
`IsMatch` (match found)	64 KB	6.3 GB/s	0
`IsMatch` (no match)	64 KB	6.0 GB/s	0
`Find` (first match)	64 KB	3.5 GB/s	1 (24 B)
`FindAll` (all matches)	77 B	100 MB/s	4 (720 B)

These are median values across multiple benchmark runs. Individual runs may be higher or lower depending on CPU frequency scaling. For context, reading from an NVMe SSD tops out at ~7 GB/s — this library processes data nearly as fast as most storage can deliver it.

How It Works: Three Layers of Optimization

Layer 1: The DFA Transition Table

The classical Aho-Corasick NFA has a problem: when a byte doesn't match any transition from the current state, it follows a chain of failure links back toward the root. In the worst case, this is O(depth) operations per byte.

Our DFA eliminates this entirely. At build time, for every state and every possible byte class, we pre-compute the final destination by following all failure links. The result is stored in a flat array:

next_state = trans[current_state + byte_class]

One addition. One array load. No branches, no link following, no indirection. The state IDs are pre-multiplied by the stride (the row width of the transition table), so the lookup doesn't even need a multiplication — just an addition.

Layer 2: Match Flag in the Transition Table

Each entry in the transition table is a uint32. The lower 31 bits hold the (pre-multiplied) destination state ID. The high bit — bit 31 — is a match flag: if set, the destination state has at least one matching pattern.

This means the hot loop checks for matches with a single AND instruction:

raw := trans[sid + class]
if raw & matchFlag != 0 {
    return true  // match found
}
sid = raw  // no flag → raw IS the clean state ID

The critical insight: when there's no match (the common case for most bytes), raw has bit 31 clear, so it's already a valid state ID. No masking needed. The mask is only applied on the rare match path.

Layer 3: SIMD Prefilter with Skip-Ahead

The DFA processes one byte at a time. But modern CPUs have SIMD instructions that can scan 16–32 bytes in a single operation. Go's bytes.IndexByte uses these instructions internally (SSE2/AVX2 on x86, NEON on ARM).

Before entering the DFA loop, we scan the haystack for any byte that could start a pattern match. If none of the pattern start bytes exist in the haystack, we return immediately — no DFA traversal at all.

More importantly, we re-engage this prefilter during the DFA loop. Whenever the automaton returns to its start state (meaning no pattern prefix is currently being tracked), we call bytes.IndexByte to skip ahead to the next position where a match could begin:

if sid == startState && len(startBytes) > 0 {
    skip := findEarliestStartByte(haystack[i+1:], startBytes)
    if skip < 0 {
        return false  // no more start bytes → no match possible
    }
    i += skip
}

This is the same technique used by BurntSushi's Rust aho-corasick crate, adapted for Go's runtime. It turns the no-match worst case from a full O(n) DFA scan into a handful of SIMD scans.

Real-World Usage

Log Analysis Pipeline

// Build once at startup
patterns := []string{
    "ERROR", "FATAL", "PANIC", "OOM",
    "connection refused", "timeout exceeded",
    "permission denied", "disk full",
}
ac, _ := ahocorasick.NewBuilder().
    AddStrings(patterns).
    Build()

// Process log lines (concurrent-safe)
func processLine(line []byte) {
    if !ac.IsMatch(line) {
        return // fast path: no keywords found
    }
    for _, m := range ac.FindAll(line, -1) {
        alert(patterns[m.PatternID], line)
    }
}

Content Moderation

// Load blocklist from database
blocklist := loadBlocklist() // []string, potentially thousands of terms
ac, _ := ahocorasick.NewBuilder().
    AddStrings(blocklist).
    Build()

func moderate(content []byte) bool {
    return ac.IsMatch(content) // O(n), regardless of blocklist size
}

Regex Engine Prefilter

Inside coregex, when the regex engine encounters a pattern like:

(?i)(error|warning|fatal|critical|info|debug|trace)

It extracts the literal alternation, builds an Aho-Corasick automaton, and uses it as a prefilter. The automaton quickly identifies candidate positions in the text, and the full regex engine only runs at those positions. For large inputs with rare matches, this can be 10–100x faster than running the regex directly.

Part of the coregx Ecosystem

ahocorasick is one component in the coregx organization's text processing toolkit:

ahocorasick — Multi-pattern string matching (this library)
coregex — High-performance regex engine that uses ahocorasick as its literal search backend

The libraries are designed to work together but are independently useful. ahocorasick has zero dependencies and can be used standalone in any Go project.

If you're interested in the regex engine side of things, check out Go's Regexp is Slow. So I Built My Own — up to 3000x Faster, where we describe coregex and how it uses this Aho-Corasick library under the hood.

Getting Started

go get github.com/coregx/ahocorasick

package main

import (
    "fmt"
    "github.com/coregx/ahocorasick"
)

func main() {
    ac, _ := ahocorasick.NewBuilder().
        AddStrings([]string{"quick", "brown", "fox"}).
        Build()

    text := []byte("the quick brown fox jumps over the lazy dog")

    // Zero-allocation existence check
    fmt.Println("Has match:", ac.IsMatch(text)) // true

    // Find all matches
    for _, m := range ac.FindAll(text, -1) {
        fmt.Printf("  %q at [%d:%d]\n", text[m.Start:m.End], m.Start, m.End)
    }
}

Output:

Has match: true
  "quick" at [4:9]
  "brown" at [10:15]
  "fox" at [16:19]

What's Next

Teddy SIMD prefilter — A packed SIMD algorithm (inspired by Hyperscan) for even faster candidate scanning with ≤64 patterns
Contiguous NFA — A memory-efficient alternative to the DFA for very large pattern sets (10,000+ patterns) where the full DFA transition table doesn't fit in L2 cache
Stream search — io.Reader interface for searching in streaming data without loading the entire input into memory

Links:

GitHub: github.com/coregx/ahocorasick
Go Reference: pkg.go.dev/github.com/coregx/ahocorasick
Part of: coregx — High-performance libraries for Go

Licensed under MIT. Contributions welcome.

Go GUI in 2026: gogpu/ui v0.1.0 — 22 Widgets, GPU Rendering, Zero CGO

Andrey Kolkov — Sun, 15 Mar 2026 16:50:20 +0000

Series: Building Go's GPU Ecosystem

GoGPU: A Pure Go Graphics Library — Project announcement

From Idea to 100K Lines in Two Weeks — The journey

Pure Go 2D Graphics with GPU Acceleration — Introducing gg

GPU Compute Shaders in Pure Go — Compute pipelines

Go 1.26 Meets 2026 — Ecosystem overview

Enterprise 2D Graphics Library — gg architecture

Cross-Package GPU Integration — gpucontext

Unified 2D/3D Graphics Integration — gg + gogpu

Core Complete, Focus on GUI — Phase 2 announcement

gogpu/ui v0.1.0 — First Release ← You are here

From "Focus on GUI" to First Release

In the last article, we announced that the core gogpu ecosystem was complete and all our energy was going into building a GUI toolkit. At that point gogpu/ui was at Phase 2 Beta with 55K lines of code, 6 widgets, and one design system.

Today, roughly three weeks later, we are tagging v0.1.0 — the first public release. The toolkit grew from 55K to 150K lines, from 6 to 22 interactive widgets, and from one to three design systems. The entire ecosystem went through a coordinated release — from shader compiler to widget toolkit — to bring everything onto stable, tagged versions.

This is a preview release. The API will change. Performance has not been optimized. There are rough edges. We are releasing now because we want community feedback to shape the API before it solidifies. The work is just beginning, but we believe there is enough here to start a conversation.

What Is gogpu/ui?

gogpu/ui is a GUI toolkit library for Go. You build widget trees, bind reactive state, and the toolkit handles layout, event dispatch, and rendering through gogpu/gg (a 2D graphics engine) onto a GPU surface provided by gogpu/gogpu (an application framework).

We studied 20+ GUI frameworks across multiple ecosystems — Flutter (Dart), Qt (C++), SwiftUI (Swift), Xilem/Floem/GPUI/Iced/Slint (Rust), Angular/SolidJS/React (Web), Fyne/Gio (Go) — and brought their proven patterns into Go:

Pluggable Painter pattern (Flutter's separation of widget behavior from rendering)
Reactive signals (Angular Signals architecture, also inspired by SolidJS and Rust's Leptos)
Functional options for backward-compatible API evolution (Go-native)
W3C Pointer Events for input handling (browser standard)
CSS font-weight matching algorithm (W3C spec) for typography
Screen-space coordinate transforms (Flutter's localToGlobal, Qt's mapToGlobal)

The entire stack — from shader compilation to window management to 2D rendering — is 580,000+ lines of pure Go with zero CGO.

By the numbers (v0.1.0):

Metric	Value
Interactive widgets	22
Design system themes	3 (Material 3, Fluent, Cupertino)
Go source files	350+
Lines of code	~146,000
Test functions	~3,900+
Average test coverage	97%+
CGO required	No

Quick Look: A Minimal Application

Here is a complete runnable application with a Material 3 button:

package main

import (
    "fmt"
    "log"

    "github.com/gogpu/gg"
    _ "github.com/gogpu/gg/gpu"
    "github.com/gogpu/gg/integration/ggcanvas"
    "github.com/gogpu/gogpu"
    "github.com/gogpu/ui/app"
    "github.com/gogpu/ui/core/button"
    "github.com/gogpu/ui/primitives"
    "github.com/gogpu/ui/render"
    "github.com/gogpu/ui/theme/material3"
    "github.com/gogpu/ui/widget"
)

func main() {
    gogpuApp := gogpu.NewApp(gogpu.DefaultConfig().
        WithTitle("My First App").
        WithSize(600, 400).
        WithContinuousRender(false)) // event-driven: 0% CPU when idle

    m3 := material3.New(widget.Hex(0x6750A4)) // seed color

    uiApp := app.New(
        app.WithWindowProvider(gogpuApp),
        app.WithPlatformProvider(gogpuApp),
        app.WithEventSource(gogpuApp.EventSource()),
    )
    uiApp.SetRoot(
        primitives.Box(
            primitives.Text("Hello, gogpu/ui!").FontSize(24).Bold(),
            button.New(
                button.TextOpt("Click Me"),
                button.OnClick(func() { fmt.Println("Clicked!") }),
                button.PainterOpt(material3.ButtonPainter{Theme: m3}),
            ),
        ).Padding(24).Gap(12),
    )

    var canvas *ggcanvas.Canvas
    gogpuApp.OnDraw(func(dc *gogpu.Context) {
        w, h := dc.Width(), dc.Height()
        if canvas == nil {
            var err error
            canvas, err = ggcanvas.New(gogpuApp.GPUContextProvider(), w, h)
            if err != nil {
                log.Fatal(err)
            }
        }
        uiApp.Frame()
        sv := dc.SurfaceView()
        sw, sh := dc.SurfaceSize()
        gg.SetAcceleratorSurfaceTarget(sv, sw, sh)
        canvas.Draw(func(cc *gg.Context) {
            cc.SetRGBA(0.94, 0.94, 0.94, 1)
            cc.DrawRectangle(0, 0, float64(w), float64(h))
            cc.Fill()
            uiApp.Window().DrawTo(render.NewCanvas(cc, w, h))
        })
        _ = canvas.RenderDirect(sv, sw, sh)
    })
    gogpuApp.OnClose(func() { gg.CloseAccelerator() })

    if err := gogpuApp.Run(); err != nil {
        log.Fatal(err)
    }
}

Yes, the boilerplate for wiring up the draw callback is verbose. That is an area we plan to improve. The tradeoff is full control over the render pipeline -- you can mix gg 2D drawing with UI widgets, render to textures, or integrate with your own rendering code.

The Widget Set

v0.1.0 ships 22 interactive widgets and display primitives:

Form controls: Button (4 variants, 3 sizes), Checkbox (tri-state), Radio group, TextField (with selection, clipboard, validation), Dropdown, Slider (continuous/discrete)

Containers: ScrollView (wheel, keyboard, scrollbar drag), TabView (lazy content, closeable tabs), Dialog (modal, focus trapping), Collapsible sections, SplitView (resizable panels)

Data display: ListView (virtualized, 1000+ items), GridView (virtualized 2D grid), DataTable (sortable columns, fixed header), TreeView (hierarchical, expand/collapse), LineChart (real-time, multiple series), ProgressBar, Circular Progress

Application chrome: Toolbar, Menu system (MenuBar + ContextMenu with submenus), Docking system (IDE-style panels)

Primitives: Box (VBox/HBox), Text (reactive via signals), Image, ThemeScope, RepaintBoundary (pixel caching)

Every interactive widget follows the same patterns: functional options for construction, a Painter interface for design-system independence, signal bindings for reactive state, and accessibility metadata (ARIA roles).

Three Design Systems

Widgets do not know how they look. Rendering is delegated to Painter implementations. v0.1.0 ships three:

Material Design 3 -- HCT color science, tonal palettes generated from a single seed color, 21 component painters.

Fluent Design -- Microsoft's design language with accent colors, inner focus rings, 9 painters.

Cupertino -- Apple HIG with iOS-style toggle switches, segmented controls, pill buttons, 9 painters.

Switching is one line:

// Material 3
btn := button.New(
    button.TextOpt("Save"),
    button.PainterOpt(material3.ButtonPainter{Theme: m3}),
)

// Fluent Design
btn := button.New(
    button.TextOpt("Save"),
    button.PainterOpt(fluent.ButtonPainter{Theme: fl}),
)

// Cupertino
btn := button.New(
    button.TextOpt("Save"),
    button.PainterOpt(cupertino.ButtonPainter{Theme: cu}),
)

The gallery example demonstrates live M3 seed color switching at runtime (Purple, Blue, Green, Orange). Fluent and Cupertino painters are implemented and tested but not yet wired into the gallery demo — switching between design systems at runtime is architecturally supported (just swap the Painter), but a full gallery with all three is a v0.2.0 goal.

Reactive Signals

State management uses a signals pattern built on our own coregx/signals library. The architecture is directly inspired by Angular Signals (fine-grained reactivity with Signal[T], Computed[T], Effect), with influence from SolidJS and Rust's Leptos. We studied Angular's signal lifecycle, dependency tracking, and lazy evaluation — then reimplemented it idiomatically in Go with generics. A Signal[T] holds a value. A Computed[T] derives from other signals and recomputes lazily. When a signal changes, bound widgets automatically invalidate and redraw.

count := state.NewSignal(0)

// Computed label updates automatically
label := primitives.TextFn(func() string {
    return fmt.Sprintf("Clicked %d times", count.Get())
})

btn := button.New(
    button.TextOpt("Increment"),
    button.OnClick(func() { count.Set(count.Get() + 1) }),
)

Widgets support two-way signal bindings. The slider reads from and writes to the same signal:

volume := state.NewSignal[float32](50)
s := slider.New(
    slider.Min(0), slider.Max(100),
    slider.ValueSignal(volume), // two-way binding
)
// volume.Get() always reflects the current slider position

Signal lifecycle is automatic: widgets subscribe on mount and clean up on unmount. No manual disposal needed.

Architecture Highlights

Pluggable Painter pattern. Widget behavior (in core/) is separated from rendering (in theme/). A Button knows about click handling, focus states, and size variants. A ButtonPainter knows how to draw rounded corners and color fills. This avoids import cycles and lets third parties create entirely new design systems.

Functional options. All widget constructors use the options pattern for backward-compatible API evolution:

btn := button.New(
    button.TextOpt("Submit"),
    button.VariantOpt(button.Filled),
    button.SizeOpt(button.Large),
    button.OnClick(handleSubmit),
)

Adding new options in future versions will not break existing code.

Content[C] polymorphic pattern. Inspired by Taiga UI's Polymorpheus pattern (Angular), complex widgets like ListView, GridView, and TabView use a generic Content[C] interface from the CDK (Component Development Kit) package. This enables type-safe polymorphic content rendering — the widget provides the context (item index, selection state, hover), the user provides the builder function. Internally it powers cell recycling and virtualization, while externally users see a simple BuildItem(func(index int) widget.Widget) callback.

Retained-mode rendering. The widget tree tracks dirty state. Only changed widgets are redrawn. RepaintBoundary widgets cache their subtree as pixel buffers. Large boundaries (128x128+) automatically use tile-parallel rendering via scene.Scene with goroutine work-stealing.

Event-driven rendering. The default mode is 0% CPU when idle. The window only redraws when events arrive or signals change. No continuous render loop burning battery.

Accessibility from day one. Every widget implements the a11y.Accessible interface with ARIA roles, labels, and actions. The accessibility tree uses stable uint64 node IDs. Platform adapters (UIA, AT-SPI2, NSAccessibility) are not implemented yet -- that is one of the biggest remaining gaps.

What Works Well

After months of development, these areas feel solid:

TextField handles Unicode input correctly (Latin, Cyrillic, CJK), with cursor movement, text selection, clipboard (Ctrl+C/V/X/A), and input validation.
Tab focus navigation works across the widget tree with Tab/Shift+Tab. Focus rings render correctly.
Hover cursors change appropriately (pointer for buttons, text beam for text fields, resize handles for SplitView).
ScrollView dispatches events with correct coordinate transforms to child widgets, even when scrolled.
Live theme color switching in the gallery demo (M3 seed color changes all widget colors instantly).
Virtualized lists handle thousands of items with only visible rows rendered and recycled.
Signal bindings propagate state changes through the widget tree without manual wiring.

What Needs Work (Honest Assessment)

This is a v0.1.0 preview. Here is what we know needs improvement:

Performance. Complex widget trees (the full gallery) can feel sluggish. We have not done an optimization pass yet. Retained-mode rendering infrastructure is in place but not fully leveraged.
Accessibility adapters. The a11y tree and ARIA roles are defined, but there are no platform adapters connecting to screen readers. This is a significant gap for production use.
HiDPI. DPI scaling is wired through the stack but has not been thoroughly tested on all platforms.
Documentation. API docs exist but guides and tutorials are sparse. The architecture document is 1200+ lines but aimed at contributors, not users.
Draw callback boilerplate. The current setup code for wiring gogpu + gg + ui is too verbose. We plan to provide higher-level convenience functions.
Some event edge cases. Drag cursors, scroll momentum, and overlay dismiss behavior have known rough spots.
Platform testing. CI runs on Ubuntu, macOS, and Windows, but real-world testing has been primarily on Windows.

How to Try It

# Clone and run the gallery example
git clone https://github.com/gogpu/ui.git
cd ui/examples/gallery
go run .

Or add it to an existing project:

go get github.com/gogpu/ui@v0.1.0
go get github.com/gogpu/gogpu@latest
go get github.com/gogpu/gg@latest

The examples/ directory has four working applications:

Example	What it shows
`examples/hello/`	Checkboxes, radio buttons, ListView with 1000 items
`examples/signals/`	Reactive state management patterns
`examples/taskmanager/`	Real-time charts, progress bars, simulated system metrics
`examples/gallery/`	All 22 widgets, M3 theme with live seed color switching

Requirements: Go 1.25+, a GPU (Vulkan, Metal, DX12, or OpenGL ES -- software fallback available). No C compiler needed.

The gogpu Ecosystem

gogpu/ui sits at the top of a pure Go graphics stack:

naga       -- shader compiler (WGSL to SPIR-V, MSL, GLSL)
wgpu       -- WebGPU Hardware Abstraction Layer (Vulkan, Metal, DX12, GLES, software)
gogpu      -- application framework (windowing, input, GPU context)
gg         -- 2D graphics engine (Canvas API, GPU text rendering, SDF acceleration)
ui         -- GUI toolkit (this project)

The entire stack is ~300K lines of pure Go. No CGO, no Rust FFI, no C bindings. If Go can build for a platform, the full stack runs there.

This release coincides with a coordinated cascade release across the entire ecosystem. All libraries were updated to work through wgpu's new public Core API (previously HAL-only):

Library	Version	What Changed
naga	v0.14.7	Shader compiler stability fixes
wgpu	v0.21.0	New public API: Instance, Adapter, Device, Queue, Surface, CommandEncoder
gpucontext	v0.10.0	Updated interfaces for new wgpu API
gogpu	v0.24.1	Platform refactor, CharCallback for Unicode text input
gg	v0.37.0	Migrated internal/gpu from HAL to wgpu public API, GPU RRect SDF clip
ui	v0.1.0	This release

This was a significant engineering effort — wgpu moved from internal HAL types to a proper public API with validation, state tracking, and resource lifecycle management. Every layer above had to adapt.

We Want Your Feedback

This release exists to start a conversation. We would genuinely appreciate input on:

What widgets are missing for your use case?
API ergonomics -- do functional options feel right for Go? Is the signal system intuitive?
Performance expectations -- what is acceptable for the apps you want to build?
Design system coverage -- are M3/Fluent/Cupertino the right targets? Missing painters?
Documentation -- what would help you get started?

The Big Architecture Question: Monolith or Modular?

There is one question we have been debating internally and would especially value community input on:

Should gogpu/ui stay as a single module, or should we extract shared primitives into a separate foundation?

Right now, go get github.com/gogpu/ui pulls the entire toolkit — 56 packages, all widgets, all three design systems, all dependencies. If you only need geometry.Rect or the layout engine or the signal system, you still get everything.

We are considering extracting foundational packages into a separate gogpu/uikit (or similar) module:

What	Currently in `ui/`	Could live in `uikit/`
Geometry types	`ui/geometry`	`uikit/geometry`
Layout engines	`ui/layout`	`uikit/layout`
Event types	`ui/event`	`uikit/event`
Widget base	`ui/widget`	`uikit/widget`
Signal bindings	`ui/state`	`uikit/state`
Theme interfaces	`ui/theme`	`uikit/theme`

This would let the community:

Build custom widget libraries on top of shared primitives without importing all of gogpu/ui
Create their own design systems (themes + painters) by depending only on the interfaces
Extend our themes with custom component tokens without forking
Use our layout engine (Flex, Grid, Stack) independently in their own UI frameworks

The tradeoff: another module to version and maintain, another API boundary to keep stable.

What do you think? Is a modular foundation important for your use case, or is a single go get simpler? We are genuinely unsure — the Go ecosystem has examples of both approaches working well. Your input will directly shape the v0.2.0 architecture.

File issues on GitHub, start a thread in Discussions, or just leave a comment here.

goffi: Zero-CGO Foreign Function Interface for Go — How We Call C Libraries Without a C Compiler

Andrey Kolkov — Mon, 02 Mar 2026 09:10:35 +0000

Every Go developer who has worked with C libraries knows the pain: CGO requires a C compiler, breaks cross-compilation, bloats binaries, and adds ~200ns overhead per call. For our WebGPU bindings and ML framework, calling wgpu-native through CGO was a non-starter — we needed to ship a single static binary across Windows, Linux, and macOS without requiring users to install gcc.

So we built goffi — a pure Go FFI library that calls C functions through hand-written assembly, with zero C dependencies and zero per-call allocations. It now powers an entire ecosystem: go-webgpu/webgpu bindings, born-ml/born ML framework, and the GoGPU GPU computing platform with dual Rust and pure Go backends.

This article explains the architecture, the hard problems we solved, how goffi compares to purego, and how you can use it in your own projects.

The Problem

Our stack looks like this:

Go application (gogpu)
  └─ wgpu bindings (gogpu/wgpu)     ← needs to call C functions
       └─ goffi                      ← this library
            └─ wgpu-native (.dll/.so/.dylib)

We need to call hundreds of WebGPU functions from Go: create GPU devices, submit command buffers, handle async callbacks from Metal/Vulkan threads. The requirements were clear:

No C compiler at build time — users run go get and it works
Cross-compilation — GOOS=linux GOARCH=arm64 go build must work from Windows
Callbacks from C threads — wgpu-native fires callbacks from internal GPU threads
Struct passing — WebGPU API passes structs by value (descriptors, extents, colors)
Low overhead — GPU command encoding happens at 60+ FPS

CGO fails requirements 1 and 2. purego covers 1-2 but had gaps in 3-5 when we started. So we built goffi.

Architecture: 4 Layers Deep

Every goffi call traverses four layers to safely transition from Go's managed runtime to raw C code:

Go Code
  │  ffi.CallFunction()
  ▼
runtime.cgocall          ← Go runtime: switch to system stack, tell GC
  │
  ▼
Assembly Wrapper         ← Our code: load registers per ABI
  │  RDI=arg0 RSI=arg1 ... XMM0=float0 ...
  ▼
C Function               ← Target library

Layer 1: The Call Interface (CIF)

Unlike purego which uses reflect.MakeFunc on every call, goffi pre-computes everything once:

// Prepare once at init time
cif := &types.CallInterface{}
ffi.PrepareCallInterface(cif, types.DefaultCall,
types.UInt64TypeDescriptor,                            // return: size_t
[]*types.TypeDescriptor{types.PointerTypeDescriptor},  // arg: const char*
)

// Call many times — zero reflection, zero allocation
// args = []unsafe.Pointer{unsafe.Pointer(&myPtr)} — pointers TO arg values
ffi.CallFunction(cif, strlenPtr, unsafe.Pointer(&result), args)

PrepareCallInterface classifies each argument (integer register? SSE register? stack?), computes stack layout, and stores everything in a reusable CallInterface struct. The cif.Flags bitmask tells the assembly exactly what to do — no decisions at call time.

Layer 2: Platform Assembly

We write assembly by hand for each ABI. Here's the core of our System V AMD64 implementation (syscall_unix_amd64.s). The function receives a pointer to a syscallArgs struct in DI, loads registers from it, calls the target, and writes return values back:

// syscall_unix_amd64.s — System V AMD64 ABI
TEXT syscallN(SB), NOSPLIT|NOFRAME, $0
    PUSHQ BP
    MOVQ  SP, BP
    SUBQ  $STACK_SIZE, SP
    MOVQ  DI, R11             // R11 = args struct pointer

    // Load 8 SSE registers from struct offsets 128-184
    MOVQ 128(R11), X0         // XMM0
    MOVQ 136(R11), X1         // XMM1
    // ... XMM2-XMM7

    // Push stack-spill args (a7-a15) from struct offsets 56-120
    MOVQ 56(R11), R12
    MOVQ R12, 0(SP)           // stack slot 0

    // Load 6 GP registers from struct offsets 8-48
    MOVQ 8(R11), DI           // RDI = arg 1
    MOVQ 16(R11), SI          // RSI = arg 2
    MOVQ 24(R11), DX          // RDX = arg 3
    MOVQ 32(R11), CX          // RCX = arg 4
    MOVQ 40(R11), R8          // R8  = arg 5
    MOVQ 48(R11), R9          // R9  = arg 6

    MOVQ 0(R11), R10          // function pointer
    CALL R10

    // Save returns: RAX → r1, RDX → r2, XMM0 → f1
    MOVQ PTR_ADDRESS(BP), DI
    MOVQ AX, 192(DI)          // integer return
    MOVQ DX, 200(DI)          // second return (9-16B structs)
    MOVQ X0, 128(DI)          // float return
    // ... restore stack, RET

We maintain separate assembly for three ABIs:

ABI	GP Registers	SSE Registers	Stack
System V AMD64 (Linux/macOS)	RDI, RSI, RDX, RCX, R8, R9	XMM0-XMM7	16-byte aligned
Win64 (Windows)	RCX, RDX, R8, R9	XMM0-XMM3	32-byte shadow space
AAPCS64 (ARM64)	X0-X7	D0-D7	16-byte aligned

Layer 3: Struct Returns

This is where it gets interesting. When a C function returns a struct, the ABI rules depend on size:

<= 8 bytes: returned in RAX
9-16 bytes: split across RAX (low 8) + RDX (high 8)
> 16 bytes: caller passes a hidden pointer as the first argument (sret)

Our handleReturn function assembles the result:

case types.StructType:
size := cif.ReturnType.Size
switch {
case size <= 8:
*(*uint64)(rvalue) = retVal
case size <= 16:
*(*uint64)(rvalue) = retVal          // RAX → bytes 0-7
remaining := size - 8
src := (*[8]byte)(unsafe.Pointer(&retVal2))
dst := (*[8]byte)(unsafe.Add(rvalue, 8))
copy(dst[:remaining], src[:remaining]) // RDX → bytes 8-15
}

Layer 4: Callbacks (C → Go)

WebGPU fires async callbacks from internal threads — Metal threads, Vulkan threads, threads goffi never created. These threads have no goroutine (G = nil), so calling Go code directly would crash.

We solve this with Go's crosscall2 mechanism:

C thread (wgpu-native internal)
  │  calls our trampoline (1 of 2000 pre-compiled entries)
  ▼
Assembly dispatcher
  │  saves registers, loads callback index
  ▼
crosscall2 → runtime.load_g → runtime.cgocallback
  │  sets up goroutine, switches to Go stack
  ▼
Your Go callback function

On AMD64, each trampoline is a 5-byte CALL instruction. On ARM64, each entry is 8 bytes — two 4-byte instructions:

// ARM64 (callback_arm64.s) — 8 bytes per entry
MOVD $0, R12              // load callback index
B    ·callbackDispatcher  // branch (no link — preserves LR)
MOVD $1, R12
B    ·callbackDispatcher
// ... 2000 entries

Usage is simple:

cb := ffi.NewCallback(func(status uint32, adapter uintptr, msg uintptr, ud uintptr) {
// This runs safely even when called from a C thread
result.adapter = adapter
close(result.done)
})
ffi.CallFunction(cif, wgpuRequestAdapter, nil, args)

goffi vs purego: Honest Comparison

Both libraries are pure Go, no CGO. But they make different trade-offs:

Aspect	goffi	purego
API model	libffi-style: prepare CIF once, call many times	reflect-style: `RegisterFunc`, closure per call
Per-call cost	Zero allocations (CIF reused)	`sync.Pool.Get()` for syscall args
Callback float returns	Supported (asm writes XMM0)	`panic("unsupported return type")`
ARM64 HFA	Recursive struct walk (nested HFAs)	Top-level fields only
Type system	Explicit `TypeDescriptor` (Size/Alignment/Kind)	Go `reflect.Type` introspection
Ergonomics	Raw — you manage `unsafe.Pointer` yourself	High-level — auto string null-termination, bool, slice
Platforms	5 (amd64x3 + arm64x2)	9+ architectures
Context support	`CallFunctionContext(ctx, ...)`	None
Typed errors	5 error types with `errors.As()`	Generic errors

Choose goffi when: you need struct passing, zero per-call overhead, callback float returns, or you're building GPU/real-time bindings where every nanosecond counts.

Choose purego when: you need string auto-marshaling, broad architecture support (386, ppc64le, riscv64...), or quick one-off C library bindings with minimal boilerplate.

We use both in gogpu — goffi for the hot-path WebGPU calls, purego patterns as reference for platform edge cases.

The Ecosystem: Where goffi Came From and Where It Led

goffi wasn't built in isolation. It was born from a real need — and it enabled an entire ecosystem of pure Go GPU libraries.

The Origin: Proprietary Roots

goffi started as an internal tool. For over a year it lived inside a proprietary codebase — a GPU computing stack we built for our own projects. It worked well enough for us: a handful of platforms, a known set of functions, predictable usage patterns.

In 2025, we decided to open-source everything. Not just goffi, but the entire ecosystem — WebGPU bindings, the ML framework, the shader compiler, the GPU platform. We believed the Go community needed a real alternative to CGO for native library bindings.

What we didn't expect: the gap between "works for us internally" and "production-ready open source" was enormous.

Our internal version handled our specific use cases. Open source means every use case. Users on platforms we never tested. Struct layouts we never considered. Calling conventions with edge cases we'd never hit. The list of things that "just worked" internally but broke in the wild was humbling:

ABI compliance — our AMD64 assembly didn't handle struct returns >8 bytes correctly. Internally we never returned large structs by value. Open source users did, immediately. We had to implement RAX+RDX split returns and sret hidden pointers.
ARM64 — we had AMD64 only. Open source meant Apple Silicon support was day one priority, not a nice-to-have.
Callbacks from C threads — internally we controlled which threads called back into Go. In the wild, wgpu-native fires callbacks from Metal and Vulkan threads we never created. We had to integrate crosscall2 for proper C→Go transitions.
Error handling — our internal code used generic errors. Open source users needed errors.As() with typed errors to build robust applications. We added 5 error types.
Testing — our internal coverage was ~40%. Getting to 89% meant writing hundreds of test cases for edge cases we'd never encountered ourselves.
Documentation — internally, we knew how the code worked. For open source, every assembly file needed comments explaining the ABI, every public function needed godoc, every platform quirk needed documentation.

We essentially rebuilt goffi from scratch while keeping the core idea intact. The architecture is the same — CIF pre-computation, assembly dispatch, zero allocations — but the implementation is production-grade now, not prototype-grade.

go-webgpu/webgpu

It started with go-webgpu/webgpu — our zero-CGO WebGPU bindings for Go. We wanted to call wgpu-native (Rust-based Vulkan/Metal/DX12 backend) from Go without requiring a C compiler. Every existing approach had a deal-breaker:

CGO: requires gcc, breaks go get, no cross-compilation
purego: at the time, no struct passing, no callback float returns, no HFA support — things WebGPU needs

So we built goffi as the FFI layer for go-webgpu/webgpu. The bindings wrap 180+ wgpu-native functions — device creation, buffer allocation, render passes, compute dispatches, async adapter requests.

born-ml: Machine Learning on GPU

The second consumer was born-ml/born — a production-ready ML framework for Go with a PyTorch-like API. born needs GPU compute for tensor operations: matrix multiplication, convolution, automatic differentiation. The WebGPU compute pipeline powered by goffi gives born GPU acceleration while shipping as a single static binary.

born (ML framework)
  └─ go-webgpu/webgpu (WebGPU bindings)
       └─ goffi (FFI layer)
            └─ wgpu-native (Vulkan/Metal/DX12)

This stack lets you go get github.com/born-ml/born, write a neural network, and run it on GPU — no Python, no CUDA, no C compiler.

GoGPU: The Full Ecosystem

As the projects matured, we realized we could go further. GoGPU grew into a complete GPU computing ecosystem with dual backends — a high-performance Rust backend (wgpu-native via goffi) and a pure Go backend:

Package	What it does	Uses goffi
gogpu/gogpu	GPU framework — windowing, input, event loop, dual backends (Rust wgpu-native or Pure Go)	Yes
gogpu/wgpu	WebGPU implementation in pure Go — calls Vulkan, Metal, EGL/GLES natively via goffi	Yes
gogpu/naga	Shader compiler in pure Go — WGSL to SPIR-V, MSL, GLSL, HLSL	No
gogpu/gg	2D graphics library — SDF rendering, MSDF text, Vello compute pipeline	Indirect
gogpu/gpucontext	Shared interfaces for GPU context, windowing, and surface creation	No

Both gogpu/gogpu and gogpu/wgpu depend directly on goffi. The "pure Go" backend (gogpu/wgpu) is pure Go in the sense of zero CGO — no C compiler needed — but it still calls native Vulkan, Metal, and EGL APIs through goffi. That's the whole point: goffi replaces CGO, not the native graphics drivers.

Real-World Performance

At 60 FPS, a typical frame makes ~30-50 FFI calls through goffi:

Frame budget:            16.6 ms
GPU work:                ~15 ms
FFI overhead (50 calls): 50 × 100ns = 5 us = 0.03%

The FFI overhead is literally unmeasurable in profiling.

Callback-Heavy Async APIs

WebGPU is heavily async. Device creation, adapter requests, buffer mapping — all callback-based:

// Request GPU adapter (async) — simplified pattern
cb := ffi.NewCallback(func(status uint32, adapter uintptr, msg uintptr, ud uintptr) {
result.status = status
result.handle = adapter
result.done <- struct{}{}
})

ffi.CallFunction(&requestAdapterCIF, wgpuInstanceRequestAdapter, nil,
[]unsafe.Pointer{
unsafe.Pointer(&instance),
unsafe.Pointer(&options),
unsafe.Pointer(&cb),
unsafe.Pointer(&userdata),
})

<-result.done // Wait for GPU driver callback

This works even when wgpu-native fires the callback from an internal Metal/Vulkan thread, thanks to our crosscall2 integration.

How to Use goffi in Your Project

Installation

go get github.com/go-webgpu/goffi

Minimal Example: Calling strlen

package main

import (
    "fmt"
    "runtime"
    "unsafe"

    "github.com/go-webgpu/goffi/ffi"
    "github.com/go-webgpu/goffi/types"
)

func main() {
    // 1. Load library
    libName := "libc.so.6"
    if runtime.GOOS == "windows" {
        libName = "msvcrt.dll"
    }
    handle, _ := ffi.LoadLibrary(libName)
    defer ffi.FreeLibrary(handle)

    strlen, _ := ffi.GetSymbol(handle, "strlen")

    // 2. Prepare call interface (once)
    cif := &types.CallInterface{}
    ffi.PrepareCallInterface(cif, types.DefaultCall,
        types.UInt64TypeDescriptor,
        []*types.TypeDescriptor{types.PointerTypeDescriptor},
    )

    // 3. Call (many times, zero overhead)
    str := "Hello, goffi!\x00"
    strPtr := uintptr(unsafe.Pointer(unsafe.StringData(str)))
    var length uint64

    ffi.CallFunction(cif, strlen, unsafe.Pointer(&length),
        []unsafe.Pointer{unsafe.Pointer(&strPtr)})
    fmt.Printf("strlen = %d\n", length) // 13
}

Passing Structs

// Define struct layout matching C struct
pointType := &types.TypeDescriptor{
Size:      16,               // sizeof(Point)
Alignment: 8,                // alignof(Point)
Kind:      types.StructType,
Members: []*types.TypeDescriptor{
types.DoubleTypeDescriptor, // x
types.DoubleTypeDescriptor, // y
},
}

// Use in CIF
ffi.PrepareCallInterface(cif, types.DefaultCall,
types.DoubleTypeDescriptor,  // returns double (distance)
[]*types.TypeDescriptor{pointType, pointType}, // two Point args
)

Registering Callbacks

cb := ffi.NewCallback(func(eventType uint32, data uintptr) {
fmt.Printf("Event %d received\n", eventType)
})

// Pass cb (uintptr) to C function expecting a function pointer
ffi.CallFunction(&cif, registerCallback, nil,
[]unsafe.Pointer{unsafe.Pointer(&cb)})

The Hard Lessons

Building a production FFI taught us things no documentation covers:

1. Stack alignment kills silently. A single byte of misalignment on AMD64 causes SIGSEGV — but only sometimes, depending on whether the callee uses SSE instructions. We spent days debugging crashes that only reproduced under specific GPU driver versions.

2. Windows shadow space is non-negotiable. Win64 ABI requires 32 bytes of "shadow space" on every call, even if the function takes zero arguments. Miss it and the callee corrupts your stack.

3. ARM64 HFA rules are recursive. A struct containing a struct containing 4 floats is still an HFA (Homogeneous Floating-point Aggregate) and must be passed in D0-D3. purego only checks top-level fields; we had to walk the full type tree.

4. C threads have no goroutine. When wgpu-native calls your callback from an internal Metal thread, getg() returns nil. You must go through crosscall2 → load_g → cgocallback or the runtime panics.

5. float32 encoding matters. On Windows, syscall.SyscallN passes args as uintptr. Widening float32 to float64 then stuffing into a register corrupts the bit pattern — you need math.Float32bits to preserve the exact IEEE-754 representation.

Numbers

Metric	Value
FFI overhead	88-114 ns/op
Test coverage	89%
Platforms	5 (Win/Linux/macOS x AMD64 + Linux/macOS x ARM64)
Assembly files	17 files, ~900 lines of logic + 6200 lines of trampoline entries
Callback slots	2000 per process
Dependencies	0 (only Go stdlib)
CGO required	No

What About Go 1.26 CGO Improvements?

Go 1.26 (released February 2026) reduced cgo call overhead by ~30% by removing the dedicated syscall P state. Benchmarks on Apple M1 show CgoCall is 33% faster, CgoCallWithCallback is 21% faster.

This is great news — but it doesn't change our calculus:

CGO still requires a C compiler at build time. Our users go get and ship.
Cross-compilation with CGO still requires cross-toolchains. GOOS=linux GOARCH=arm64 go build just works with goffi.
Static binaries — CGO often pulls in libc. goffi produces fully static Go binaries.
Go 1.26 also benefits goffi — our runtime.cgocall path gets the same 30% speedup, because goffi uses the same runtime machinery internally.

The gap between CGO and pure-Go FFI is narrowing from both directions. We welcome it.

What's Next

v0.5.0 is focused on usability:

Variadic function support (printf, sprintf)
Builder pattern API for less boilerplate
Platform-specific struct alignment (Windows #pragma pack)

v1.0.0 targets API stability with SemVer guarantees, security audit, and published benchmarks vs CGO/purego.

The long-term goal: make GPU programming in Go as natural as it is in Rust or C++, with the ergonomics Go developers expect — go get, go build, done.

Acknowledgments

goffi wouldn't exist without purego.

When we first faced the CGO problem, the conventional wisdom was simple: "you can't call C from Go without a C compiler." purego proved that wrong. The ebitengine team — and specifically @AJ and @TotallyGamerJet — demonstrated that runtime.cgocall, cgo_import_dynamic, and hand-written assembly could replace CGO entirely. They showed the community that pure Go FFI was not just theoretically possible, but practical enough to ship a production game engine.

We studied purego's source code extensively. The crosscall2 callback mechanism, the fakecgo approach, the assembly trampoline pattern — purego pioneered all of these in the Go ecosystem. Without that foundation to learn from, goffi would have taken years longer to build, if we'd attempted it at all.

goffi took a different path — libffi-style CIF pre-computation instead of reflect-based dispatch, explicit type descriptors instead of Go type introspection, struct passing and callback float returns for GPU workloads — but the path only existed because purego cleared it first.

To the purego maintainers: thank you for proving it was possible. The entire pure-Go FFI ecosystem stands on your work.

goffi is MIT-licensed and open to contributions. If you're building Go bindings for C libraries and want zero-CGO with full ABI compliance — give it a try and let us know how it goes.

Porting Vello's GPU Tile Rasterizer to Pure Go

Andrey Kolkov — Sat, 28 Feb 2026 00:46:44 +0000

When you call dc.DrawCircle(400, 300, 100) in gogpu/gg, what happens under the hood? A tile-based rasterization pipeline — a direct port of Vello's GPU compute pipeline from the linebender team — converts your vector paths into per-pixel coverage values. It runs on both CPU and GPU, and it's written entirely in Pure Go.

This article walks through the internals of tilecompute — a 6,700-line dual-execution port of Vello's original GPU compute rasterizer (circa 2020–2023) into Pure Go, with a CPU reference implementation and GPU compute dispatch via 9 WGSL shaders.

Why Not Just Use Scanline?

Traditional scanline rasterizers process one row of pixels at a time. They work, but they have a fundamental scalability problem: for a 4K canvas (3840x2160), you're iterating over 8.3 million pixels regardless of how simple your shapes are.

Tile-based rasterizers flip this around. They divide the canvas into small tiles (16x16 pixels in our case) and only process tiles that the vector path actually touches. A circle in the corner of a 4K canvas? You process maybe 40 tiles instead of 8 million pixels.

Vello — created by Raph Levien and the linebender team — pioneered this approach using GPU compute shaders (originally as piet-gpu in 2020, renamed to Vello in 2022). We ported its GPU compute pipeline to Pure Go for use as the rasterization core of gogpu/gg.

Note: This article covers the original GPU compute pipeline (16x16 tiles, 2020–2023). We've also ported Vello's newer Sparse Strips algorithm (4x4 tiles, August 2024) — see the Two Rasterizers, Two Targets section below.

The GPU Compute Pipeline

Vello's original rasterizer (2020–2023) uses a tile-based GPU compute approach with 16x16 pixel tiles. The key insight: instead of asking "which pixels does this path cover?", ask "which tiles does each line segment cross, and what's the winding contribution?"

The full pipeline has 9 GPU compute stages (matching our 9 WGSL shaders), plus scene encoding and curve flattening on the CPU:

Vector Paths (cubics, arcs, lines)
    ↓
Scene Encoding (CPU — pack paths, transforms, styles)
    ↓
 1. PathTag Reduce    ─┐
 2. PathTag Scan      ─┘ monoid prefix sums over path structure
    ↓
Flatten (Euler spiral → line segments)
    ↓
 3. Draw Reduce       ─┐
 4. Draw Leaf Scan    ─┘ monoid prefix sums over draw commands
    ↓
 5. Path Count        (DDA walk — which tiles does each segment cross?)
    ↓
 6. Backdrop          (prefix sum — left-to-right winding accumulation)
    ↓
 7. Coarse            (generate Per-Tile Command Lists)
    ↓
 8. Path Tiling       (clip segments to tile boundaries, compute yEdge)
    ↓
 9. Fine              (per-pixel analytic anti-aliased coverage)
    ↓
Per-pixel RGBA output

The first four stages use monoid prefix sums — Vello's core parallelism primitive. A monoid is an associative operation with an identity element; prefix sums over monoids can be computed in O(log n) parallel steps on a GPU, turning what would be sequential parsing into massively parallel work.

Let's walk through the key stages.

Stages 1–4: Monoid Prefix Sums

The first four stages parse the encoded scene in parallel using monoid prefix sums. Each path tag and draw tag is reduced into a monoid (an associative structure), then scanned to produce cumulative values:

// PathMonoid — accumulated state from scanning path tags
type PathMonoid struct {
TransIx       uint32 // Transform index
PathSegIx     uint32 // Path segment index
PathSegOffset uint32 // Offset into path segment data
StyleIx       uint32 // Style index
PathIx        uint32 // Path index
}

// DrawMonoid — accumulated state from scanning draw tags
type DrawMonoid struct {
PathIx      uint32 // Which path this draw belongs to
ClipIx      uint32 // Clip stack depth
SceneOffset uint32 // Offset into scene data
InfoOffset  uint32 // Offset into info buffer
}

On the GPU, reduce + scan runs in O(log n) parallel steps via our 9 WGSL compute shaders dispatched through VelloComputeDispatcher. On the CPU, it's a sequential scan — the data structures are identical, making the CPU code a reference implementation that validates GPU correctness.

Stage 5: Path Count — DDA Tile Walk

The path count stage answers: "which tiles does each line segment cross?"

We use a Digital Differential Analyzer (DDA) — an algorithm that traces a line through a grid, visiting every cell the line passes through. For each tile visited, we record two things:

Segment count — how many line segments cross this tile
Backdrop — the signed winding contribution at the tile's left edge

// pathCountMain — DDA walk through the tile grid
func pathCountMain(bump *BumpAllocators, lines []LineSoup,
paths []Path, tile []Tile, segCounts []SegmentCount) {

for lineIx := uint32(0); lineIx < bump.Lines; lineIx++ {
line := lines[lineIx]
p0 := vec2FromArray(line.P0)
p1 := vec2FromArray(line.P1)

// Sort by Y for consistent DDA walking
isDown := p1.y >= p0.y
var xy0, xy1 vec2
if isDown {
xy0, xy1 = p0, p1
} else {
xy0, xy1 = p1, p0
}

// Scale to tile coordinates (pixel / 16)
s0 := xy0.mul(tileScale)
s1 := xy1.mul(tileScale)

// DDA walk: trace the line through tile grid cells
// counting X crossings and Y crossings separately
dx := abs32(s1.x - s0.x)
dy := s1.y - s0.y
idxdy := 1.0 / (dx + dy)
a := dx * idxdy

// ... walk through tiles, update backdrop and segment counts
}
}

The backdrop is the critical concept. When a line segment crosses a tile's left edge, it contributes a signed delta to the winding number: -1 for downward segments, +1 for upward. This is how we know whether a pixel is "inside" or "outside" the path without checking every segment.

Stage 6: Backdrop Prefix Sum

This is where tile-based rasterization really shines. Instead of checking every segment for every pixel, we accumulate winding numbers left-to-right across each row of tiles:

// Backdrop prefix sum — left-to-right winding accumulation
for y := 0; y < bboxH; y++ {
sum := int32(0)
for x := 0; x < bboxW; x++ {
idx := base + y*bboxW + x
sum += tiles[idx].Backdrop
tiles[idx].Backdrop = sum
}
}

After this step, each tile knows the accumulated winding number from all segments to its left. A tile with winding number 1 and no segments crossing it is fully solid — no per-pixel computation needed.

Stage 7: Coarse — Allocation + PTCL Generation

The coarse stage allocates space in a global segment buffer and generates Per-Tile Command Lists. Segment counts are converted into indices using Vello's inverted index trick:

// Convert counts to indices using bitwise NOT
nextSegIx := uint32(0)
for i := range tiles {
nSegs := tiles[i].SegmentCountOrIx
if nSegs != 0 {
tiles[i].SegmentCountOrIx = ^nextSegIx // !seg_ix in Rust
nextSegIx += nSegs
}
}

The ^ (bitwise NOT) serves double duty: it marks the tile as "has segments" (the NOT of a valid index is always negative as int32) while encoding the starting index into the global segment array.

Stage 8: Path Tiling

Now we clip each line segment to its tile boundaries and compute the crucial yEdge value:

// PathSegment — a line segment clipped to tile boundaries
type PathSegment struct {
Point0 [2]float32 // Tile-relative start point
Point1 [2]float32 // Tile-relative end point
YEdge  float32    // Y where segment crosses tile left edge (x=0)
}

YEdge tells the fine rasterizer where the segment enters or exits the tile at x=0. If the segment doesn't cross the left edge, YEdge is set to 1e9 (sentinel value). This single float32 captures the geometric relationship needed for coverage computation.

Stage 9: Fine Rasterization

The final stage computes per-pixel anti-aliased coverage within each 16x16 tile:

// fillPath computes per-pixel coverage for a single tile.
// Direct port of fill_path from vello_shaders/src/cpu/fine.rs.
func fillPath(area []float32, segments []PathSegment,
backdrop int32, evenOdd bool) {

// Initialize area with backdrop winding number
for i := range area {
area[i] = float32(backdrop)
}

for _, seg := range segments {
// For each column in the tile, compute the area
// contribution of this segment using analytic integration
// ...
}

// Apply fill rule and convert to alpha [0, 1]
if evenOdd {
for i := range area {
area[i] = abs32(area[i] - 2.0*round32(0.5*area[i]))
}
} else {
for i := range area {
area[i] = min32(abs32(area[i]), 1.0)
}
}
}

This is analytic anti-aliasing — we compute exact sub-pixel coverage by integrating line segment contributions, not by supersampling. The result is mathematically precise edges with smooth alpha gradients.

Euler Spiral Flattening

But wait — DrawCircle produces cubic Bezier curves, not line segments. How do we get from curves to lines?

Vello uses Euler spiral approximation for adaptive curve flattening. Unlike naive subdivision (which produces too many or too few segments), Euler spirals provide optimal error bounds:

// FlattenFill flattens cubic Beziers using Vello's Euler spiral algorithm
func FlattenFill(cubics []CubicBezier) []LineSoup {
var lines []LineSoup
for _, c := range cubics {
p0 := vec2{c.P0[0], c.P0[1]}
p1 := vec2{c.P1[0], c.P1[1]}
p2 := vec2{c.P2[0], c.P2[1]}
p3 := vec2{c.P3[0], c.P3[1]}
flattenEulerFill(p0, p1, p2, p3, &lines)
}
return lines
}

The algorithm evaluates curvature at each point and subdivides only where the error exceeds a tolerance (0.25 pixels by default). A nearly-straight segment becomes 1 line. A tight curve gets more subdivisions. The result: minimum line segments for maximum visual quality.

Per-Tile Command Lists (PTCL)

The coarse stage (Stage 7) generates Per-Tile Command Lists — each tile gets a stream of commands like "fill with coverage from segment N", "apply color #FF0000", "begin clip", "end clip". This is what makes the pipeline work for multiple overlapping paths (UI with buttons, text, backgrounds) in a single fine rasterization pass:

// PTCL commands
const (
CmdEnd       = 0
CmdFill      = 1  // Compute coverage from segments
CmdSolid     = 3  // Full coverage (no segments needed)
CmdColor     = 5  // Apply RGBA color with source-over blending
CmdBeginClip = 10 // Push clip layer
CmdEndClip   = 11 // Pop and composite clip
)

The fine rasterizer walks each tile's PTCL, executing commands and compositing results with premultiplied alpha — exactly like a GPU would:

func fineRasterizeTile(ptcl *PTCL, segments []PathSegment,
bgColor [4]float32) [TileWidth * TileHeight][4]float32 {

const pixelCount = TileWidth * TileHeight
var rgba [pixelCount][4]float32
for i := range rgba {
rgba[i] = bgColor
}

for {
tag, nextOffset := ptcl.ReadCmd(offset)
switch tag {
case CmdEnd:
return rgba
case CmdFill:
// Compute coverage, store in area buffer
case CmdColor:
// Apply color using area as mask, source-over blend
case CmdBeginClip:
// Push current pixels onto clip stack
case CmdEndClip:
// Pop and composite with clip mask
}
}
}

Dual Execution: Why Both CPU and GPU?

tilecompute is a dual-execution pipeline: the same 9-stage algorithm runs on both CPU (sequential Go code) and GPU (WGSL compute shaders dispatched via VelloComputeDispatcher). Why maintain both?

1. CPU is the Core. After analyzing 8 enterprise 2D engines (Skia, Cairo, Vello, Blend2D, tiny-skia, piet, Qt RHI, Pathfinder), we found that in zero of them is CPU rasterization a "backend". It's always the core. GPU is the optional accelerator.

2. Correctness Reference. The CPU implementation serves as a reference for the GPU compute shaders. When GPU and CPU produce different results, we know which one to trust.

3. Universal Availability. Servers, CI/CD, embedded systems — many environments have no GPU. A server generating 10,000 chart images doesn't need GPU acceleration; it needs reliable software rendering.

4. Identical Algorithm, Dual Execution. The CPU code mirrors the GPU pipeline stage-by-stage — same data structures, same logic. The 9 WGSL compute shaders are //go:embedded and compiled into GPU compute pipelines via hal.Device.CreateComputePipeline(). When a GPU is available, VelloComputeDispatcher dispatches all 9 stages in parallel with pass.Dispatch(); when not, the CPU executes them sequentially.

Two Rasterizers, Two Targets

tilecompute is not the only Vello algorithm we've ported. gogpu/gg includes both of Vello's rasterization pipelines — each optimized for a different execution target:

	tilecompute	SparseStripsRasterizer
Vello era	Original (2020–2023)	New (Issue #670, August 2024)
Source	`vello_shaders/src/cpu/`	`sparse_strips/vello_cpu/`
Tile size	16x16 (256 pixels)	4x4 (16 pixels)
Optimized for	GPU compute workgroups	CPU / SIMD registers
Key insight	256 pixels = GPU workgroup size	16 u8 pixels = one 128-bit SSE register
Data flow	Monoid prefix sums → PTCL	Sort by Y,X → strip rendering
Package	`internal/gpu/tilecompute/`	`internal/gpu/sparse_strips.go`

Why 16x16 for GPU? GPU compute shaders process tiles in parallel workgroups. 256 pixels per tile matches the typical workgroup size (256 threads), giving each thread exactly one pixel.

Why 4x4 for CPU? SIMD instructions operate on 128-bit registers. 16 pixels of u8 coverage data fit into a single SSE register, enabling vectorized operations across an entire tile at once — the same approach Intel used in Larrabee.

Both rasterizers use analytic anti-aliasing, Euler spiral flattening, and support NonZero/EvenOdd fill rules. The difference is purely in how they partition the canvas and process tiles.

gogpu/gg Rasterization Engines
    │
    ├── tilecompute (16x16 tiles) — DUAL EXECUTION
    │      ├── CPU: sequential Go (reference + fallback)
    │      └── GPU: 9 WGSL shaders via VelloComputeDispatcher
    │
    └── SparseStripsRasterizer (4×4 tiles) — CPU
           CPU/SIMD-optimized pipeline
           Sort by Y,X + strip rendering

Having both means gogpu/gg selects the optimal algorithm for the target: GPU compute dispatches the 16x16 pipeline via WGSL shaders, CPU rendering defaults to the 4x4 pipeline for SIMD efficiency.

Smart Multi-Engine Selection

Having multiple rasterizers raises a question: who decides which algorithm handles which path?

We analyzed 8 enterprise 2D engines — Skia, Cairo, Blend2D, Vello, Qt, Direct2D, Flutter, SwiftUI — and found that none of them do per-path dynamic algorithm selection. Skia has separate CPU/GPU pipelines but no cross-selection. Vello has a planned vello_api for CPU/GPU choice, not yet built. Direct2D recognizes simple shapes but doesn't switch algorithms.

gogpu/gg is the first 2D graphics library with systematic multi-factor per-path selection across 5 rasterization algorithms:

Path arrives at Context.Fill()
    │
    ├── Shape detection → SDF Accelerator (circles, rrects)
    │     GPU SDF or CPU SDF — smoothstep coverage, highest quality
    │
    ├── Adaptive threshold check
    │     │
    │     ├── Below threshold → AnalyticFiller (scanline)
    │     │     Zero tile overhead, O(width × edges)
    │     │
    │     └── Above threshold → AdaptiveFiller
    │           │
    │           ├── < 10K segments → SparseStrips (4×4 tiles)
    │           │     CPU/SIMD-optimized, lower tile overhead
    │           │
    │           └── > 10K segments + large canvas → TileCompute (16×16 tiles)
    │                 GPU workgroup-ready, 16× fewer tiles
    │
    └── GPU Compute → Vello PTCL pipeline (full scene)
          9-stage GPU compute, massively parallel

The Coregex Analogy

The pattern is inspired by coregex — a Go regex library with 17 strategies and an intelligent selector that picks the optimal engine per-pattern. Same idea: analyze the input, pick the optimal engine. Both Go libraries, both first-of-kind multi-engine approaches.

	coregex	gogpu/gg
Engines	17 regex strategies	5 rasterization algorithms
Selection	Pattern analysis	7-dimension path analysis
Input	Regex pattern	Vector path
Output	Match result	Pixel coverage

Adaptive Threshold

The key insight: scanline cost grows with width × edge crossings, while tile cost grows with fill area. For large shapes, tiles win at lower complexity. For tiny shapes (< 32px), scanline always wins.

The selection between scanline and tile-based rasterizers uses an adaptive threshold derived from the path's bounding box area:

// threshold = max(32, 2048/sqrt(bboxArea))
//
// 100×100 bbox → threshold 20 elements (tiles kick in early)
// 500×500 bbox → threshold  4 elements (large shapes → always tiles)
//  30×30  bbox → always scanline (below bboxMinDimension)
func adaptiveThreshold(bboxArea float64) int {
if bboxArea <= 0 {
return maxElementThreshold
}
threshold := int(2048.0 / math.Sqrt(bboxArea))
return clamp(threshold, 32, 256)
}

User Override

Auto-selection is the default, but the user always has final say — the same principle as database query hints or GPU driver force flags:

dc := gg.NewContext(800, 600)

// Auto (default) — intelligent per-path selection
dc.SetRasterizerMode(gg.RasterizerAuto)

// Force scanline for all paths (debugging, isolation)
dc.SetRasterizerMode(gg.RasterizerAnalytic)

// Force 4×4 tiles (benchmarking CPU/SIMD path)
dc.SetRasterizerMode(gg.RasterizerSparseStrips)

// Force 16×16 tiles (benchmarking GPU workgroup path)
dc.SetRasterizerMode(gg.RasterizerTileCompute)

// Force SDF for maximum circle/rrect quality
dc.SetRasterizerMode(gg.RasterizerSDF)

The mode is per-Context — different contexts can use different strategies simultaneously. This makes A/B benchmarking trivial: render the same scene with two contexts, compare output and timing.

Numbers

Metric	Value
Go source	2,878 LOC
Test code	2,194 LOC
WGSL shaders	1,695 LOC (9 shaders)
Total	6,767 LOC
Tile size	16x16 pixels
Fill rules	NonZero, EvenOdd
Golden test threshold	0.15% max pixel difference

The 9 WGSL compute shaders are //go:embedded into VelloComputeDispatcher, compiled into GPU compute pipelines, and dispatched with pass.Dispatch() — the same algorithm running on both CPU (reference/fallback) and GPU (parallel compute).

Part of a Larger Ecosystem

tilecompute is the rasterization core of gogpu/gg, which is part of a 466K+ line Pure Go GPU computing ecosystem:

Project	Description	LOC
gogpu/gg	2D graphics library	186K
gogpu/wgpu	Pure Go WebGPU	110K
gogpu/naga	Shader compiler	61K
gogpu/ui	GUI widget toolkit	61K
gogpu/gogpu	GPU framework	40K

The default stack is zero CGO, Pure Go — from shader compilation to GPU command submission. But gogpu also supports a Rust backend via go-webgpu FFI to wgpu-native for maximum GPU performance when needed:

Backend	Stack	Build	Use Case
Pure Go (default)	gogpu/wgpu → Vulkan/Metal/GLES	`go build`	Zero dependencies, easy cross-compile
Rust FFI (opt-in)	go-webgpu → wgpu-native	`go build -tags rust`	Maximum GPU performance, production

Both backends use the same gg API — the choice is transparent to application code. gg doesn't know or care which WebGPU implementation is underneath; it talks to hal.Queue.

When GPU acceleration is available, gg uses the registered WebGPU backend (Pure Go or Rust) with support for Vulkan, Metal, DX12, and OpenGL ES. When it's not — tilecompute and the CPU rasterizer handle everything.

Acknowledgments

The Vello team and Raph Levien for the tile rasterization pipeline and Euler spiral flattening research
The variable naming in tilecompute intentionally matches Vello's Rust originals for easy cross-reference

Links

GitHub: gogpu/gg
Package: internal/gpu/tilecompute/
Vello: linebender/vello
Raph Levien's blog: raphlinus.github.io
Discussion: Join the conversation

go get github.com/gogpu/gg@latest

Pure Go GUI Toolkit 2026 — 425K LOC Ecosystem, Zero CGO, WebGPU (gogpu/ui)

Andrey Kolkov — Sat, 21 Feb 2026 13:38:23 +0000

Series: Building Go's GPU Ecosystem

GoGPU: A Pure Go Graphics Library — Project announcement

From Idea to 100K Lines in Two Weeks — The journey

Pure Go 2D Graphics with GPU Acceleration — Introducing gg

GPU Compute Shaders in Pure Go — Compute pipelines

Go 1.26 Meets 2026 — Ecosystem overview

Enterprise 2D Graphics Library — gg architecture

Cross-Package GPU Integration — gpucontext

Unified 2D/3D Graphics Integration — gg + gogpu

Core Complete, Focus on GUI ← You are here

The Foundation is Done

Three months ago, GoGPU was an idea. Today it's 425,000+ lines of Pure Go — a complete GPU computing stack with a shader compiler, WebGPU implementation, 2D graphics library, and application framework. All without CGO.

The core architecture that powers everything — from shader compilation to pixel output — is production-ready. And that means it's time to build what this was all leading to: a real GUI toolkit for Go.

Where We Are: The Ecosystem at a Glance

Active Development

Project	What It Does	LOC	Status
gogpu/ui	GUI Toolkit	55K	Phase 2 Beta

Foundation (Maintenance Mode)

Project	What It Does	LOC	Version
gogpu/gg	2D Graphics (Canvas, GPU accel, text)	167K	v0.29.0
gogpu/wgpu	Pure Go WebGPU (Vulkan/DX12/Metal/GLES)	105K	v0.16.9
gogpu/naga	Shader Compiler (WGSL → SPIR-V/MSL/GLSL/HLSL)	54K	v0.14.1
gogpu/gogpu	Application Framework (windowing, input)	37K	v0.20.0
+ 4 more	gpucontext, gputypes, gg-pdf, gg-svg	9K	Stable

The foundation libraries handle issues, feature requests, bug fixes, and performance improvements as they come in. Their architecture is settled. Our full energy goes into gogpu/ui.

Why Build Another GUI Toolkit?

Go's GUI landscape has options — Fyne, Gio, Wails. We respect all of them. But we're solving a different problem:

We want Go to power the applications that currently require Electron, Qt, or native platform toolkits. IDEs. Design tools. CAD. Professional dashboards.

That means:

Zero CGO — go build and it works, everywhere
WebGPU rendering — native GPU acceleration on all platforms
Enterprise layout — Flexbox, Grid, docking, virtualization
Reactive state — Signals-based data binding (not callbacks)
Accessibility — ARIA roles from day one, not bolted on later
Pluggable design systems — Material 3 today, Fluent or Cupertino tomorrow

Architecture: Three Layers, Clean Separation

Layer 3b: Design Systems ── theme/material3/ (HCT color science)
Layer 3a: Generic Widgets ── core/button/, core/checkbox/, core/radio/
Layer 2:  CDK (headless)  ── Content[C] polymorphic pattern
Layer 1:  Foundation      ── widget/, event/, geometry/, layout/

The key insight: widgets don't know their design system.

A button.Button defines behavior — click handling, keyboard activation, focus management. How it looks is determined by a Painter interface that the design system implements.

// The widget defines behavior
btn := button.New(
    button.Text("Submit"),
    button.OnClick(func() { save() }),
    button.VariantOpt(button.Filled),
)

// Material 3 painter handles appearance
// (injected via ThemeProvider, not imported by the widget)

This means:

Core widgets are design-system-agnostic
Swapping from Material 3 to Fluent is changing one import
Community can create custom design systems without forking widgets

Dependency Inversion

gogpu/ui never imports gogpu directly. Instead, it depends on interfaces from gpucontext:

ui ──imports──> gpucontext (interfaces: WindowProvider, EventSource)
examples ──imports──> gogpu (concrete implementation)

This means you can test the entire widget tree headlessly — no window, no GPU, just unit tests. The toolkit has 97% average test coverage across all packages.

What's Already Working

Phase 0: Foundation (Complete)

Core infrastructure that every widget builds on:

geometry — Point, Size, Rect, Constraints, Insets
event — Mouse, keyboard, wheel, focus events with modifier keys
widget — Widget interface with 3-phase lifecycle (Layout → Draw → Event)
layout — CSS Flexbox, VStack/HStack, CSS Grid engines
render — Canvas implementation backed by gogpu/gg

Phase 1: MVP (Complete)

The basics needed for a working application:

state — Reactive signals (Signal, Computed, Effect, Binding, Scheduler) wrapping coregx/signals
a11y — Accessibility tree with 35+ ARIA roles
primitives — Box, Text, Image display widgets with fluent API
app — Window integration via gpucontext interfaces

Phase 1.5: Extensibility (Complete)

Enabling the community to build on top:

registry — Widget factory registration with categories
plugin — Plugin bundling with dependency resolution
theme — Base theme system (ColorPalette, Typography, Spacing, Shadows, Radii, Extensions)
layout (public) — Custom layout algorithms

Phase 2: Beta (75% Complete)

Interactive widgets and Material Design:

button — 4 variants (Filled, Outlined, TextOnly, Tonal), 3 sizes, keyboard activation
checkbox — Checked / unchecked / indeterminate, label support
radio — Radio groups with vertical/horizontal layout, arrow key navigation
focus — Tab/Shift+Tab navigation, keyboard shortcuts, focus ring
cdk — Component Development Kit with Content[C] polymorphic pattern
material3 — HCT color science, 32 color roles, 15 typography roles, painters for all widgets

Remaining for Phase 2: TextField, Dropdown, Slider, Progress indicators, Typography system, Icon system

A Working Example

Here's a real application running today — ui/examples/hello:

func main() {
    gogpuApp := gogpu.NewApp(gogpu.DefaultConfig().
        WithTitle("gogpu/ui — Widget Demo").
        WithSize(800, 600).
        WithContinuousRender(false)) // Event-driven: 0% CPU idle

    uiApp := app.New(
        app.WithWindowProvider(gogpuApp),
        app.WithPlatformProvider(gogpuApp),
        app.WithEventSource(gogpuApp.EventSource()),
    )
    uiApp.SetRoot(buildUI())

    // ... rendering pipeline setup ...
    gogpuApp.Run()
}

func buildUI() *primitives.BoxWidget {
    return primitives.Box(
        primitives.Text("gogpu/ui — Widget Demo").
            FontSize(28).Bold().
            Color(widget.RGBA8(33, 33, 33, 255)),

        checkbox.New(
            checkbox.LabelOpt("Enable notifications"),
            checkbox.Checked(true),
            checkbox.OnToggle(func(checked bool) {
                fmt.Println("notifications:", checked)
            }),
        ),

        radio.NewGroup(
            radio.Items(
                radio.ItemDef{Value: "light", Label: "Light"},
                radio.ItemDef{Value: "dark", Label: "Dark"},
                radio.ItemDef{Value: "system", Label: "System"},
            ),
            radio.Selected("system"),
            radio.DirectionOpt(radio.Horizontal),
        ),
    ).Padding(32).Gap(12).
      Background(widget.RGBA8(255, 255, 255, 255)).
      Rounded(12).ShadowLevel(2)
}

Key characteristics:

Event-driven rendering — 0% CPU when nothing changes
GPU-direct pipeline — widgets render through gg, ggcanvas blits directly to the GPU surface (zero-copy)
Functional options — clean construction without builder hell
Fluent styling — .Padding().Gap().Background().Rounded() chains

The rendering pipeline:

Widget tree → render.Canvas (gg) → ggcanvas → GPU surface
                                    ↓
                              Zero CPU readback
                              Direct GPU composition

What's Next

Near-term: Phase 2 Completion

Widget	Description	Status
TextField	Text input with cursor, selection, clipboard	Next up
Dropdown	Popup selection with search	Planned
Slider	Range input with track and thumb	Planned
Progress	Determinate and indeterminate indicators	Planned

Phase 3–4: IDE-Class Application Shell

This is where it gets ambitious. The target is GoLand-class IDE layout — the kind of application shell that currently requires Electron, Qt, or platform-native code:

┌──────────────────────────────────────────────────────────┐
│  Toolbar                                                 │
├────────┬─────────────────────────────────┬───────────────┤
│        │  Tab1 │ Tab2 │ Tab3             │               │
│  Left  │─────────────────────────────────│  Right Panel  │
│  Panel │                                 │  (Inspector,  │
│  (Tree,│     Main Editor Area            │   Properties) │
│  Files)│                                 │               │
│        │                                 │               │
├────────┴──────────────────┬──────────────┴───────────────┤
│  Terminal │ Problems │ Git│                              │
│  Bottom Panel (resizable, collapsible)                   │
└──────────────────────────────────────────────────────────┘

The building blocks for this, in order:

Component	Phase	Description
ScrollView	3	Smooth scrolling with inertia
TabView	3	Editor-style tabs with close buttons, reordering
SplitView	3	Resizable horizontal/vertical splits
Dialog/Modal	3	Popup windows with focus trapping
Popover/Tooltip	3	Context menus, hover tooltips
VirtualizedList/Grid	3	Render 100K items (file trees, logs)
Animation Engine	3	Spring physics, transitions, easing
Docking System	4	Draggable panels — left, right, bottom, floating
Drag & Drop	4	Cross-widget, cross-window DnD (tab reordering, panel docking)
Fluent Theme	4	Windows-native look
Cupertino Theme	4	macOS-native look
i18n	4	RTL text, locale-aware formatting

The docking system is the crown jewel — panels that snap to left/right/bottom, collapse to icon strips, drag between positions. Exactly what you see in GoLand, VS Code, or Photoshop. Built entirely in Go, rendered entirely on the GPU.

The Core Libraries: Maintenance Mode

With the GUI toolkit as the primary focus, the lower-level libraries shift to maintenance:

Library	Focus Going Forward
gg (2D graphics)	Bug fixes (#95 AA quality, #72 circle artifact), GPU pattern support, performance
wgpu (WebGPU)	Community bug reports, platform-specific fixes, new HAL features as needed
naga (shaders)	HLSL matrix fix (DX12 text rendering), new shader targets on demand
gogpu (framework)	Community issues (#82 NVIDIA crash, #89 macOS Tahoe), WASM support (#70)

This doesn't mean they're done — it means they're stable enough to build on while we focus our development time on the toolkit that will use them.

Numbers

Metric	Value
Total ecosystem	425K+ lines of Go
UI toolkit alone	55K lines, 208 Go files
Test functions (UI)	1,400+
Test coverage (UI)	97% average
GPU backends	5 (Vulkan, DX12, Metal, GLES, Software)
Shader targets	4 (SPIR-V, MSL, GLSL, HLSL)
Platforms	Windows, Linux (X11/Wayland), macOS
CGO required	None

Try It

# Clone and run the hello example
git clone https://github.com/gogpu/ui
cd ui/examples/hello
go run .

Requirements: Go 1.25+, a GPU with Vulkan/DX12/Metal/GLES support.

Get Involved

We're building this in the open and we want your input:

GitHub Discussions — Feature requests, architecture feedback
gogpu/ui Issues — Bug reports, widget requests
gogpu Organization — All repositories

The foundation is solid. Now comes the fun part — building the toolkit that makes Go a first-class citizen for desktop applications.

The GoGPU ecosystem is MIT-licensed. Contributions welcome.

Smart Coding: What Karpathy's Agentic Engineering Is Missing (630K LOC of Proof)

Andrey Kolkov — Thu, 12 Feb 2026 10:58:09 +0000

On February 4, 2026, Andrej Karpathy — the person who gave us "vibe coding" exactly one year earlier — declared it passé. His replacement term: Agentic Engineering.

"Agentic — because the new default is that you are not writing the code directly 99% of the time, you are orchestrating agents. Engineering — because there is an art & science and expertise to it."

The term landed in a landscape already primed for it. Anthropic had just released their 2026 Agentic Coding Trends Report. A Hacker News thread asking "Do you have any evidence that agentic coding works?" pulled 461 points and 455 comments. An academic paper on arXiv had already formalized the paradigm split. And within days of Karpathy's post, Addy Osmani (Google) published a detailed framework and announced an O'Reilly book titled Beyond Vibe Coding.

I've been practicing and writing about this exact shift since January 2026 — a month before Karpathy named it. My Smart Coding article laid out the same core idea: engineering discipline plus AI as an accelerator, not a replacement.

I'm not claiming credit for the term. But the conversation is still incomplete. Karpathy gave us a great name. Osmani gave us a great workflow. Both frameworks miss a critical piece that I've found essential across 35+ production projects.

The Three Paradigms: Understanding the Spectrum

The community keeps framing this as a binary: Vibe Coding vs. Agentic Engineering. That's wrong. There are actually three distinct paradigms, and understanding all three is the key to working effectively with AI.

Vibe Coding: Exploration Mode

Karpathy's original description (February 2025): "You fully give in to the vibes, embrace exponentials, and forget that the code even exists."

When it works: Prototypes, hackathons, learning new APIs, feasibility spikes. You prompt, you accept, you run, you see if it works. Fast and cheap — and the code is disposable.

When it fails: Production. As a survey of 18 CTOs revealed, 16 experienced production disasters directly caused by unreviewed AI-generated code. The code compiled. The tests (auto-generated, shallow) passed. The bugs were subtle, the security vulnerabilities real.

Agentic Engineering: Orchestration Mode

Karpathy's new framework: you orchestrate AI agents while maintaining oversight.

What it gets right:

Developers are no longer typists — they're orchestrators
Multiple agents can work in parallel (code, test, review)
Quality gates and automated validation are essential
The skill is in specification and oversight, not syntax

What it misses: More on this below.

Smart Coding: The Unifying Framework

My take: Smart Coding isn't the opposite of either Vibe Coding or Agentic Engineering. It's the framework that encompasses both.

┌─────────────────────────────────────────────┐
│              SMART CODING                   │
│         (The Meta-Framework)                │
│                                             │
│  ┌─────────────┐    ┌───────────────────┐   │
│  │ Vibe Coding │    │    Agentic        │   │
│  │ (Explore)   │───→│    Engineering    │   │
│  │             │    │    (Build)        │   │
│  └─────────────┘    └───────────────────┘   │
│         ↑                    │              │
│         └────────────────────┘              │
│    Feedback loop + Knowledge accumulation   │
└─────────────────────────────────────────────┘

Smart Coding is knowing when to Vibe and when to Engineer — and, crucially, how to make each session compound on the last. It's the judgment layer that neither paradigm addresses on its own.

Vibe Coding answers: how do I explore quickly?
Agentic Engineering answers: how do I build with AI agents?
Smart Coding answers: how do I decide, learn, and get better at both over time?

What Karpathy Got Right

Credit where it's due — Karpathy nailed several things:

1. The 99% observation is accurate.
This isn't hyperbole. Boris Cherny, head of Claude Code at Anthropic, says he hasn't written a line of code by hand in over two months — shipping 22-27 PRs per day, all 100% AI-generated. OpenAI researcher Roon says the same: "100%, I don't write code anymore." Anthropic's CPO Mike Krieger confirms that for most products it's "effectively 100%", with the company-wide average at 70-90%. In my own daily work across multiple Go ecosystems, I'd put it at 90-95%. My role is architecture, specification, review.

2. "Engineering" is the right word.
Calling it "engineering" demands rigor. It's not "agentic vibing" or "agentic prompting." The word engineering implies standards, validation, discipline.

3. The timing is right.
Models in early 2026 (Claude Opus 4.6, GPT-5, Gemini 2.5) are genuinely capable of multi-step autonomous work. Agentic workflows that failed in 2024 now succeed reliably with proper guidance.

4. The self-awareness is refreshing.
Karpathy calling his original vibe coding tweet a "shower of thoughts throwaway" is honest. The fact that it resonated shows the community was ready for the vocabulary, not that the term was deeply considered.

What's Missing: The Bidirectional Learning Gap

Neither Karpathy nor Osmani fully address this: the AI doesn't learn from you, and most developers don't systematically learn from AI.

Osmani's framework says: "Start with a plan. Direct. Review. Test. Own the codebase." All correct. But it treats AI as a stateless contractor — you give instructions, it delivers code, you review. Next session, same blank slate.

This is like hiring a developer who forgets everything every morning.

Teaching Your AI Agent

In my Smart Coding article, I described the Knowledge File Pattern — a dedicated context file that your AI agent reads at the start of every session:

# PROJECT_CONTEXT.md

## Architecture
- Hexagonal architecture with ports/adapters
- All external services accessed through interfaces
- No business logic in HTTP handlers

## Conventions
- Error wrapping with context, never naked errors
- Structured JSON logging with request_id
- Table-driven tests for validation logic

## Domain Knowledge
- "Settlement" = end-of-day batch processing
- Customer IDs are UUIDs, Order IDs are sequential

## Known Pitfalls
- Redis cluster doesn't support MULTI in our setup
- Legacy API returns 200 for errors — check body
- Date fields from Partner X: ISO but no timezone

## Lessons Learned
- Week 1: AI suggested time.Now() → added: "Use injected clock"
- Week 2: AI used fmt logger → added: "Use zerolog with context"
- Week 3: AI flat package layout → added: "Domain-driven packages"

This file is a living document that accumulates project wisdom. Each AI mistake becomes a permanent correction. Each session starts where the last one ended.

In practice, I go further. Each project has a STATUS.md that the agent reads at session start and updates on exit — current progress, near-term plans, discovered problems that need investigation. Detailed tasks go into an internal kanban broken into stages with interdependencies. There are LINTER_RULES files that agents read during coding and update when they discover new patterns — so code passes golangci-lint on the first try, not the fifth.

Each repository also maintains a research knowledge base — results of investigations, benchmarks, comparisons with alternative approaches, and crucially, why specific design decisions were made, with the full context of the decision. For an ecosystem like GoGPU with 9 interrelated repositories, there's an ecosystem-wide research base on top of per-repo ones. When you revisit a decision six months later, you don't have to reverse-engineer your own reasoning — it's documented, with the alternatives you considered and why you rejected them.

And the knowledge is hierarchical. The root-level context knows about all repositories in the ecosystem but doesn't go deep. Each project essentially has its own agent that fully owns its repository — knows every module, every convention, every quirk. It practically lives inside the codebase. When I switch between projects, the context switches with me, and each agent picks up right where it left off.

The agent doesn't just know how to write code for this project — it knows where we left off, what problems we've spotted, and what's next.

The Feedback Loop Karpathy Doesn't Mention

Session 1: AI makes 20 mistakes. You correct 20.
           → 20 corrections added to knowledge file.

Session 2: AI makes 5 mistakes (15 prevented by context).
           → 5 new corrections added.

Session 3: AI makes 1 mistake.
           → Your knowledge file is now a comprehensive project spec.

This is bidirectional learning: you learn AI's patterns and capabilities, AI (via context) learns your project's constraints and conventions. Over weeks, this compounds dramatically.

Without this feedback loop, agentic engineering is like conducting an orchestra that can't remember the piece they played yesterday. You spend half your time re-explaining context instead of making progress.

The exchange is asymmetric, and that's the point. You know better: project context, business domain, team conventions, past mistakes, infrastructure quirks, stakeholder constraints. AI knows better: syntax across languages, algorithm tradeoffs, library APIs, boilerplate patterns, cross-ecosystem solutions. Smart Coding makes this exchange systematic and cumulative, not ad hoc and forgotten.

Knowledge Consolidation: Keeping Context Sharp

There's a catch that nobody talks about. Knowledge files grow. Fast. After weeks of daily sessions, your PROJECT_CONTEXT.md becomes a sprawling document with redundant entries, outdated lessons, and contradictory notes from different project phases. The AI agent starts drowning in its own context — reading hundreds of lines of accumulated wisdom where half no longer applies.

You need to periodically consolidate your knowledge files. Think of it as garbage collection for project context.

Week 1-4:   Knowledge file grows organically (additions only)
Week 5:     Consolidation pass
            - Remove lessons the AI no longer needs (patterns now habitual)
            - Merge duplicate entries
            - Update outdated conventions (API changed, dependency upgraded)
            - Restructure: separate "always relevant" from "situational"
            - Archive historical context that's no longer actionable

In practice, I do a consolidation pass every few weeks — or whenever I notice the agent making mistakes it shouldn't, which often means it's losing important rules in a sea of less relevant ones. Context windows are large but not infinite, and signal-to-noise ratio matters more than volume.

The consolidation itself is a form of learning. Reviewing what accumulated forces you to reflect: which patterns stuck? Which conventions evolved? What assumptions turned out wrong? It's a checkpoint for both the project and your own understanding of it.

Pro tip: Keep a separate archive file for removed entries. You might need them if you revisit an old subsystem or onboard someone new. The active knowledge file should be lean and current — a briefing, not a history book.

Real-World Case: Building Where Go Was Weakest

Enough theory. What does Smart Coding look like at scale?

It started last summer, when I decided to publish my internal HDF5 and MATLAB parsers as open-source libraries. These were working code extracted from private projects — battle-tested, but not shaped for public consumption. Packaging them properly (documentation, CI, tests, API design) was the first exercise.

Then something clicked. I had years of accumulated private code solving problems where Go was traditionally weak — and modern AI agents (Claude Opus 4.6 in particular) made it feasible to extract, refactor, and publish at a pace I couldn't have imagined before. Without these tools, I could realistically maintain one, maybe two open-source projects alongside my regular work. With Smart Coding, I've shipped 35+.

There's a personal angle here too. After COVID-19, my vision deteriorated — I developed polyopia and ghosting, where letters and digits multiply across different depth layers on screen, like looking through layered glass at night in a subway tunnel. Not simple doubling — images shift along random axes, some closer, some further, overlapping unpredictably. Post-COVID corneal and lens changes are well-documented, and mine made reading code character by character genuinely exhausting. Agentic engineering changed my relationship with the screen: I focus on code flow, architecture, and diffs — not on typing every semicolon and bracket. My eyes track the big picture while agents handle the detail work. It's not just a productivity story. For developers dealing with vision impairment, RSI, or other physical constraints, this way of working can be genuinely life-changing.

I want to be honest about this: AI didn't design these libraries. I did. The architecture, the API decisions, the choice of which problems to solve — that's decades of engineering experience. But AI turned what would have been years of solo implementation work into months. That's the force multiplier effect in action.

What that looks like in practice — across a systematic effort to fill Go's blind spots:

The Pattern: Identifying Architectural Gaps

Go is excellent for servers, CLI tools, and infrastructure. But it has well-known blind spots:

Domain	The Gap	What Existed
GPU/Graphics	No unified ecosystem (vs. Rust's wgpu+naga+bevy)	Individual libs (Ebiten, Gio, Fyne), all CGO-based
Regex	stdlib is intentionally slow (single RE2 engine)	No multi-engine alternative
ML/Deep Learning	Python dominance, Rust has Burn	No production Go framework
Scientific formats (HDF5, MATLAB)	CGO wrappers only, no write support	No pure Go read/write implementations
Race detection	Built-in requires CGO	Can't use on Lambda/Alpine
PDF processing	Limited libraries	No enterprise-grade option

AI agents can't identify these gaps. They don't understand ecosystem dynamics, community pain points, or the strategic value of filling a specific niche. That's architecture thinking — the human's job.

GoGPU: 630K+ Lines of Pure Go Graphics

GoGPU is a full GPU computing ecosystem: 630,000+ lines of pure Go across 9 repositories. A WebGPU implementation (127K LOC), a 2D graphics library (204K LOC), a shader compiler (90K LOC) translating WGSL to SPIR-V/MSL/GLSL/HLSL, a UI toolkit (161K LOC), PDF and SVG export backends. 429+ stars and growing. Five GPU backends (Vulkan, DirectX 12, Metal, GLES, Software), three platforms.

Go had graphics libraries before this — Ebitengine for 2D games, Gio and Fyne for UI. But what it lacked was what Rust has built over years: a cohesive, integrated GPU ecosystem. Rust's wgpu + naga + Bevy + Iced form an interconnected stack from low-level HAL to high-level UI — all pure Rust, all interoperable. Go had nothing comparable. Every existing option required CGO, and there was no shader compiler, no unified abstraction layer, no path from GPU compute to rendered pixels without leaving Go.

GoGPU fills that gap: a pure Go stack from shader compilation to 2D graphics to UI toolkit.

This was impossible to Vibe Code. The architecture decisions — how to structure a shader compiler pipeline, how to map WebGPU's memory model to Go's garbage collector, how to design cross-platform rendering abstractions across five GPU backends — require deep understanding of both GPU programming and Go's runtime characteristics.

But it was also impossible without AI agents. Translating shader compiler patterns from Rust's naga to idiomatic Go? Implementing a WebGPU HAL across five backends? That's exactly where agentic engineering shines — clearly specified translation tasks with well-defined inputs and outputs, executed at a pace no single developer could match.

The Smart Coding approach:

Vibe phase: Explore Rust's naga codebase, understand the architecture (throwaway spikes)
Architecture phase: Design Go-idiomatic module boundaries, memory layout, API surface (human)
Agentic phase: AI agents implement well-specified components under strict review
Knowledge accumulation: Each module taught the AI about Go-specific GPU patterns, making subsequent modules faster

Coregex: Multi-Engine Regex, 3-3000x Faster Than stdlib

Coregex (156 stars) is a multi-engine regex library inspired by Rust's regex crate architecture — multiple execution engines (Thompson NFA, Pike VM, one-pass DFA, bounded backtracker) with an intelligent meta-engine that selects the optimal strategy per pattern. It outperforms Go's stdlib by 3 to 3000x depending on the pattern.

You can't Vibe Code a multi-engine regex library. The meta-engine selection logic, Thompson NFA construction, Pike VM execution, SIMD-accelerated literal search — each requires deep algorithmic understanding and careful architectural decisions about when to dispatch to which engine. But you can use AI agents to implement well-specified automaton transitions, generate comprehensive test suites from regex grammar specifications, and benchmark systematically.

The knowledge file for this project grew to include regex-specific patterns:

## Regex Engine Conventions
- NFA states use uint32, not int (SIMD alignment)
- All character class operations must be branchless
- Thompson construction: no epsilon-removal optimization
  (benchmarks showed it's slower for our pattern distribution)

Every session with AI was more productive than the last because the context accumulated.

Born: Go's Answer to Burn

Born (51 stars) is a production ML framework with PyTorch-like API, automatic differentiation, and type-safe tensors — Go's answer to Rust's Burn framework. Where Burn brought deep learning to Rust with swappable backends and ONNX interop, Born brings it to Go with the same philosophy: single binary deployment, compile-time type safety, and zero external dependencies.

Here, the cross-ecosystem research pattern was critical. AI agents researched Burn's backend trait architecture, PyTorch's autograd implementation, JAX's tracing approach, and Tinygrad's minimalist design. But the human decided: Go's strengths (single binary deployment, generics-based type safety, goroutine parallelism) dictate a different design than either Python's dynamic typing or Rust's ownership model allows.

Smart prompt vs. naive prompt:

Naive: "Implement backpropagation in Go"
→ Gets a textbook implementation that ignores Go's type system

Smart: "I've studied Burn's backend trait architecture, JAX's tracing,
and PyTorch's autograd. For Go, I want backpropagation that:
- Uses Go generics for type-safe tensor operations
- Leverages goroutines for parallel gradient computation
- Produces a computational graph that can be serialized
- Follows the conventions in PROJECT_CONTEXT.md
What are the tradeoffs vs. a tape-based approach for our use case?"
→ Gets an informed implementation that fits the ecosystem

The Pattern Across All Projects

Racedetector (35 stars) — pure Go race detector built on multiple research papers: FastTrack (Flanagan & Freund, PLDI 2009), escape analysis integration, shadow memory, vector clocks, and AST instrumentation. 359 tests ported from Go's official race detector suite. This required studying concurrent systems theory across several academic papers and synthesizing them into a cohesive architecture — then AI accelerated the implementation of each well-specified component.

HDF5 (23 stars) — full read/write support for HDF5 2.0.0 (Format Spec v4.0), including chunked datasets, GZIP/LZF/BZIP2 compression, hyperslab selection (10-250x faster partial reads), and 100% pass rate on the official 378-file test suite. MATLAB (10 stars) — read/write for both legacy v5-v7.2 and modern HDF5-based v7.3+ formats, covering all numeric types, complex numbers, sparse matrices, structures, and cell arrays. Both are pure Go, zero CGO — the only complete implementations in the Go ecosystem. Designing the architecture for these complex binary format specifications required deep human analysis; AI agents then implemented the byte-level parsing and serialization under strict test coverage.

GxPDF — started when a friend asked me to help parse bank statements from PDFs. Every bank had its own table format for transactions and balances. What began as a quick script grew into an enterprise PDF library — because the PDF spec is 1,300 pages and "quick" doesn't exist in PDF parsing. Human identified the subset that matters for production use; AI implemented the extraction pipeline.

GRPM — next-gen package manager for Gentoo. Here, AI agents first helped study and translate the entire Gentoo PMS (Package Manager Specification) into structured Markdown — creating a machine-readable knowledge base from dense technical documentation. That knowledge base then became the spec for implementation: each section mapped to code, tracked via a PMS compliance matrix. This is bidirectional learning in action — agents helped build the context, then used that same context to implement. SAT-based dependency resolution still required human CS fundamentals; but the documentation-to-implementation pipeline was pure agentic workflow.

Every single project followed the same cycle:

Human identifies the gap and designs the architecture
Vibe exploration of reference implementations
Knowledge file creation with project-specific constraints
Agentic implementation with growing context
Bidirectional learning compound effect

This is Smart Coding. Not Vibe. Not Agentic. Both, orchestrated by engineering judgment.

The Architect Mindset: Why Experience Still Matters

Karpathy wrote: "I've never felt this much behind as a programmer."

I'd reframe that: you've never been more valuable as an architect.

When AI handles 95% of implementation, what remains is the 5% that determines whether the software succeeds or fails:

System boundaries and module design — AI optimizes locally, architects think globally
Technology selection with full context — AI knows APIs, architects know ecosystems
Tradeoff evaluation — AI can list options, architects can weigh them against constraints AI doesn't see
Failure mode anticipation — AI builds the happy path, architects prevent the disasters
Conceptual integrity — AI generates code, architects maintain vision

Traditional:  Junior → Mid → Senior → Lead → Architect
              (Years of progression)

With AI:      Every developer must think like an architect
              (AI handles the junior-to-senior implementation work)

The Hacker News discussion on agentic coding confirmed this: the consensus was that "you get the most value when you know exactly what you want." Clear specifications matter more than model capability.

But knowing what you want requires experience. And experience compounds faster when you maintain a systematic feedback loop with your AI tools.

Practical Smart Coding Framework

The workflow I use daily, distilled from months of production work:

Phase 1: Assess (5 minutes)

Before touching any tool:

☐ Am I exploring or building?
☐ What are the system boundaries affected?
☐ What would I sketch on a whiteboard?
☐ Can I write a one-paragraph spec for this task?

If you can't write the spec, you're not ready for Agentic Engineering. Start with a Vibe spike.

Phase 2: Prepare Context

Update your knowledge file with anything relevant to this session:

☐ New constraints discovered since last session?
☐ Known pitfalls for this specific task?
☐ Conventions that must be followed?
☐ Related decisions already made?

This takes 2-3 minutes and saves 30+ minutes of correcting AI mistakes.

Phase 3: Execute (Vibe or Agentic)

Vibe mode (exploration):

Time-boxed to 30-60 minutes
Goal: knowledge, not code
Everything produced is throwaway

Agentic mode (building):

Detailed specs per component
AI agents implement, you review every diff
Tests required before proceeding
Knowledge file updated with lessons learned

Phase 4: Capture

After every session:

☐ What did AI get wrong? → Add to knowledge file
☐ What did AI teach me? → Add to personal notes
☐ What pattern emerged? → Document for future sessions
☐ Did my architecture assumptions hold? → Adjust if not

The 70/30 Rule

A practical heuristic: spend 70% of time on architecture, specification, review, and validation. Let AI accelerate the remaining 30% — the mechanical implementation.

This ratio seems counterintuitive. But the 70% investment is what makes the 30% valuable. Without understanding, AI output is just random characters that happen to compile.

The Terminology Doesn't Matter. The Practice Does.

Call it Smart Coding. Call it Agentic Engineering. Call it whatever you want. The principles are the same:

You own the architecture. AI owns the implementation.
You validate everything. AI generates candidates.
Context compounds. Every session builds on the last.
Mode awareness matters. Know when to explore and when to build.
Experience is your moat. AI levels the playing field on syntax. Architecture and judgment are your edge.

Karpathy gave us a great term. The industry needed vocabulary to distinguish disciplined AI-assisted development from reckless prompt-and-pray. "Agentic Engineering" is professional, precise, and descriptive.

But the term alone isn't enough. Without the bidirectional learning loop — without systematically teaching your AI agent about your project while learning from its capabilities — you're orchestrating an amnesiac. Productive today, starting from zero tomorrow.

Smart Coding is the practice that makes Agentic Engineering compound.

In January 2026, I published Smart Coding vs Vibe Coding — exploring the same ideas before Karpathy coined "Agentic Engineering." The principles hold up. The vocabulary evolved. The practice continues.

How are you managing the Vibe-to-Agentic transition? Are you maintaining knowledge files? Have you found the right explore/build ratio for your work? I'd love to compare approaches — share your experience in the comments.

About the Author

I'm Andrey Kolkov — a Full Stack developer (Go backend, Angular frontend) maintaining 35+ open source projects. I build in the spaces where Go is traditionally weakest: GPU computing, regex engines (3-3000x faster than stdlib), ML frameworks, and scientific computing. Each project is a daily exercise in Smart Coding — using AI as a force multiplier while maintaining engineering rigor.

GitHub: @kolkov | Projects: GoGPU, coregx, born-ml, scigolib

Tags: #ai #programming #productivity #softwaredevelopment

GoGPU: Unified 2D/3D Graphics Integration in Pure Go

Andrey Kolkov — Fri, 30 Jan 2026 05:02:04 +0000

Series: Building Go's GPU Ecosystem

GoGPU: A Pure Go Graphics Library — Project announcement

From Idea to 100K Lines in Two Weeks — The journey

Pure Go 2D Graphics with GPU Acceleration — Introducing gg

GPU Compute Shaders in Pure Go — Compute pipelines

Go 1.26 Meets 2026 — Roadmap

Enterprise 2D Graphics Library — gg architecture

Cross-Package GPU Integration — gpucontext

Unified 2D/3D Graphics Integration ← You are here

Introduction

Today we announce a major milestone for the GoGPU ecosystem: unified 2D/3D graphics integration through standardized interfaces. This release enables seamless rendering of 2D graphics (via gg) into GPU-accelerated windows (via gogpu) — all in Pure Go, without CGO.

This is the foundation for gogpu/ui, our upcoming enterprise-grade GUI toolkit.

The Problem We Solved

Modern applications need both 2D and 3D graphics:

UI elements (text, buttons, icons) require 2D rendering
Visualization (charts, graphs, CAD) requires GPU acceleration
Games and simulations require both

Traditionally, integrating these required:

CGO bindings to native libraries (Cairo, Skia, Qt)
Complex texture management between CPU and GPU
Tight coupling between graphics and windowing code

We solved this with interface-based architecture — a pattern proven in enterprise systems.

Architecture Overview

┌─────────────────────────────────────────────────────────────┐
│                    User Application                         │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│   ┌─────────────────┐        ┌──────────────────────────┐   │
│   │ gg (2D Graphics)│        │  gogpu (GPU Framework)   │   │
│   │                 │        │                          │   │
│   │  - Canvas API   │        │  - WebGPU abstraction    │   │
│   │  - Text/Fonts   │        │  - Multi-backend         │   │
│   │  - Paths/Shapes │        │  - Window management     │   │
│   └────────┬────────┘        └────────────┬─────────────┘   │
│            │                              │                 │
│            └──────────┬───────────────────┘                 │
│                       │                                     │
│            ┌──────────▼──────────┐                          │
│            │  gpucontext         │                          │
│            │  (Shared Interfaces)│                          │
│            │                     │                          │
│            │  - TextureDrawer    │                          │
│            │  - TextureCreator   │                          │
│            │  - DeviceProvider   │                          │
│            │  - EventSource      │                          │
│            └─────────────────────┘                          │
│                                                             │
└─────────────────────────────────────────────────────────────┘

The key insight: shared interfaces enable integration without coupling.

The TextureDrawer Interface

At the heart of our integration is gpucontext.TextureDrawer:

// gpucontext/texture.go

// TextureDrawer provides texture drawing capabilities for 2D rendering.
// This interface enables packages like ggcanvas to draw textures without
// depending directly on gogpu, following the Dependency Inversion Principle.
type TextureDrawer interface {
    // DrawTexture draws a texture at the specified position.
    DrawTexture(tex Texture, x, y float32) error

    // TextureCreator returns the texture creator associated with this drawer.
    TextureCreator() TextureCreator
}

// TextureCreator provides texture creation from raw pixel data.
type TextureCreator interface {
    // NewTextureFromRGBA creates a texture from RGBA pixel data.
    NewTextureFromRGBA(width, height int, data []byte) (Texture, error)
}

This interface follows the Dependency Inversion Principle:

gg depends on abstractions (gpucontext.TextureDrawer)
gogpu implements abstractions (Context.AsTextureDrawer())
Neither depends on the other

Working Example

Here's a simplified example based on our codebase (see full version at examples/gg_integration/main.go):

package main

import (
    "log"
    "math"

    "github.com/gogpu/gg"
    "github.com/gogpu/gg/integration/ggcanvas"
    "github.com/gogpu/gogpu"
    "github.com/gogpu/gogpu/gmath"
)

func main() {
    // Create GPU-accelerated window
    app := gogpu.NewApp(gogpu.DefaultConfig().
        WithTitle("GoGPU + gg Integration via ggcanvas").
        WithSize(800, 600))

    var canvas *ggcanvas.Canvas

    app.OnDraw(func(dc *gogpu.Context) {
        w, h := dc.Width(), dc.Height()
        dc.ClearColor(gmath.Hex(0x1a1a2e))

        // Lazy initialization with GPU context
        if canvas == nil {
            var err error
            canvas, err = ggcanvas.New(app.GPUContextProvider(), w, h)
            if err != nil {
                log.Fatalf("Failed to create canvas: %v", err)
            }
        }

        // Draw 2D graphics using familiar gg API
        cc := canvas.Context()
        cc.SetRGB(1, 0.5, 0)
        cc.DrawCircle(400, 300, 100)
        cc.Fill()

        // Render to GPU window — one line!
        canvas.RenderTo(dc.AsTextureDrawer())
    })

    // Handle window resize
    app.EventSource().OnResize(func(w, h int) {
        if canvas != nil {
            canvas.Resize(w, h)
        }
    })

    app.Run()
}

Key points:

ggcanvas.New(provider, w, h) — Creates a canvas with GPU context
canvas.Context() — Returns standard *gg.Context for 2D drawing
canvas.RenderTo(dc.AsTextureDrawer()) — Uploads to GPU and draws

Note: The full example includes animated HSV-colored circles, debug PNG export, backend logging, and comprehensive error handling.

The ggcanvas package handles all complexity:

CPU→GPU texture upload
Dirty tracking (only upload when changed)
Format conversion (RGBA→GPU texture)
Resource cleanup

Under the Hood

Data Flow

User draws via gg API
         │
         ▼
gg.Context accumulates draw commands
         │
         ▼
canvas.RenderTo(dc) called
         │
         ├─── cc.RenderToPixmap(pixmap)    [CPU rasterization]
         │
         ├─── texture.UpdateData(pixmap.Pix) [CPU→GPU upload]
         │
         └─── dc.DrawTexture(texture, 0, 0)  [GPU render]
         │
         ▼
Window surface (Vulkan/Metal/DX12)

gogpu Implementation

gogpu.Context implements the interface via an adapter:

// context_texture.go

// AsTextureDrawer returns an adapter implementing gpucontext.TextureDrawer.
func (c *Context) AsTextureDrawer() gpucontext.TextureDrawer {
    return &contextTextureDrawer{
        ctx:     c,
        creator: &rendererTextureCreator{renderer: c.renderer},
    }
}

This follows the Adapter Pattern — exposing existing functionality through a new interface without modifying the original type.

Platform Support

This integration works across all gogpu-supported platforms:

Platform	Backend	Status
Windows	Vulkan, DX12	Production
Linux (X11)	Vulkan	Production
Linux (Wayland)	Vulkan	Production
macOS	Metal	Production

All platforms use Pure Go FFI — no CGO required.

Performance Characteristics

Operation	Cost	Notes
`canvas.Context()`	O(1)	Returns existing context
2D drawing	CPU	Rasterization in gg
`RenderTo()`	O(pixels)	CPU→GPU texture upload
GPU draw	O(1)	Single textured quad

For static or infrequently changing UI, the CPU→GPU upload happens only when content changes (dirty tracking).

Roadmap: gogpu/ui

This integration is the foundation for gogpu/ui, our upcoming GUI toolkit:

// Future gogpu/ui API (planned)

func main() {
    app := gogpu.NewApp(gogpu.DefaultConfig().
        WithTitle("gogpu/ui Demo").
        WithSize(1280, 720))

    // Declarative UI with reactive state
    count := signals.New(0)

    root := layout.VStack(
        widgets.Text("Counter Demo").FontSize(24),
        layout.HStack(
            widgets.Button("-").OnClick(func() {
                count.Set(count.Get() - 1)
            }),
            widgets.Text(signals.Computed(func() string {
                return fmt.Sprintf("Count: %d", count.Get())
            })),
            widgets.Button("+").OnClick(func() {
                count.Set(count.Get() + 1)
            }),
        ).Gap(8),
    ).Padding(24).Gap(16)

    ui := ui.NewRenderer(app.GPUContextProvider())
    ui.SetRoot(root)

    app.OnDraw(func(dc *gogpu.Context) {
        dc.ClearColor(theme.Background)
        ui.RenderTo(dc.AsTextureDrawer())
    })

    // Event forwarding
    app.EventSource().OnMouse(ui.HandleMouse)
    app.EventSource().OnKeyboard(ui.HandleKeyboard)
    app.EventSource().OnTouch(ui.HandleTouch)

    app.Run()
}

Planned Features

Phase	Version	Features
Phase 1	v0.1.0	Core widgets, Flexbox layout, Events
Phase 2	v0.2.0	Material 3 theme, Animation
Phase 3	v0.3.0	Virtualization (100K+ items), A11y
Phase 4	v1.0.0	IDE docking, Multiple themes

Design Decisions

Based on our research of 7 Rust UI frameworks:

Decision	Choice	Rationale
Reactivity	Fine-grained signals	O(affected) updates only
Styling	Tailwind-style builders	Type-safe, IDE autocomplete
Layout	Flexbox + incremental	Industry standard
Accessibility	AccessKit schema	Cross-platform standard

Today's Release

Package	Version	Highlights
gpucontext	v0.4.0	`TextureDrawer`, `TouchEventSource`
wgpu	v0.12.0	BufferRowLength fix
naga	v0.9.0	Shader compiler improvements
gg	v0.22.1	Integration + LineJoinRound fix
gogpu	v0.14.0	`AsTextureDrawer()` implementation

Getting Started

go get github.com/gogpu/gogpu@v0.14.0
go get github.com/gogpu/gg@v0.22.1

Run the example:

git clone https://github.com/gogpu/gogpu
cd gogpu
go run examples/gg_integration/main.go

Resources

Resource	Link
GitHub Organization	github.com/gogpu
RFC Discussion	gogpu/ui RFC
gpucontext Article	Cross-Package GPU Integration
gg Architecture	Enterprise 2D Graphics Library
Project History	From Idea to 100K Lines

We Need Your Help

Building an enterprise-grade graphics ecosystem is a massive undertaking. We're a small team, and we need the community's help:

Testing & Bug Reports

Platform testing — macOS, Linux (X11/Wayland), different GPUs
Edge cases — unusual window sizes, high DPI, multi-monitor setups
Performance issues — stuttering, memory leaks, high CPU usage

Validation & Feedback

API review — Does the API feel Go-idiomatic? What's confusing?
Architecture validation — Are we making the right design decisions?
Real-world usage — Try it in your projects and report pain points

What We're Especially Looking For

Area	What We Need
Rendering bugs	Incorrect colors, missing pixels, artifacts
Performance bottlenecks	Profile and identify slow paths
API ergonomics	Confusing names, missing methods, rough edges
Platform issues	Windows/macOS/Linux-specific problems
Integration feedback	How well does it fit your use case?

How to Contribute

Star the repos — Helps visibility
File issues — Even small bugs matter
Join discussions — github.com/orgs/gogpu/discussions
Try the examples — Report what breaks

Every bug report, performance profile, and piece of feedback helps us build the graphics library Go deserves.

Conclusion

With unified 2D/3D integration, the GoGPU ecosystem is ready for the next step: a production-grade GUI toolkit for Go.

Our approach:

Pure Go — No CGO, easy cross-compilation
Interface-based — Clean architecture, testable
Enterprise patterns — Proven in large-scale systems

We're building the GUI toolkit Go deserves. Join the discussion at github.com/orgs/gogpu/discussions/18.

The GoGPU Team

Follow the project:

GitHub: github.com/gogpu
Twitter: @gogpu_go

GoGPU Enterprise Architecture: Cross-Package GPU Integration with gpucontext

Andrey Kolkov — Tue, 27 Jan 2026 16:36:53 +0000

Release (January 27, 2026): gogpu v0.12.0 + gg v0.21.0 — Enterprise architecture with gpucontext integration. Shared GPU interfaces enable database/sql-like dependency injection across the ecosystem.

The Problem: Circular Dependencies

As the GoGPU ecosystem grew to 300K lines of Pure Go, we hit a classic enterprise problem:

gogpu/gogpu (windowing, GPU init)
      ↓ depends on
gogpu/gg (2D graphics)
      ↓ depends on
gogpu/wgpu (WebGPU implementation)
      ↓ depends on
gogpu/naga (shader compiler)

The challenge: How can gg receive a GPU device from gogpu without creating circular dependencies? And how will gogpu/ui receive both GPU context AND input events?

The answer: Shared interfaces in a zero-dependency package.

Introducing gpucontext

gogpu/gpucontext is a new package with zero dependencies that defines shared GPU infrastructure:

// gpucontext v0.2.0 — Zero dependencies!
import "github.com/gogpu/gpucontext"

Core Interfaces

Interface	Purpose	Implemented By
`DeviceProvider`	GPU device + queue access	gogpu.App
`EventSource`	Input events for UI	gogpu.App
`IMEController`	IME positioning for CJK input	gogpu.App (future)

This follows the wgpu-types pattern from Rust — separating type definitions from implementation.

DeviceProvider: The database/sql Pattern

Just like Go's database/sql lets you swap MySQL for Postgres without changing your code, gpucontext.DeviceProvider lets libraries receive GPU resources without knowing the source:

// gpucontext/device_provider.go
type DeviceProvider interface {
    Device() Device           // Create GPU resources
    Queue() Queue             // Submit commands
    SurfaceFormat() TextureFormat  // Match surface format
    Adapter() Adapter         // GPU capabilities (optional)
}

gogpu Implements DeviceProvider

In gogpu v0.12.0, the App now provides GPU context to external libraries:

package main

import (
    "github.com/gogpu/gogpu"
    "github.com/gogpu/gpucontext"
)

func main() {
    app := gogpu.NewApp(gogpu.DefaultConfig().
        WithTitle("gpucontext Demo").
        WithSize(800, 600))

    app.OnDraw(func(dc *gogpu.Context) {
        // Get DeviceProvider for external libraries
        provider := app.GPUContextProvider()

        // All non-nil — GPU is ready!
        device := provider.Device()   // gpucontext.Device
        queue := provider.Queue()     // gpucontext.Queue
        adapter := provider.Adapter() // gpucontext.Adapter
        format := provider.SurfaceFormat() // gpucontext.TextureFormat

        // Pass to gg, ui, or any library that accepts DeviceProvider
    })

    app.Run()
}

Key insight: The library receiving DeviceProvider doesn't need to know it came from gogpu. It could come from born-ml/born for ML compute, or a future WebAssembly host.

EventSource: Input Events for UI

Building a GUI toolkit requires more than GPU access — you need input events. The EventSource interface provides platform-independent input delivery:

// gpucontext/events.go
type EventSource interface {
    // Keyboard
    OnKeyPress(func(key Key, mods Modifiers))
    OnKeyRelease(func(key Key, mods Modifiers))
    OnTextInput(func(text string))

    // Mouse
    OnMouseMove(func(x, y float64))
    OnMousePress(func(button MouseButton, x, y float64))
    OnMouseRelease(func(button MouseButton, x, y float64))
    OnScroll(func(dx, dy float64))

    // Window
    OnResize(func(width, height int))
    OnFocus(func(focused bool))

    // IME (Chinese/Japanese/Korean input)
    OnIMECompositionStart(fn func())
    OnIMECompositionUpdate(fn func(state IMEState))
    OnIMECompositionEnd(fn func(committed string))
}

Full IME Support for CJK Input

Enterprise applications must support international users. The IMEState struct provides everything needed for inline composition rendering:

type IMEState struct {
    Composing       bool   // Currently composing?
    CompositionText string // e.g., "nihon" → "日本"
    CursorPos       int    // Cursor within composition
    SelectionStart  int    // Selection range
    SelectionEnd    int
}

Using EventSource

app := gogpu.NewApp(gogpu.DefaultConfig())

// Get event source
events := app.EventSource()

// Register callbacks
events.OnKeyPress(func(key gpucontext.Key, mods gpucontext.Modifiers) {
    if key == gpucontext.KeyEscape {
        app.Quit()
    }
})

events.OnMousePress(func(btn gpucontext.MouseButton, x, y float64) {
    fmt.Printf("Click at (%.0f, %.0f)\n", x, y)
})

events.OnIMECompositionUpdate(func(state gpucontext.IMEState) {
    // Render composition text inline
    renderIMEPreview(state.CompositionText, state.CursorPos)
})

app.Run()

gg Enterprise Architecture

gg v0.21.0 introduces two new packages that leverage gpucontext:

core/ — CPU Rendering Primitives

Independent of GPU, contains pure algorithms:

gg/core/
├── fixed.go          # Fixed-point math (FDot6, FDot16)
├── edge.go           # Line/curve edges
├── edge_builder.go   # Path → edges conversion
├── analytic_filler.go # Anti-aliased rendering
└── alpha_runs.go     # RLE coverage storage

Key principle: CPU rendering code is separate from GPU code, following Skia/Vello architecture patterns.

render/ — GPU Integration Layer

Bridges gg to host applications via gpucontext:

// gg/render/device.go
type DeviceHandle = gpucontext.DeviceProvider

// gg/render/gpu_renderer.go
// gg receives device from host, doesn't create its own
func NewGPURenderer(handle DeviceHandle) (*GPURenderer, error) {
    if handle == nil {
        return nil, errors.New("render: nil device handle")
    }
    return &GPURenderer{
        handle:           handle,
        softwareFallback: NewSoftwareRenderer(),
    }, nil
}

Architecture:

              User Application
                    │
     ┌──────────────┼──────────────┐
     │              │              │
     ▼              ▼              ▼
  gogpu.App    gg.Context     gg.Scene
  (windowing)  (immediate)    (retained)
     │              │              │
     └──────────────┼──────────────┘
                    │
                    ▼
            gg/render package
     ┌──────────────┼──────────────┐
     │              │              │
     ▼              ▼              ▼
 DeviceHandle  RenderTarget    Renderer
 (GPU access)    (output)     (execution)
                    │
                    ▼
            gg/core package
          (CPU rasterization)

Building gogpu/ui: The Path Forward

With gpucontext providing GPU access AND input events, gogpu/ui can now be built as a pure consumer:

// Future gogpu/ui integration
package main

import (
    "github.com/gogpu/gogpu"
    "github.com/gogpu/ui"
)

func main() {
    app := gogpu.NewApp(gogpu.DefaultConfig())

    // ui receives BOTH GPU context AND events
    uiRoot := ui.New(
        app.GPUContextProvider(), // GPU for rendering
        app.EventSource(),        // Input for interaction
    )

    uiRoot.Add(
        ui.Box(
            ui.Text("Hello, GoGPU!").Font(ui.Title),
            ui.Button("Click Me").OnClick(func() {
                fmt.Println("Clicked!")
            }),
        ).Padding(16).Gap(12),
    )

    app.OnDraw(func(dc *gogpu.Context) {
        uiRoot.Render()
    })

    app.Run()
}

UI Architecture Goals

Feature	Implementation
Signals-based reactivity	Fine-grained updates, O(affected) not O(n)
Tailwind-style API	Type-safe styling, AI-friendly
Enterprise features	Docking, virtualization, accessibility
Cross-platform	Desktop (gogpu), Web (WASM), Mobile (WebView)

The Ecosystem Today

Project	Version	LOC	Description
gogpu/gg	v0.21.0	~143K	2D graphics + core/render packages
gogpu/wgpu	v0.10.2	~95K	Pure Go WebGPU
gogpu/naga	v0.8.4	~33K	Shader compiler
gogpu/gogpu	v0.12.0	~29K	GPU framework + gpucontext integration
gogpu/gpucontext	v0.2.0	~1K	Shared interfaces (zero deps)
gogpu/ui	—	—	GUI toolkit (in design)

Total: ~300K lines of Pure Go. No CGO. No Rust required. Just go build.

Dependency Graph

┌─────────────────────────────────────────────────────────────┐
│                    Your Application                         │
├─────────────────────────────────────────────────────────────┤
│    gogpu/ui (future)    │   born-ml/born   │   Your App     │
├─────────────────────────────────────────────────────────────┤
│                  gogpu/gg (2D Graphics)                     │
│              core/ (CPU)    render/ (GPU integration)       │
├─────────────────────────────────────────────────────────────┤
│              gogpu/gogpu (Graphics Framework)               │
│         Windowing, Input, GPU Init, DeviceProvider          │
├─────────────────────────────────────────────────────────────┤
│    gogpu/gpucontext (Shared Interfaces — ZERO DEPS)         │
│      DeviceProvider, EventSource, IME, WebGPU types         │
├─────────────────────────────────────────────────────────────┤
│                  gogpu/wgpu (Pure Go WebGPU)                │
├─────────────────────────────────────────────────────────────┤
│            Vulkan  │  Metal  │  DX12  │  GLES               │
└─────────────────────────────────────────────────────────────┘

Try It

# Get the latest versions
go get github.com/gogpu/gogpu@v0.12.0
go get github.com/gogpu/gg@v0.21.0
go get github.com/gogpu/gpucontext@v0.2.0

Complete Example

package main

import (
    "fmt"

    "github.com/gogpu/gogpu"
    "github.com/gogpu/gogpu/gmath"
    "github.com/gogpu/gpucontext"
)

func main() {
    app := gogpu.NewApp(gogpu.DefaultConfig().
        WithTitle("gpucontext Integration Demo").
        WithSize(800, 600))

    // Setup event handling
    events := app.EventSource()
    events.OnKeyPress(func(key gpucontext.Key, mods gpucontext.Modifiers) {
        fmt.Printf("Key: %d, Mods: %d\n", key, mods)
    })

    events.OnMousePress(func(btn gpucontext.MouseButton, x, y float64) {
        fmt.Printf("Click at (%.0f, %.0f)\n", x, y)
    })

    app.OnDraw(func(dc *gogpu.Context) {
        // Verify DeviceProvider
        provider := app.GPUContextProvider()
        if provider != nil && provider.Device() != nil {
            // GPU ready — can pass to gg or other libraries
        }

        // Draw demo triangle (red) on CornflowerBlue background
        dc.DrawTriangleColor(gmath.CornflowerBlue)
    })

    app.Run()
}

What's Next

Q1 2026: Stabilization

Comprehensive benchmarks across all backends
Memory optimization and GPU submission batching
Documentation and tutorials

Q2 2026: gogpu/ui Foundation

Widget system with signals-based reactivity
Layout engine (flexbox-inspired)
Theme system with accessibility support

Q3 2026: gogpu/ui Enterprise Features

Docking and workspace management
Virtualized lists for large datasets
AccessKit integration for screen readers

Join the Discussion

We're making architectural decisions right now. Your input shapes the future of Go graphics:

GitHub Discussions
gogpu/ui Repository — Star and watch for updates

Links

gogpu/gogpu: https://github.com/gogpu/gogpu/releases/tag/v0.12.0
gogpu/gg: https://github.com/gogpu/gg/releases/tag/v0.21.0
gogpu/gpucontext: https://github.com/gogpu/gpucontext
Organization: https://github.com/gogpu

Enterprise-grade GPU integration. Pure Go. Zero CGO. Zero circular dependencies.

go get github.com/gogpu/gogpu@v0.12.0

Star the repos if you find them useful!

Part of the GoGPU Journey series:

GoGPU: A Pure Go Graphics Library
From Idea to 100K Lines in Two Weeks
GPU Compute Shaders in Pure Go
Enterprise GPU Backend v0.20.0
Enterprise Architecture v0.21.0 ← You are here

gogpu/gg: Enterprise 2D Graphics Library in Pure Go

Andrey Kolkov — Thu, 22 Jan 2026 22:05:00 +0000

Latest: v0.20.0 — Enterprise-grade GPU backend, color emoji, anti-aliased rendering. Part of the 280K+ LOC Pure Go graphics ecosystem.

Previous: GPU Compute Shaders in Pure Go (v0.15.0)

What is gogpu/gg?

gg is a production-grade 2D graphics library for Go, designed to power:

IDEs — Syntax highlighting, code rendering, UI components
Browsers — Canvas-like rendering, WebGPU acceleration
Professional apps — Vector graphics, data visualization, games

Key differentiator: Pure Go. No CGO. No external dependencies. Just go build.

go get github.com/gogpu/gg@v0.20.0

Feature Overview

Category	Capabilities
Drawing	Rectangles, circles, ellipses, arcs, lines, polygons, stars, bezier curves
Paths	MoveTo, LineTo, QuadraticTo, CubicTo, ArcTo, Close + fluent PathBuilder
Text	TrueType fonts, MSDF rendering, bidirectional text, color emoji
Images	PNG/JPEG I/O, 7 pixel formats, affine transforms, mipmaps
Compositing	29 blend modes (Porter-Duff, Advanced, HSL), layer isolation
Rendering	Software (CPU), GPU (Vulkan/Metal/DX12), hybrid auto-selection
Performance	SIMD optimization, parallel tile rendering, LRU caching

Quick Start

Hello World

package main

import "github.com/gogpu/gg"

func main() {
    dc := gg.NewContext(512, 512)
    defer dc.Close()

    // Clear background
    dc.ClearWithColor(gg.White)

    // Draw anti-aliased circle
    dc.SetHexColor("#3498db")
    dc.DrawCircle(256, 256, 100)
    dc.Fill()

    // Draw stroked rectangle
    dc.SetHexColor("#e74c3c")
    dc.SetLineWidth(3)
    dc.DrawRectangle(156, 156, 200, 200)
    dc.Stroke()

    dc.SavePNG("output.png")
}

Text Rendering

package main

import (
    "github.com/gogpu/gg"
    "github.com/gogpu/gg/text"
)

func main() {
    dc := gg.NewContext(800, 200)
    defer dc.Close()

    dc.ClearWithColor(gg.White)

    // Load font
    source, _ := text.NewFontSourceFromFile("Roboto-Regular.ttf")
    defer source.Close()

    // Render text
    dc.SetFont(source.Face(48))
    dc.SetColor(gg.Black)
    dc.DrawString("Hello, GoGPU!", 50, 100)

    // Centered text
    dc.DrawStringAnchored("Centered Text", 400, 150, 0.5, 0.5)

    dc.SavePNG("text.png")
}

Gradients

dc := gg.NewContext(400, 400)
defer dc.Close()

// Linear gradient
grad := gg.NewLinearGradientBrush(0, 0, 400, 400)
grad.AddColorStop(0, gg.Hex("#ff6b6b"))
grad.AddColorStop(0.5, gg.Hex("#4ecdc4"))
grad.AddColorStop(1, gg.Hex("#45b7d1"))

dc.SetFillBrush(grad)
dc.DrawRectangle(0, 0, 400, 400)
dc.Fill()

dc.SavePNG("gradient.png")

Transforms

dc := gg.NewContext(400, 400)
defer dc.Close()

dc.ClearWithColor(gg.White)

// Save state, transform, draw, restore
dc.Push()
dc.Translate(200, 200)
dc.Rotate(math.Pi / 4)  // 45 degrees
dc.Scale(1.5, 1.5)

dc.SetHexColor("#9b59b6")
dc.DrawRectangle(-50, -50, 100, 100)
dc.Fill()

dc.Pop()  // Restore original state

dc.SavePNG("transform.png")

Canvas API

gg provides a familiar Canvas-like API inspired by HTML5 Canvas and Cairo:

Drawing Primitives

// Rectangles
dc.DrawRectangle(x, y, width, height)
dc.DrawRoundedRectangle(x, y, w, h, radius)

// Circles and ellipses
dc.DrawCircle(cx, cy, radius)
dc.DrawEllipse(cx, cy, rx, ry)
dc.DrawArc(cx, cy, r, startAngle, endAngle)

// Lines
dc.DrawLine(x1, y1, x2, y2)
dc.MoveTo(x, y)
dc.LineTo(x, y)

// Curves
dc.QuadraticTo(cx, cy, x, y)
dc.CubicTo(cx1, cy1, cx2, cy2, x, y)

// Polygons
dc.DrawPolygon(points...)
dc.DrawRegularPolygon(n, cx, cy, r, rotation)
dc.DrawStar(cx, cy, outerR, innerR, points)

Styles

// Colors
dc.SetColor(gg.Red)
dc.SetRGB(1.0, 0.5, 0.0)
dc.SetRGBA(1.0, 0.5, 0.0, 0.8)
dc.SetHexColor("#3498db")

// Strokes
dc.SetLineWidth(2.0)
dc.SetLineCap(gg.LineCapRound)    // Butt, Round, Square
dc.SetLineJoin(gg.LineJoinMiter)  // Miter, Round, Bevel
dc.SetDash(5, 3)  // Pattern: 5px on, 3px off

// Fill and stroke
dc.Fill()
dc.Stroke()
dc.FillPreserve()   // Fill but keep path
dc.StrokePreserve() // Stroke but keep path

Clipping

// Clip to circle
dc.DrawCircle(200, 200, 100)
dc.Clip()

// All subsequent drawing is clipped
dc.DrawImage(img, 0, 0)

dc.ResetClip()

Fluent PathBuilder

Build complex paths with method chaining for use with Scene Graph:

import (
    "github.com/gogpu/gg"
    "github.com/gogpu/gg/scene"
)

// Build path with fluent API
path := gg.BuildPath().
    MoveTo(100, 100).
    LineTo(200, 100).
    QuadTo(250, 150, 200, 200).
    CubicTo(150, 250, 100, 250, 50, 200).
    Close().
    Circle(300, 150, 50).
    Star(400, 150, 40, 20, 5).
    RoundRect(50, 250, 100, 80, 10).
    Build()

// Use with scene graph
s := scene.NewScene()
s.Fill(scene.FillNonZero, scene.IdentityAffine(),
    scene.SolidBrush(gg.Hex("#2ecc71")), scene.NewPathShape(path))

Available shape methods:

MoveTo, LineTo, QuadTo, CubicTo, Close
Circle, Ellipse
Rect, RoundRect
Polygon, Star

Text Rendering

Font Loading

// From file
source, err := text.NewFontSourceFromFile("font.ttf")

// From bytes
source, err := text.NewFontSourceFromBytes(fontBytes)

// Create face at specific size
face := source.Face(24)  // 24pt
defer source.Close()

Multi-Face (Font Fallback)

// Primary font + emoji fallback
mainFont, _ := text.NewFontSourceFromFile("Roboto.ttf")
emojiFont, _ := text.NewFontSourceFromFile("NotoColorEmoji.ttf")

multiFace, _ := text.NewMultiFace(
    mainFont.Face(16),
    text.NewFilteredFace(emojiFont.Face(16), text.RangeEmoji),
)

dc.SetFont(multiFace)
dc.DrawString("Hello World! 🎉🚀", 50, 100)

Text Layout with Wrapping

opts := text.LayoutOptions{
    MaxWidth:    400,
    WrapMode:    text.WrapWordChar,  // Word-first, char fallback
    Alignment:   text.AlignCenter,
    LineSpacing: 1.2,
}

layout := text.LayoutText(longText, face, 16, opts)

// Render using glyph renderer
renderer := text.NewGlyphRenderer()
outlines := renderer.RenderLayout(layout)

// Or access line metrics directly
for _, line := range layout.Lines {
    // line.Y is the baseline Y position
    // line.Width, line.Ascent, line.Descent available
    // line.Glyphs contains positioned glyphs
}

Color Emoji

gg supports both bitmap (CBDT/CBLC) and vector (COLR/CPAL) color emoji:

// Extract bitmap emoji (Noto Color Emoji)
extractor, _ := emoji.NewCBDTExtractor(cbdtData, cblcData)
glyph, _ := extractor.GetGlyph(glyphID, ppem)
img, _ := png.Decode(bytes.NewReader(glyph.Data))

// Parse vector emoji layers (Segoe UI Emoji)
parser, _ := emoji.NewCOLRParser(colrData, cpalData)
glyph, _ := parser.GetGlyph(glyphID, paletteIndex)
for _, layer := range glyph.Layers {
    // Render each layer with layer.Color
}

Layer Compositing

29 Blend Modes

Porter-Duff: Clear, Src, Dst, SrcOver, DstOver, SrcIn, DstIn, SrcOut, DstOut, SrcAtop, DstAtop, Xor

Advanced: Multiply, Screen, Overlay, Darken, Lighten, ColorDodge, ColorBurn, HardLight, SoftLight, Difference, Exclusion

HSL: Hue, Saturation, Color, Luminosity

dc.PushLayer(gg.BlendMultiply, 0.8)  // Blend mode + opacity

dc.SetHexColor("#e74c3c")
dc.DrawCircle(150, 200, 100)
dc.Fill()

dc.SetHexColor("#3498db")
dc.DrawCircle(250, 200, 100)
dc.Fill()

dc.PopLayer()  // Composite layer

Alpha Masks

// Create mask from shape
dc.DrawCircle(200, 200, 100)
dc.Fill()
mask := dc.AsMask()

// Apply mask to new context
dc2 := gg.NewContext(400, 400)
dc2.SetMask(mask)
dc2.DrawImage(backgroundImage, 0, 0)  // Only visible through mask

Scene Graph (Retained Mode)

For complex, frequently-updated scenes:

import (
    "github.com/gogpu/gg"
    "github.com/gogpu/gg/scene"
)

s := scene.NewScene()

// Build scene graph with layer compositing
s.PushLayer(scene.BlendNormal, 1.0, nil)  // blend, alpha, clip

s.Fill(scene.FillNonZero, scene.IdentityAffine(),
    scene.SolidBrush(gg.Red), scene.NewCircleShape(150, 200, 100))

s.Fill(scene.FillNonZero, scene.IdentityAffine(),
    scene.SolidBrush(gg.Blue), scene.NewCircleShape(250, 200, 100))

s.PopLayer()

// Render to pixmap
renderer := scene.NewRenderer(width, height)
renderer.Render(s)

Benefits:

GPU-optimized command batching
Efficient dirty region tracking
Parallel tile rendering

Backend Architecture

gg supports three rendering backends:

Backend	Package	Description	Use Case
Native	`backend/native/`	Pure Go via gogpu/wgpu	Default, zero deps
Rust	`backend/rust/`	wgpu-native FFI	Max performance
Software	`backend/software/`	CPU rasterizer	Fallback

import "github.com/gogpu/gg/backend"

// Auto-select best available
b := backend.Default()

// Explicit selection
b := backend.Get(backend.BackendNative)
b := backend.Get(backend.BackendRust)     // Requires -tags rust
b := backend.Get(backend.BackendSoftware)

GPU Backend Features (v0.20.0)

Command Encoder — State machine for GPU command recording
Texture Management — Lazy views with sync.Once
Buffer Mapping — Async with device polling
Pipeline Cache — FNV-1a descriptor hashing
Compute Shaders — WGSL shaders for path rasterization

Performance

Benchmarks

Operation	Time	Notes
sRGB → Linear	0.16ns	260x faster than math.Pow
LayerCache.Get	90ns	Thread-safe LRU
DirtyRegion.Mark	10.9ns	Lock-free atomic
MSDF lookup	<10ns	Zero-allocation
Path iteration	438ns	iter.Seq, 0 allocs

Optimizations

SIMD — Vectorized color operations
Parallel rendering — Tile-based multi-threaded rasterization
LRU caching — Glyph cache, texture cache, layer cache
GPU compute — Path flattening, tile binning, coverage calculation

Anti-Aliased Rendering

v0.19.0 introduced professional-grade anti-aliasing using the tiny-skia algorithm:

// AA is enabled by default
dc.Fill()

// Disable AA for performance
dc.FillNoAA()

Implementation:

4x supersampling with coverage accumulation
AlphaRuns — RLE-encoded sparse alpha buffer
SIMD batch blending for 16 pixels at a time
Same algorithm as Chrome, Android, Flutter

The GoGPU Ecosystem

gg is part of a complete Pure Go graphics stack:

Project	Version	LOC	Description
gogpu/gg	v0.20.0	~122K	2D graphics (this library)
gogpu/wgpu	v0.10.1	~95K	Pure Go WebGPU
gogpu/naga	v0.8.4	~33K	WGSL shader compiler
gogpu/gogpu	v0.11.1	~28K	Graphics framework

Total: ~280K lines of Pure Go.

Design Principles

Pure Go — No CGO, easy cross-compilation, single binary
GPU-First — Designed for GPU acceleration from day one
Production-Ready — Enterprise-grade error handling, logging
API Stability — Semantic versioning, deprecation policy

Inspired By

vello (Rust) — GPU compute shaders, sparse strips
tiny-skia (Rust) — Anti-aliasing, stroke expansion
kurbo (Rust) — Path algorithms
peniko (Rust) — Brush/paint system
skrifa/swash (Rust) — Font parsing, color emoji

Installation

go get github.com/gogpu/gg@v0.20.0

Requirements: Go 1.25+

Build Tags

# Default: Native + Software backends
go build ./...

# With Rust backend (requires wgpu-native)
go build -tags rust ./...

# Software only
go build -tags nogpu ./...

Examples

Complete Examples

examples/basic/ — Basic shapes and colors
examples/text/ — Text rendering
examples/color_emoji/ — Color emoji extraction
examples/gpu/ — GPU backend usage
examples/scene/ — Scene graph

Run Examples

cd examples/basic
go run main.go

Documentation

README — Quick start
ARCHITECTURE.md — System design
ROADMAP.md — Development milestones
pkg.go.dev — API reference

Links

Repository: https://github.com/gogpu/gg
Release v0.20.0: https://github.com/gogpu/gg/releases/tag/v0.20.0
GoGPU Organization: https://github.com/gogpu
Discussions: https://github.com/orgs/gogpu/discussions

122K lines. Pure Go. Production-ready 2D graphics.

go get github.com/gogpu/gg@v0.20.0

Star the repo if you find it useful!

Part of the GoGPU Journey series