TL;DR: Jonathan Blow, creator of Braid and The Witness, thinks garbage collected languages like C# are wrong for games. Unity's old Boehm GC forced developers into object pooling to avoid frame hitches. Blow built his own language, Jai, to own the stack. His DevGAMM 2019 talk warns that engine knowledge is dying because nobody builds engines anymore.

Jonathan Blow’s Take on Game Engines (And Why It Matters for Developers)

Indie designer and programmer Jonathan Blow (Braid, The Witness) is known for strong opinions on how games are made, especially about game engines and the tools we use every day. His views are worth understanding even if you ship with Unity or Unreal: they’re about performance, control, and the long-term health of our tools.

The Short Version

Blow is critical of relying on a small set of commercial engines (Unity, Unreal) and of languages that don’t give developers enough control over performance, notably garbage-collected languages like C#. He doesn’t think the answer is “use engine X better”; he’s spent years building his own language (Jai) and tooling so he can own the whole stack. He also worries that if almost nobody builds or deeply understands engines anymore, that knowledge will disappear, a theme he expands on in his talk “Preventing the Collapse of Civilization.”

1. Criticism of Garbage Collection in Game Development

Blow has repeatedly argued that garbage collection is a poor fit for game development at the performance level he cares about. He points out that GC causes unpredictable pauses: the runtime decides when to collect, not the developer, which can mean hitches and frame spikes exactly when you don’t want them.

This criticism lands especially on Unity’s historical use of C#: for a long time Unity used a non-incremental GC (the Boehm collector), which led to noticeable “GC spikes” during gameplay. Developers had to work around it with object pooling, avoiding allocations in hot paths, and other tricks, all to compensate for a runtime behavior they couldn’t directly control. Blow’s view is that game-specific languages shouldn’t rely on GC in the first place; the control and predictability of manual (or more explicit) memory management are essential for high-performance, real-time games.

2. “Almost Nobody Programs Game Engines Anymore”

In his talk “Preventing the Collapse of Civilization” (DevGAMM 2019), Blow goes beyond performance and talks about who actually builds and maintains game engines.

His concern: most teams now build games, not engines. They use Unity or Unreal as black boxes. The number of people who can design, implement, and debug a full engine, or even deeply extend one, is small. If that knowledge isn’t passed on and if the next generation only knows how to use existing engines, we risk a kind of knowledge collapse: the ability to create or deeply fix these systems could fade when the current experts retire.

So for Blow, the issue isn’t only “Unity vs Unreal” or “C# vs C++”; it’s that relying on a few closed or complex ecosystems makes the whole industry more fragile. He’s not saying everyone should write an engine, but he does think the option to build your own (or to understand engines deeply) should exist and be taken seriously.

3. Building Your Own Engine (And Language)

Blow doesn’t just critique; he’s acted on it. He has publicly advocated for building your own engine when commercial engines don’t fit your goals or when you want full control over performance and design.

Going further, he’s spent over a decade designing Jai, a programming language aimed at game development. He’s said he started because of frustration with C++ (which he’s called “a terrible language”) and with the limitations of C# and GC for the kind of high-performance, predictable code he wants. Jai is meant to be compiled, low-level enough for games, but with a cleaner design and without GC, and it’s being proven on a real project: Order of the Sinking Star, a 3D puzzle game built in Jai at Thekla, Inc.

So his “opinion on game engines” is really: if the mainstream stack doesn’t give you control or performance, consider building your own tools, including your own language. That’s a high bar, but he’s deliberately chosen that path.

4. What This Means for Us as Developers

You don’t have to agree with every take to get something useful out of it:

Performance and GC: If you’re in Unity, being aware of allocations and GC (pooling, avoiding unnecessary allocations in hot paths) is exactly the kind of discipline Blow is arguing for, even if we’re still inside a GC’d runtime.

Understanding the stack: Learning how engines and runtimes work (rendering, physics, memory, build pipelines) makes you less dependent on a single vendor and better at debugging and optimizing.

Tooling and craft: Blow often ties this to “craft” and “work ethic”, caring about the quality and longevity of the tools we use, not just shipping with whatever is default.

You can keep shipping with Unity or Unreal and still take away: more control over performance, deeper understanding of engines, and skepticism toward one-size-fits-all solutions.

Sources and Further Reading

1. Jonathan Blow on a Programming Language for Games , Unity forums discussion summarizing his views on GC and game languages.

2. Unity’s own Optimizing for managed memory and community discussions on GC (e.g. Hacker News) document the historical impact of GC on Unity games.

3. Jonathan Blow, Preventing the Collapse of Civilization (DevGAMM 2019), YouTube , main source for “almost nobody programs game engines” and knowledge collapse.

4. Jonathan Blow on Building Your Own Engine, YouTube , building custom engines as a viable path.

5. Jai (programming language) , Wikipedia on Jai’s design, history, and relation to Thekla/Order of the Sinking Star.

6. Jonathan Blow Is Writing His Own Programming Language , Forbes (2015) on his motivation for Jai.

7. Jonathan Blow , Wikipedia biography and context on Braid, The Witness, and Thekla.

If you’re building games in Unity and want to go deeper on performance, architecture, or engine concepts, I focus on that in my mentorship and tutorials. Feel free to reach out.