“Complexity is multiplicative.”
The Story
Robert Griesemer's career reads like a tour of the most performance-critical software ever built. Before Go, he worked on the V8 JavaScript engine at Google — the runtime that made Chrome fast and enabled Node.js to exist. Before that, he contributed to the Java HotSpot VM at Sun Microsystems — the just-in-time compiler that made Java viable for production workloads after years of being dismissed as too slow.
Both V8 and HotSpot are among the most security-critical pieces of software ever written. V8 runs untrusted code from every website a Chrome user visits. HotSpot runs the server-side applications that process financial transactions, medical records, and government data worldwide. A bug in either runtime isn't a bug in one application — it's a bug in every application that runs on top of it. Griesemer worked at the layer where a single optimization mistake can become a CVE affecting billions of devices.
In 2007, frustrated with the multi-hour compile times and Byzantine complexity of Google's C++ codebase, Griesemer began discussing a new language with Rob Pike and Ken Thompson. The conversations happened during the long waits for C++ builds to finish — which is perhaps the most fitting origin story any programming language has ever had. The result was Go: a language designed not around what features it should have, but around what features it should deliberately exclude.
Go has no inheritance. No generics (until 1.18, and even then, deliberately constrained). No exceptions. No implicit type conversions. No operator overloading. No macros. Each of these omissions was a deliberate decision — a bet that the complexity these features introduce outweighs the convenience they provide.
Why They're in the Hall
Griesemer is a Builder in the deepest sense — someone who has spent decades working at the layer between human-written code and machine execution, making that layer faster, safer, and more predictable.
His work on V8 and HotSpot places him at two of the most consequential chokepoints in modern software. The browser runtime and the JVM together execute the vast majority of code that humans interact with daily. Griesemer didn't write the applications — he wrote the thing that runs the applications. Bugs at that level cascade into every exhibit in the TechnicalDepth archives.
But it's Go where his philosophy becomes most visible. Go was designed as a reaction to C++ complexity — the kind of complexity that generates the patterns documented in TechnicalDepth's Exhibits wing. When a language lets you express the same idea seventeen different ways, teams will use all seventeen, and the resulting codebase becomes an archaeological site of competing idioms and implicit conventions.
Go's answer is enforced simplicity. One way to loop. One way to handle errors. One way to format code (gofmt — there is no style debate because the tool decides). The language was an argument, rendered in syntax and semantics, that the features you leave out matter more than the features you put in.
Griesemer understood something that many language designers miss: complexity is multiplicative, not additive. Every feature interacts with every other feature. A language with N features doesn't have N units of complexity — it has something closer to N-squared. By keeping N small, Go keeps the interaction space manageable, and manageable systems produce fewer of the bugs that fill TechnicalDepth's exhibit halls.
His career arc — from optimizing runtimes that execute other people's code, to designing a language that prevents other people's bugs — is the trajectory of someone who has seen what complexity costs at every level of the stack.