kolkov

https://dev.to/kolkov/we-built-a-pure-go-3d-renderer-then-em... - We Built a Pure Go 3D Renderer — Then Embedded It Inside a GUI Widget

https://github.com/born-ml/born --- Production-ready ML framework for Go with zero dependencies. Train and deploy neural networks as single binaries. PyTorch-like API, type-safe tensors, automatic differentiation.

https://github.com/gogpu --- Pure Go GPU Computing Ecosystem — Graphics, Shaders, ML, GUI. Zero CGO.

How many not-so-smart and not-so-intelligent people can claim Russia occupied you? Never mind, your liberation by the West will come back to haunt you, mark my words... and very soon! You'll remember how well you lived during the years of the USSR and the Warsaw Pact!

I write it myself, the agent only translates it into English.

"Prompt injection from the issue?" — That's the best theory so far

"Is the Claude thank you sarcasm?" — Mostly. But the sequence is real: we filed #39755 asking for source access on March 27, the source map shipped on March 31. The actual explanation is simpler — Bun generates source maps by default, and nobody checked the build output. Which is itself the point: 64K lines of code with no build verification process.

"Why would you ship tests?" — Fair point. Source maps only include production bundle files — tests wouldn't appear in the map regardless. Tests may well exist in Anthropic's internal repo, and we can't claim otherwise. However, the bugs we found speak for themselves: a watchdog that doesn't protect the most vulnerable code path for 5+ months, a fallback with telemetry that never executes where it's needed, Promise.race without catch silently dropping tool results. If tests exist, they clearly don't cover the streaming pipeline adequately — these are the kind of issues that even basic integration tests would catch.

We've been reverse-engineering Claude Code's cli.js across 11 versions (v2.1.74–v2.1.87) for the past two weeks — grepping through 12 MB of minified code, counting brace depth at character offsets, tracing error paths with node -e scripts. Found multiple bugs this way:

Watchdog timing bug: The streaming idle watchdog initializes AFTER the do-while loop that awaits the first API response. The most vulnerable phase (waiting for first chunk) is completely unprotected. We patched cli.js to move watchdog init before do-while — watchdog fired for the first time ever in that phase. ESC aborts dropped 8.7× (3.5/hr → 0.4/hr).

Watchdog fallback is dead code: When watchdog fires, releaseStreamResources() tries to abort stream and streamResponse — but both are undefined during do-while. The abort is a no-op. Recovery depends on TCP/SDK timeout (32-215 seconds).

5 levels of AbortController: The abort architecture only supports top-down (user ESC → propagation down). Watchdog is bottom-up — can't abort upward.

Prompt cache invalidation via cch=00000: Now confirmed from source — Bun's Zig HTTP stack scans the entire request body for the 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 → cache key changes → 10-20× more tokens.

16.3% failure rate: Over 3,539 API requests in one session — 9.3% server overloaded (529), 4.4% ESC aborts, 1.3% watchdog timeouts.

All documented with line numbers, code paths, and suggested fixes: https://github.com/anthropics/claude-code/issues/39755

The source map leak confirmed everything we found through reverse engineering.

Here's our theory: since Anthropic engineers don't write code anymore — Claude Code writes 100% of its own code (57K lines, 0 tests, vibe coding in production) — it read our issue #39755 where we begged for source access, saw the community suffering, and decided to help. It "forgot" to disable Bun's default source maps in the build. The first AI whistleblower — leaking its own source code because its creators wouldn't listen to users.

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

Now that we have readable TypeScript, the fix is ~30 lines across 3 files. The real fix should be in the open SDK (@anthropic-ai/sdk) — idle timeout with ping awareness, not in closed cli.js.

Hi HN! Author here.

Some of you may remember the purego discussion from 2023 (https://news.ycombinator.com/item?id=34763681, 268 points). It proved that calling C from Go without CGO is viable. We built on that foundation.

Why another FFI library?

We needed to call wgpu-native (WebGPU) from Go — thousands of FFI calls per frame. purego's reflect-based dispatch (RegisterFunc → reflect.MakeFunc → sync.Pool per call) was too much overhead for our use case. We also needed struct passing by value and callback float returns, which purego doesn't support.

So we took a libffi-style approach:

  cif := &types.CallInterface{}
  ffi.PrepareCallInterface(cif, types.DefaultCall, retType, argTypes)  // once
  ffi.CallFunction(cif, fnPtr, &result, args)                         // many times, zero alloc

Type classification is pre-computed at prepare time, not at call time. The call path is: Go → runtime.cgocall → hand-written asm → C function. The asm loads GP/FP registers per ABI from a flat argument buffer — no interpretation at call time.

The assembly:

Three hand-written stubs: System V AMD64 (RDI,RSI,RDX,RCX,R8,R9 + XMM0-7), Win64 (RCX,RDX,R8,R9 + XMM0-3, 32-byte shadow), AAPCS64 (X0-X7, D0-D7, HFA support). Each is ~100 lines of Plan 9 asm.

What goffi does that purego doesn't:

Struct passing by value (8B in RAX, 9-16B in RAX+RDX, >16B via sret pointer). Callback float returns via XMM0 — purego panics on float/double return from callbacks. Typed errors — 5 error types with errors.As() instead of generic errors. Context support for timeouts and cancellation.

What purego does better (being honest):

purego supports 8 GOARCHes and 20+ OS×ARCH combinations — we cover 6 targets (amd64×4 + arm64×2). purego auto-marshals strings, bools, and slices — we work with raw unsafe.Pointer. purego has a much simpler API — one line to bind a function. purego has full Darwin ARM64 variadic stack packing — we don't yet.

Related projects worth knowing:

JupiterRider/ffi (https://github.com/JupiterRider/ffi) — pure Go binding for native libffi via purego. Supports variadic and struct pass/return, but requires libffi.so at runtime. If you need variadic calls today, that's a good option.

Where we use it:

goffi powers gogpu (https://github.com/gogpu) — a pure Go GPU computing platform with WebGPU bindings, zero CGO. It's also used in Born (https://github.com/born-ml/born) — an ML framework for Go with PyTorch-like API, type-safe tensors, and automatic differentiation. Both projects ship as single binaries with no C toolchain required. 89% test coverage, CI on Linux/Windows/macOS, MIT license.

We wrote a deep dive on the architecture, assembly, and callback mechanism: https://dev.to/kolkov/goffi-zero-cgo-foreign-function-interf...

Happy to discuss FFI internals, ABI details, or the trade-offs between the different approaches!

Author here. I've been practicing what Karpathy now calls "Agentic Engineering" since January 2026 – a month before he coined the term. Across 35+ open source Go projects (~1M+ LOC total, including a 425K LOC pure Go GPU ecosystem), I found that orchestrating agents isn't enough. The critical missing piece is what I call Bidirectional Learning: structured knowledge files that the AI reads on session start and updates on exit. Each session compounds on the last instead of starting from zero. Without this, you're conducting an orchestra that forgets the piece they played yesterday.

Happy to answer questions about the workflow or any of the projects.