Kaiju Engine: Can Go Compete with C++ for Game Dev?

Kaiju Engine: Can Go Compete with C++ for Game Dev?

Kaiju Engine, a new game engine written in Go and backed by Vulkan, gained 1,480 GitHub stars on December 11, 2025, reigniting the debate over whether garbage-collected languages can compete with C++ for real-time game development. While Unity, Unreal, and Godot dominate with C++ or C# foundations, Kaiju challenges decades of conventional wisdom by leveraging Go’s simplicity alongside Vulkan’s low-level graphics power.

The catch? Zero shipped games and serious community skepticism about performance benchmarks.

Net-Zero Allocation: Kaiju’s Answer to the Garbage Collection Problem

Kaiju’s core technical innovation is “net-zero heap allocation” during game runtime, which avoids triggering Go’s garbage collector during frame rendering. The developers claim 2,712 FPS for a complete game featuring real-time PBR rendering, shadows, UI, and audio—in debug mode, no less.

Here’s the trick: by pre-allocating objects during initialization and reusing memory pools during gameplay, Kaiju prevents runtime allocations that would force garbage collection. From the project’s README: “The overall design for the engine plays very well with the GC and last I measured, I have a net-0 heap allocation while running.”

Sounds promising, except the Hacker News community isn’t buying it. One developer cut through the hype: “An empty scene benchmark is basically a measurement of how thin your abstraction layer is, not how the engine behaves under actual game workloads.” Without real games stress-testing the engine, these performance claims remain theoretical.

Go’s garbage collector has improved dramatically—Twitch achieved ~1ms GC pause times back in 2016 with Go 1.7. For 60 FPS gaming, you have 16.67ms per frame, so a 1ms pause consumes 6% of your frame budget. Kaiju’s net-zero allocation strategy aims to eliminate even that overhead. However, until someone ships an actual game proving this works under pressure, it’s just impressive engineering with no validation.

The Cgo Overhead Problem: Vulkan Calls as a Bottleneck

Kaiju’s second challenge is more insidious: cgo overhead. The engine uses cgo bindings to call Vulkan APIs from Go, incurring 40-171 nanoseconds per call depending on your Go version. That might sound negligible, but graphics engines make thousands of Vulkan calls per frame.

Benchmarks from CockroachDB show cgo calls at ~171ns compared to 1.83ns for native Go functions—a 100x slowdown. Newer Go 1.21 benchmarks from Shane.ai reduced this to ~40ns, but the question remains: how many times does Kaiju cross the cgo boundary per frame?

At 60 FPS with 16.67ms per frame, you could theoretically make ~416,000 cgo calls at 40ns each before exhausting the entire frame budget. Nevertheless, real games need CPU time for physics simulation, AI pathfinding, game logic, and asset streaming. Graphics can’t consume everything.

One Hacker News commenter hit the nail on the head: “Go has this performance bottleneck…any kind of request of a faster path to call cgo was ignored by the Go team.” This is why Unity uses C++ for its core graphics engine with C# scripting on top—keeping the performance-critical rendering path native while offering developers a friendlier scripting language.

Zero Shipped Games: The Hobby Engine Problem

Here’s the deal-breaker: after 10 minutes of searching, one Hacker News developer found exactly one screenshot of a game built with Kaiju. Not a complete game. A screenshot.

Kaiju’s README states the engine is “production ready” but the built-in editor is “not production ready,” and the engine itself “is not released and is under heavy development.” This is the classic hobby engine pattern: GitHub overflows with these projects because building engines is easier than shipping games. Different skill sets entirely—technical optimization versus game design, narrative, balance, and polish.

Compare this to Unity’s 4 million developers and 50% market share of mobile games, Godot’s 60,000+ GitHub stars with thousands of shipped indie titles, or Unreal’s dominance in AAA development. Kaiju has 3,055 stars (impressive growth!) but zero proof it works for actual game development.

Real games stress engines in ways synthetic benchmarks can’t predict: complex physics interactions, massive world streaming, AI pathfinding across hundreds of entities, multiplayer networking with state synchronization. Until Kaiju ships real games, all the technical claims are just that—claims.

Related: TypeScript Overtakes Python as GitHub’s #1 Language

What Kaiju Gets Right: Simplicity Over Raw Power

Strip away the performance debates, and Kaiju’s real value proposition emerges: lowering the barrier to game development. Go is dramatically simpler than C++. No manual memory management. No header file maze. No pointer arithmetic hell.

Consider who’s already using Go at scale. Riot Games built Valorant’s entire backend in Go, leveraging “concurrency primitives to add back pressure when operations start slowing down, parallelize independent operations, and run background processes.” Wildlife Studios handles 40 million daily active users with Go microservices. ByteDance runs 70% of its infrastructure on Go.

These backend developers already know Go. Kaiju offers them a path into game development without learning C++ first. The project’s philosophy is explicit: “Developers can write their games in Go directly, no need for some alternative language that is different from the engine code.”

Not every game needs Unreal Engine’s Nanite geometry or Unity’s massive asset marketplace. Indie 2D games, puzzle titles, strategy games, and simulation projects could benefit from Go’s developer productivity even if raw performance trails C++ slightly. The question is whether “slightly” is accurate or wishful thinking.

What Kaiju Must Prove to Succeed

Kaiju’s viral moment—1,480 stars in a single day—is an opportunity, not a victory. To convert curiosity into adoption, the project needs proof, not promises.

First, ship 1-2 complete indie games built with Kaiju. Not empty scene benchmarks. Actual games with complex logic, asset streaming, physics, UI, and polish. Open source them so the community can profile GC behavior and cgo overhead under real workloads.

Second, publish honest profiling data. Show actual GC pause times during gameplay. Document where cgo overhead appears in frame budgets. Be transparent about limitations—nobody expects Kaiju to match Unreal’s AAA capabilities, but developers need realistic expectations.

Third, stabilize and release version 1.0. Right now there are no official releases, no semantic versioning, and the editor is explicitly unfinished. Developers won’t bet production projects on unstable tooling.

Godot’s growth came from shipped games proving it worked. Unity became the mobile standard by powering millions of published titles. Even Ebiten, a simpler Go 2D engine, has games on Steam. Kaiju needs the same proof of concept.

Key Takeaways

• Kaiju challenges C++ dominance with Go + Vulkan, but zero shipped games mean all claims are theoretical
• Net-zero allocation tackles GC concerns intelligently, but empty scene benchmarks don’t reflect real game workloads
• Cgo overhead could bottleneck Vulkan calls—40-171ns per call adds up across thousands of graphics commands per frame
• Go’s simplicity is the real advantage—backend developers get a familiar path into game development without C++ complexity
• Viral interest doesn’t equal production readiness—Kaiju needs shipped games, stable releases, and honest profiling before developers trust it for real projects

The verdict: Kaiju is a fascinating experiment exploring whether modern languages can break C++’s stranglehold on real-time graphics. If the team ships even one polished indie game proving the architecture works, it could open game development to Go’s massive developer base. Until then, it’s an ambitious prototype, not a Unity alternative.