Adding in a second neural network that guesses the identity of hidden pieces was key.

Credit: Vectorwin

Deep Blue took down Garry Kasparov at chess in 1997, AlphaGo beat Lee Sedol at Go in 2016, and poker bots have been beating professionals for years. But one classic game called Stratego held out. Even DeepMind, with its exceptional budget, couldn’t build a machine that reliably beat the best human players.

Now, a team of researchers from Carnegie Mellon, MIT, New York University, and Stanford University has done it. Their AI, called Ataraxos, beat Pim Niemeijer, arguably the best Stratego player of all time, 15 games to one, with four draws. And it took just 16 GPUs and a few thousand dollars to train it.

Hidden armies

In Stratego, each player gets 40 pieces representing military ranks, from a marshal down to a spy, plus bombs and a flag. You win by capturing the opponent’s flag. Your opponent knows where your pieces are, but not what they are. Identities are revealed only when two pieces collide in battle—the weaker one is removed, and the identity of the winner is revealed. That makes Stratego an imperfect-information game, just like poker, which computers cracked years ago. “There’s something super distinctive about Stratego, which is that it is a massive amount of hidden information that unfolds over a very long time scale,” said Eugene Vinitsky, a researcher at NYU and co-author of the study.

In some forms of poker, the hidden information is tiny. In Texas Hold’em, “You only have two hidden cards,” said Gabriele Farina, an MIT computer scientist and another co-author. That leaves just 1,326 possible hands, few enough for a machine to weigh them all. “In Stratego, there’s 40 pieces on the board that could be in any order,” Farina said. That’s more than a decillion possible setups. Then there’s the game’s length.

“In chess, usually the game lasts 40 moves, but in Stratego, a game can easily last 2,000 moves,” Farina said. On top of that, Stratego is a game of bluffing. Sometimes you move a weak piece as if it were a marshal, just to scare the opponent off. When players bluff too often, their threats mean nothing; when they never bluff, they become predictable. That balancing act, the team explains, is what stumped earlier AIs like DeepMind’s DeepNash, introduced in 2022.

Learning to guess

Just like DeepNash, Ataraxos learned by playing against itself—163 million games in total. In these self-play sessions, moves that led to wins were reinforced and played more often in future matches, while moves that led to losses were played less, which was the same simple training idea. The difference was in how much Ataraxos adjusted after each game, because hidden information tends to send self-play learning algorithms around in circles. The team addressed this by making big, bold changes in strategy early in training and small, careful ones later.

The even bigger innovation was something DeepNash never had: thinking ahead before each move. AIs like AlphaGo refine their general strategy with a search just before acting. DeepMind couldn’t make that work in Stratego because the search space was too large, leaving it an open question whether it was worth trying.

“This is one of the things that we did figure out how to do,” Farina said. The solution was a second neural network, a belief model, trained to guess the opponent’s hidden pieces based on how they had been moving. This way, instead of iterating through every possible arrangement, Ataraxos samples plausible ones, plays out candidate moves in each, and picks based on how they turned out.

And it shows in its playstyle.

Calm and unbothered

The name Ataraxos comes from the ancient Greek word for a state of calm. “It means somebody that’s calm and unbothered,” Farina explained. He suggests the structure of the AI and its lack of human emotions ensure it doesn’t react impulsively, “even in situations where a human would be losing their mind.” While the human might try big gambles to come back from a significant deficit, Ataraxos would work its way back into the game slowly and methodically.

The strategy it developed also avoids drawing attention to any problems it faces. When Ataraxos estimates its opponent has no reason to suspect a weak spot, it leaves that spot alone, even if it might look like a disaster waiting to happen to anyone who can see both sides of the board.

“For humans, it’s very hard when you know a secret to make decisions ignoring the fact that you know that secret,” Farina said. “For machines, it’s easy.” This, the team says, leads machines to make moves a human would only do while bluffing—and follow up on them much better than humans. “We would watch the bot ‘bluff’ its way back from like a two percent victory probability, very, very casually,” Vinitsky added.

Niemeijer, the human player Ataraxos pulled these miraculous comebacks against, has four world championships and more than 600 weeks as the world’s top-ranked player.

The match

Over three weeks, Niemeijer played 20 online games against Ataraxos, earning $100 for each win. He knew the AI would not adapt to him, which gave him time to hunt for weaknesses. He managed to win just once.

That loss, researchers claim, wasn’t really a flaw. Playing Stratego well requires randomizing the arrangement of your pieces, so luck always plays a role. “Even a perfect strategy, sometimes it will just lose,” Farina said.

The human champion apparently got lucky, but it went both ways. “Sometimes we got lucky,” Vinitsky admitted.

At the 2025 Stratego World Championship, attendees who challenged Ataraxos fared even worse. The AI won 38 of 40 games. In the process, it also changed how people play. “I think this bot has kind of skewed the metagame a little bit,” Farina said.

Players were surprised, for example, by how often it tucked its flag into a corner behind just two bombs, a rarely played setup.

But Ataraxos’s best trick was arguably its price tag.

The price to pay

DeepNash was trained for two to three months on 1,024 of Google’s specialized chips, a run the Ataraxos team estimates would cost $3 million to $4.5 million at 2025 prices. Ataraxos, in contrast, needed 16 GPUs for a week, plus an additional four GPUs for four days to train the belief model.

Farina and lead author Samuel Sokota achieved this efficiency by writing a simulator that runs millions of moves per second on graphics cards. “At the scale that we are in academia, we don’t really have access to an entire field of GPUs,” Farina said.

The algorithm also learned far faster—it played about 34 times fewer games than DeepNash, and still ended up much stronger.

The Ataraxos architecture also worked in learning other games. The same approach beat three world champions at Barrage Stratego, a faster eight-piece variant of Stratego, mastered the cooperative card game Hanabi, and beat the best bots at the Chinese card game dou dizhu. But the team has its sights set on scenarios far more complex than board or card games.

Beyond the board

Board games have fixed rules and clear winners, while real-world problems like negotiations, financial markets, or military conflicts usually don’t. But the Ataraxos team argues the gap is smaller than it looks, since tackling any real problem starts with building a simplified model of it.

“War gaming is a common thing that people do,” Vinitsky said. “You can use the techniques that were derived here to play it forward and see how a strong opponent might respond to what you do.”

Farina and his colleagues are now interested in making their AI more understandable, since Ataraxos, in its current state, can’t explain why it makes the moves it makes. “We work on machines that produce strong but also interpretable and explainable strategies. I think we’re not quite there yet,” Farina said.

Nature, 2026. DOI: 10.1038/s41586-026-11036-y

Why SaaS business is now a harness one.

Every SaaS business will become a harness around a model, whether or not they’ve realized it yet.

What even is a harness?

Narrowly, folks will often associate a “harness” with frameworks like LangGraph or coding agents like Codex, Claude Code, or OpenCode, which wrap a stateless model API in enough tooling and state that you can actually get work done.

I’m using the term “harness” broadly to mean all the infra, interfaces, context, and state that surround a stateless LLM. A harness can be composed of adapted or task-specific sub-harnesses (with the orchestrator being called a “meta-harness”). A “software factory” is a harness whose parts are smaller harnesses — one that writes specs, one that writes code, one that reviews — plus something on top deciding what runs when.

If you accept this broader definition (or replaceAll “harness” with whatever phrase you’d prefer), I suspect for many software service businesses you’ll see this trajectory:

1. They sell software services built the traditional SaaS-y way.

   1. No harness.

2. They sell software services, but the engineers pair with agents to get the work done. Increasingly other functions like product and sales pair with agents for productivity.

   1. Individuals operate harnesses.

3. They sell software services with many core tasks moving to background agents running in the cloud (a laptop can’t run twenty of them). Engineering, product, and sales all trigger these agents (i.e. write the prompts) and review the outputs.

   1. Individuals orchestrate harnesses.

4. They sell software services with many core tasks moving to proactive background agents, with engineering, product, and sales moving to reviewing agent outputs. Consistent reviews move to sampled reviews. Increasingly the agents decide what to do proactively, instead of humans designing the work up front.

   1. Harnesses orchestrate individuals.

Following this trajectory, you’ve actually turned your company into a harness. The work to produce the software service has moved from people to the harness.

• Core tasks are done by agents and the “product” is now entirely model output, with the company supplying the context, integrations, and human-facing review interfaces.
• The relationship between software and org structure has inverted as the org chart becomes a question of where to put people so the harness gets the most taste and judgment out of them. Humans are part of the harness.
• The company’s domain knowledge, tooling, permissions, review loops, context, etc. all become the business harness.

This sounds like an AI slop factory.

It’ll be tempting to think that products that are primarily crafted and reviewed by AI will be inherently low quality and that building through a harness instead of through people will produce a slop factory at scale. I think that belief assumes a company run this way is lights-out.

The core mitigation is actually having the harness pick where human inputs matter most. For example:

• A product decision could come from an agent fanning out questions to reps in customer meetings and then synthesizing a product demo for the product lead to review
• A feature suggestion pulled from a customer meeting is turned into a major architectural decision presented to an engineering taste-holder by the agent.
• A UI redesign kicks off after aggregating feedback, and after testing a few variants, the top options are presented to a design taste-holder.

A good harness maximizes value to the customer while spending human attention — employees’ and customers’ — only where it’s needed.

If you are still skeptical, that’s fair. Even with today’s frontier models and a well-crafted harness, it’s quite difficult to trust agents to handle the outer loop like this (we’ve spent a lot of time trying). I just don’t think it’s worth betting that models won’t be able to eventually do this, especially as more of this planning-and-review work gets broken into tasks with verifiable rewards that labs can train on.

To explore more on what an organization of “taste-holders” could look like, see The Transposed Organization. This post builds quite a bit on the ideas laid out in that article.

If harnesses produce and sell the product, that’s now your core competency.

Depending on the service, the differentiation a company has often comes from things like trust, distribution, efficacy, and domain context. In a proactive background agent world, your ability to construct the harness — how it learns, what it watches for, how it interfaces with human taste-holders, what systems it integrates with — will more and more be how you maintain that differentiation.

The harness is now what shapes what must be true for work to ship (~trust), how fast and how the products land (~distribution), the speed and context of feedback loops (~efficacy), and how institutional knowledge is ingested and maintained (~domain context).

Harnesses go from internal tooling you’d happily buy to something you’d no more outsource than your product-eng org or your GTM team. This is distinctly different from the pre-AI world, where outputs were mostly bounded by the humans using the software to get things done.

This is already starting to happen.

I think in-house AI developer tools (like the ones we’ve seen from Ramp, Stripe, DoorDash, etc.) are the beginning of this.

For AI-pilled companies, waiting for an SDLC tool vendor to add an integration, support a certain interface, or reach a level of cost-efficacy increasingly bottlenecks their ability to build and maintain their product. This is especially true in the short term for third-party tools that can’t yet run an enterprise’s whole software factory for it (often because the tech stack is too bespoke, governance too restrictive, critical feature support too slow, or due to a preferred cost model).

I don’t expect everything to be built and maintained in-house. Rather, companies should own the top-level harness — the one that decides what to build and reviews what comes back — and plug vendor products into it for specific workflows. Eventually a third party will get pretty good at an enterprise-level “spec to tested pull request” and at that point a company can swap out that part of the software loop with that product while still maintaining the agent(s) that write the input spec and handle the next steps from pull request output.

If somehow the entire outer loop can be done by a third-party harness (i.e. running the entire business via proactive background agents as a service), then I’d argue the business has now been commoditized.

So what?

If this is the right mental model, you should expect to see:

• An unusual amount of in-house harness building on both the build side and the sell side
• Org structures and individual roles being reshaped around their place in the business harness
• AI-native startups beating incumbents in domains where the “moat” can be easily harness-ified
• All software a software company uses (on or tied to the core build or sell paths) needing to be headless so the outer harness can run it

Slop, Alienation, Deskilling, and Team Fallout

Agentic coding is undeniably very useful. It’s also very bad. Or rather, it’s having some horrible effects on us, our craft, and our relationships with each other. I can feel it in my bones, and a lot of others can too. But whenever I try to explain what exactly is wrong, I find myself waving my hands wildly and jumping from point to point. What do you mean, what’s wrong? So many things are wrong!

Fine, here’s a list. 4 problems with no solution in sight–or, as I call them, the four horsemen of agentic coding.

Slop

LLM-generated code has a strong smell that makes codebases repulsive to humans.

LLMs aren’t humans, and the way they write code is... different. Not strictly worse, but different for sure. We quickly came up with a name for it—slop—and it undoubtedly carries a negative connotation.

For plain prose, humanity seems to be converging on the opinion that AI prose is bland at best and an insult at worst. For code, due to its instrumental nature, the debate is far from over. A lot of people latch onto the idea that very soon we won’t have to read the code at all. “Remember, it’s the worst the models will ever be,” they say.

And yet, the latest generation of models is surprisingly underwhelming. They’re certainly smart, but they seem to be moving towards “unemployable smart” rather than “inspiring smart.” Claude now famously communicates entirely through word salad, and Astra writes in a bizarre competitive code-golfy style, incomprehensible to normal humans. Sloppiness turned out to be a surprisingly persistent property of LLM output and at this point looks like a signature move rather than a growing pain.

Which is very bad news for people who still want to poke around in the codebase and maintain some familiarity with it, especially in a team setting. Once agents are allowed, they very quickly take over. What used to be a shared space for humans where each team member contributed became an AI wasteland where people don’t want to spend time.

But what if we don’t have to spend time in these slop caves? Why spend your time there when you can be a design mastermind and reign over a swarm of loyal agents from the comfort of the chat interface?

Alienation

Engineers become alienated from code and, as a result, care less.

Software engineering used to be a fairly... kinesthetic field of work. Maybe not to the same degree as woodworking, but we loved our tools too, both real and virtual. Text editors had a cult-like following. Popular color themes and programming fonts had their own fanbases. Split keyboards were a hot thing once, and there was no shortage of keyboard sound testing videos.

We produced code directly, by hand. It’s only natural that this resulted in a strong sense of ownership of the fruits of our labor. Sure, this feeling varied depending on the context, but even if you just assembled something from a set of building blocks, you would feel something. IKEA certainly knows that!

Agentic coding has dramatically increased the distance between engineers and the product of their work. This gap is so large that none of our kinesthetic tools can cross it. We don’t experience code directly anymore: we send an agent with a vague set of instructions and then skim through its report. Hell, even typing is optional—you can just yap at your phone while driving.

So naturally, we become more detached. We care less. We lose touch with our craft. And it shows. It shows in poorly thought-out features that receive no pushback. It shows in band-aid bugfixes that don’t address the root cause. It shows in how unfulfilled we feel at the end of the day. For software to spark joy, it has to be imbued with its creator’s love.

Elsie Driggs, “Pittsburgh”

Deskilling

AI erodes existing skills, impedes learning, and doesn’t offer any meaningful skill progression.

I think at this point it shouldn’t be controversial to say that deskilling is real. There is no shortage of people reporting their wits slipping away after prolonged use of AI. Which makes sense: a lot of things in life are use-it-or-lose-it, and professional skills are no exception. Yes, you’ll always know how to ride a bike, and I myself will die before I forget how to exit Vim, but anything beyond that is fair game.

I’ve made the point before that we’re currently experiencing a historical anomaly. We have all those seasoned engineers who spent years doing things the hard way and can now hold LLMs exactly the right way to be insanely productive. But unless we figure out how learning works in the age of AI, this supply won’t last long.

One common piece of advice is that if you’re at the beginning of your career, you simply shouldn’t use AI. And I completely agree, but it’s important to understand that this isn’t a viable strategy for humanity as a whole. Everyone will not just.

We can’t be blind to the fact that the introduction of an “easy button” has led to a tectonic shift in incentives to learn. And if I know one thing about humans, it’s that they follow incentives.

Another common response to the deskilling argument is that LLM usage comes with its own learning curve. You just need to upskill and learn the intricacies of downloading markdown files! I’m not buying it. The learning curve is basically non-existent.

A printing press or a chainsaw at least requires some skill to operate, but the fancy new magic box? You don’t have to know how to read or write. A caveman could build a B2B SaaS and be on time for his weekly podcast appearance. And if you think your custom agent orchestration workflow is an important feat of engineering, just you wait.

Team Fallout

Agents weaken the social fabric of engineering teams by reducing interpersonal communication, increasing self-reliance, and hindering skill expression.

Slack channels used to be crowded with people. Anything that your rubber duck couldn’t answer would go into a team chat. Now the chat is a pale shadow of its former self. Everyone is too busy talking to their agents. Each of us has received a magic familiar that follows us around like we’re some kind of Disney protagonists. It’s very smart, available 24/7, and will never report you to HR. The rubber duck can finally talk back!

In a certain sense, being more autonomous is virtuous. Why distract colleagues with your silly nonsense? The problem is, helping other people with silly nonsense is our thing. It’s how we build and maintain relationships. You need to walk the path; otherwise, it will be overtaken by grass.

I’m convinced that AI has dramatically reduced interpersonal communication. The average team chat right now consists of agent threads and an occasional LLM-generated manuscript followed by a humble “what do you guys think?”

Agentic coding also changes the way we see other people. Teams used to be sort of like parties of adventurers: a Git wizard, a Rust witch, a bard who is really into mechanical keyboards. There was plenty of room for skill expression, and the diversity of expertise was celebrated.

Now, an average team consists of a Claude operator, a Codex whisperer, and a guy with AI psychosis who insists on committing .md files. “This is John—you’ll want to see how he prompts,” said nobody ever.

And that’s true: nobody wants to see how John prompts. There is something repulsive and fundamentally unsexy about talking to an agent. It feels fine when you are doing it, but others... ugh, get a chatroom. Their prompts are cringe; their agents are weird. Like looking at someone else’s TikTok feed.

So here we are, still peers in the org chart, but growing more and more distant over time. I used to praise your Vim skills and Advent of Code solutions. These days you prompt Claude all day, and I do too. Are we even a team anymore?

---

So that’s my list. And I’ll be honest with you, I have no idea what to do with any of this. I can only hope that eventually we’ll move forward in this cursed discussion. However beneficial AI is, we pay dearly for it with our curiosity, craftsmanship, and social connection.

---

AI discussion will continue until the morale improves

Am I allowed to say that? Because it does.

Maybe it's because I'm writing this at 2:00 AM, which is about the only time I let myself experience sadness for a prolonged period of time, but every time I see a post on Twitter or LinkedIn about a new development in AI, I feel a sense of hopelessness.

And I'm saying this as someone who is absolutely in a position to benefit from AI. If I added a few vibecoded projects to my resume, the gaping maw of every startup, enterprise company, and FAANG behemoth would open to me. Just the other day, I sat near a table of my fellow TAs as they discussed their plans to work at OpenAI after graduation, eyeing $500k salaries.

But I don't want to do that. I don't want to prompt Codex for a living, or Claude for that matter. Maybe it's because I don't even really know what that looks like. As sure as I know anything, I know what it sounds like. It sounds like a loss of craft, a loss of control, a loss of creativity. It sounds like Charlie Chaplin in Modern Times, the scene where he's so enthusiastic about screwing hex nuts in a factory that he screws the buttons on people's shirts, and then he goes and gets himself caught in the conveyor belt, snaking through the gears and screwing in the hex nuts inside the machine. It sounds like people around me are throwing themselves at the machine, volunteering to make themselves obsolete for $500k a year. If you genuinely, genuinely, believed artificial superintelligence was coming, why would you want to work at the company that would be in the best position to replace its employees?

It makes me sad that I missed the boat on startups. I think I could have been a pretty formidable startup founder had I been born five or ten years earlier. I'm good at web stuff, I'm good at Rust, I can even do OS stuff. I watched all the YC Stanford lectures this summer while translating tests from one language to another as an intern. Now there's no such thing as a startup, there are only "AI startups", where you build a company that somebody else can write a prompt for in 30 seconds. And if they can't write a prompt for it now, they'll be able to next year with GPT-7, or whenever AI hardware fabrication gets better.

It makes me sad that AI evangelists are so quick to adopt the language of online incels, and that AI-generated art and music have become the defining aesthetic of fascism in the 2020s while AI-generated writing went from risible to a mark of stupidity to something reluctantly accepted since it sits at the fringes of everything useful on the Internet like a kind of digital mold.

The overwhelming weight of it all feels so stifling. It feels like there's no way to stop it. I can't imagine a Twitter (sorry, an X) where every post isn't filled with verified bots spewing LLM nonsense in the replies. I can't imagine an article about some random topic on some random webpage, designed to maximize SEO for some banner ad I won't see because I block ads, being written by a human. We would have to rebuild all our institutions.

The part where I'm not (that) sad anymore

Honestly, though, it doesn't sound that hard to rebuild all our institutions. Twitter is only 20 years old, LinkedIn is only 23. Most of these were in need of a refresh anyway. I don't know much about the Dark Ages, but I know that Muslims and Irish monks kept the candle of knowledge burning while everyone else ran around crusading. In a similar way, I know that there are a lot of people who feel a lot of the same sadness that I do, even if they don't express it as sadness. I like to think even a lot of AI evangelists feel at least a little sad, like Paul Graham, because he's a Lisp man from way back, and programming language fanatics usually care about humans writing programs.

Another point of hope: the technology industry moves at unfathomable speeds, so we'll start to see a way out of our "dark age" within only a few years as our institutions start to mature and improve. In fact, I suspect that AI will have a fixed role in our society before the end of my natural life. Whether that role is a small one or a major one, I'm not sure. But I know I will feel at least a little happier to have some finality about the whole thing.

I think this will require some painful shifts in our industry, but I also think that this will be a satisfying kind of pain, at least for people like me, like the burn you feel when working out. It feels extremely strange to be looking forward to a bubble bursting. It makes me feel like the AI evangelists who look forward to artists filling out McDonald's applications. But I do. It makes me very hopeful. When I imagine that scenario, I can conjure no emotion besides glee. I desperately want to work in an industry that makes sense, even if a lot of people right now would rather work in an industry that sells nothing to nobody for untold sums of money.

I'm sorry. I want to go back to the Twitter thing because I use Twitter a lot. And, seriously, there are so many verified accounts that just post AI-generated replies to popular posts, and we all just ignore them. It's the most insane, Kafkaesque thing. Absolutely nobody likes it. It's an eyesore. And we're supposed to be living in the most powerful age for AI. You're telling me that nobody at SpaceX/Xai/Grok/SuperGrok/whatever can write a classifier to ban these accounts? I can press a button on any post and be given a full explanation by Grok, a button which I've pressed 2 dozen times on accident and never on purpose. You can't run a decision model for $0.0000001 cents whenever someone hits "Post" and realize that a reply makes no sense?

Recently, I've seen a lot of people point out the fact that billions (trillions?) in AI spend has translated to absolutely no benefit for most consumers of everyday apps. Obviously, people who use ChatGPT get the benefit of having their question answered. But in the world where development is getting faster and cheaper, I can't think of a single piece of software I use that has gotten better. Everything is exactly the same, just with a button to ask a chatbot. Somebody has to notice this eventually.

I want an industry that makes sense. Right now, we have (most of) my undergrad classmates' dream industry. They drink constantly [1], skip lectures, scrape by on their homework with AI, complain about classes, grind Leetcode to get internships, and eventually get their diploma. It must feel like walking around in a literal dream, where your footsteps have no weight, like Wile E. Coyote near a ledge. They commiserate with their friends, "That class is so hard. I just asked Chat." I know because I hear them two seats away from me. Now they get to work a job where they commiserate to an coding agent, "this task is so hard. Do this for me." How come they get to look forward to relief while I feel dread? And that just makes me feel selfish. They're only human too. They is how they've been told to navigate life. For some reason, somebody forgot to tell me. I want an industry that makes sense.

I guess I've been talking a lot about sense. It's 4 AM now, so I guess I'm not making a lot of sense myself. If I wake up tomorrow and the president has signed an injunction on all AI inference, including local models, would I be sadder than I was going to sleep? I don't know. Just ignore me. I'm the homeless guy. I have no home in this industry. Codex, make me a home by the time I wake up.

---

[1] Seriously, if you ever thought Gen Z doesn't drink, look no further than Georgia Tech. I'm in multiple group chats and Discord servers where the subject discussed most often is the date, location, and intensity of the next planned drinking session.

Zig is a general-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.

Zig development is funded via Zig Software Foundation, a 501(c)(3) non-profit organization. Please consider a recurring donation so that we can offer more billable hours to our core team members. This is the most straightforward way to accelerate the project along the Roadmap to 1.0. If you need donation receipts or are looking to migrate away from GitHub Sponsors, we recommend donating via Every.org.

This release features 5 months of work: changes from 206 different contributors, spread among 925 commits.

Originally predicted to be shorter, this release cycle ended up substantial, with the Build System reworked, including the introduction of the Build Server Protocol, and the ELF Linker enhanced to the point where we expect Incremental Compilation to work for everyone on x86_64-linux.

Target Support

Zig supports a wide range of architectures and operating systems. The Support Table and Additional Platforms sections cover the targets that Zig can build programs for, while the zig-bootstrap README covers the targets that the Zig Compiler itself can be easily cross-compiled to run on.

Notable changes:

• aarch64-openbsd is now tested natively in Zig's CI, ensuring high-quality support going forward.
• aarch64-freebsd and aarch64-netbsd CI jobs now run on pull requests too, in addition to master pushes.
• An LLVM bug that broke most aarch64-windows binaries, including the Zig Compiler, has been worked around.
• The Zig Compiler now applies mandatory code hardening techniques when targeting aarch64-openbsd so that the resulting binaries actually work.
• Zig now provides stack traces on crashes and failed assertions on 32-bit ARM. Some work still remains for Thumb-only targets.
• Zig now provides stack traces on crashes and failed assertions on SPARC.
• Zig now handles pointer authentication opcodes when doing stack unwinding on AArch64.
• Support for the loongarch32-linux-gnu[sf] targets has been added.
• Zig now has generally usable support for 64-bit SPARC, and especially sparc64-linux. This is largely thanks to Zig's new ELF linker which now has better support for this target than LLD.
• The Zig Standard Library has been ported to the x32 and N32 ABIs on x86-64 and 64-bit MIPS, respectively. These are niche ILP32 ABIs that allow using the 64-bit instruction set while only having 32-bit pointers - the idea being to trade available address space for lower memory usage and better cache utilization.
• Target information has been added for some game consoles: aarch64-switch, arm-gba, mipsel-psx, and powerpc-wiiu
• Very early xtensa-linux support has been added to Zig. Note that, for now, this support can only be exercised via the C backend or the experimental LLVM backend.
• The Zig Standard Library now has support for arc[eb]-linux, csky-linux, and m88k-openbsd when using the C backend.
• The Zig Standard Library now has support for no-libc microblaze[el]-linux, sh[eb]-linux, and sparc-linux.
• Zig now enforces -mabi=ieeelongdouble for all PowerPC targets. This is just a formalization of what was already reality; Zig has never supported the IBM "double-double" format for long double and likely never will. As a result, this release drops support for powerpc-linux-gnueabi[hf] because glibc only supports the "double-double" format on these targets. The powerpc-linux-musleabi[hf] targets remain supported as they use the IEEE format.
• This release drops support for powerpc64-linux-gnu. Zig has only ever supported linking ELFv2 binaries for 64-bit PowerPC, and glibc does not officially support ELFv2 on big endian - nor IEEE long double, as above.
• Zig's ability to detect the native CPU model and features has been greatly enhanced across the board; this affects almost every architecture on every supported OS.
• The baseline CPU model has been changed for some targets:
  • aarch64-haiku: cortex_a55
  • m68k-*: M68030
  • mips64-openbsd: octeon
  • powerpc-netbsd: 750
  • powerpc64-freebsd: pwr8
  • powerpc64-linux: pwr8
  • powerpc64-openbsd: pwr9
  • s390x-*: arch11
  • sparc-*: generic
  • sparc-linux: v9
  • sparc64-*: ultrasparc
  • xtensa-*: esp32
• In Zig's target query syntax, native libc version detection now only happens if the triple actually uses native libc (i.e. the ABI component is omitted). We expect this new behavior to better match people's mental model for how target queries work, particularly when considering how the OS component works.

Tier System

Zig's level of support for various targets is broadly categorized into four tiers with Tier 1 being the highest. The goal is for Tier 1 targets to have zero disabled tests - this will become a requirement for post-1.0.0 Zig releases.

Tier 1

• All non-experimental language features are known to work correctly.
• The Compiler can generate machine code for this target without relying on LLVM.
• The integrated fuzzer works on this target (if applicable).

Tier 2

• The Standard Library cross-platform abstractions have implementations for this target.
• Failed assertions and crashes produce stack traces on this target.
• libc is available for this target even when cross-compiling (if applicable).
• Continuous integration machines build the module tests for this target on every push.

Tier 3

• The Compiler can generate machine code for this target by relying on an external backend such as LLVM.
• The Linker can produce object files, libraries, and executables for this target.

Tier 4

• The Compiler can generate assembly or C source code for this target.

Support Table

In the following table, ✅ indicates full support, ❌ indicates no support, and ⚠️ indicates that there is partial support, e.g. only for some sub-targets, or with some notable known issues. ❔ indicates that the status is largely unknown, typically because the target is rarely exercised. Hover over other icons for details.

Targets marked with 🪦 are obsolescent; the Zig compiler and standard library maintain best-effort support for them, but that support is expected to be removed eventually.

OS Version Requirements

The Zig standard library has minimum version requirements for some supported operating systems, which in turn affect the Zig compiler itself:

OS	Version
Darwin	15.0+
DragonFly BSD	6.4+
FreeBSD	14.0+
Linux	5.10+
NetBSD	10.1+
OpenBSD	7.8+
Windows	10+

Additional Platforms

Zig also has varying levels of support for these targets, for which the tier system does not quite apply:

• aarch64-driverkit
• aarch64[_be]-freestanding
• aarch64-fuchsia
• aarch64-hurd
• aarch64-switch
• aarch64-uefi
• alpha-freestanding
• amdgcn-amdhsa
• amdgcn-amdpal
• amdgcn-mesa3d
• arc[eb]-freestanding
• arm[eb]-freestanding
• arm-3ds
• arm-fuchsia
• arm-gba
• arm-uefi
• arm-vita
• avr-freestanding
• bpf(eb,el)-freestanding
• csky-freestanding
• ez80-freestanding
• ez80-tios
• hexagon-freestanding
• hppa[64]-freestanding
• kalimba-freestanding
• kvx-freestanding
• lanai-freestanding
• loongarch(32,64)-freestanding
• loongarch(32,64)-uefi
• m68k-freestanding
• m88k-freestanding
• microblaze[el]-freestanding
• mips[64][el]-freestanding
• mipsel-psx
• mipsel-psp
• msp430-freestanding
• nvptx[64]-cuda
• nvptx[64]-nvcl
• or1k-freestanding
• powerpc-wiiu
• powerpc[64][le]-freestanding
• powerpc64-ps3
• propeller-freestanding
• riscv(32,64)[be]-freestanding
• riscv(32,64)-uefi
• riscv64-fuchsia
• riscv64-hurd
• s390x-freestanding
• sh[eb]-freestanding
• sparc[64]-freestanding
• spirv(32,64)-opencl
• spirv(32,64)-opengl
• spirv(32,64)-vulkan
• spork8-freestanding
• thumb[eb]-freestanding
• thumb-fuchsia
• thumb-gba
• thumb-vita
• ve-freestanding
• wasm(32,64)-emscripten
• wasm(32,64)-freestanding
• x86[_16,_64]-freestanding
• x86[_64]-hurd
• x86[_64]-uefi
• x86_64-driverkit
• x86_64-fuchsia
• x86_64-plan9
• x86_64-ps4
• x86_64-ps5
• xcore-freestanding
• xtensa[eb]-freestanding

Language Changes

Language Stability Progress

Since the release of Zig 0.16.0, a lot of progress has been made towards stabilizing the language. This is a key step in our roadmap, and a requirement before tagging Zig 1.0.

In particular, since the last release, we have discussed and made decisions on many language proposals—accepting around 25 and rejecting around 125. At the time of writing, 23 undecided language proposals remain open on the Codeberg issue tracker, and 61 undecided language proposals remain open on the legacy GitHub issue tracker. Therefore, this effort represents a significant step towards finalizing the language design (although some major decisions remain).

@bitCast changes

Zig 0.17.0 changes the definition of the @bitCast builtin.

In many cases, the new behavior is equivalent to the old: in particular, casting between an integer type and another integer type is unaffected, as is casting between an integer type and a packed struct or packed union.

However, the semantics of @bitCast calls involving array or vector types have changed. Unfortunately, this change has the potential to break existing code without triggering a compile error.. Therefore, it may be useful when upgrading to audit any @bitCast uses which involve array or vector types.

The new definition of @bitCast is that it reinterprets the logical bit representation of a value as a different type. The following types are considered to have logical bit representations:

• void
• bool
• integer types, except for comptime_int
• floating-point types, except for comptime_float
• integer-backed types enum(T), packed struct(T), and packed union(T)
• arrays or vectors of any of these types

For integer and floating-point types, the logical bit representation starts with the least-significant bit and ends with the most-significant bit. For array and vector types, all elements' logical bit representations are concatenated in order starting with the first element.

In practice, this means that the new @bitCast definition largely aligns with the old behavior on little-endian targets. Unlike the old behavior, the new behavior is fully endian-agnostic, i.e. the operation behaves the same regardless of the target endian.

The new @bitCast definition disallows casts between some types which were previously allowed. In particular, casts involving extern struct or extern union types are no longer permitted. In most cases, code which was using such casts is aiming to reinterpret the value's in-memory representation (sometimes called "type punning")—to achieve this, use @ptrCast or an extern union.

bitcast_extern_struct.zig

const TwoBytes = extern struct {
    b0: u8,
    b1: u8,
};
test "type pun extern struct" {
    const bytes: TwoBytes = .{ .b0 = 0x12, .b1 = 0xAB };
    const int: u16 = @bitCast(bytes);
    switch (std.lang.Endian.native) {
        .little => try expectEqual(0xAB_12, int),
        .big => try expectEqual(0x12_AB, int),
    }
}
const std = @import("std");
const expectEqual = std.testing.expectEqual;

$ zig test bitcast_extern_struct.zig
/home/ci/.cache/act/4d2db5a0202099f4/hostexecutor/src/download/0.17.0/release-notes/bitcast_extern_struct.zig:7:31: error: cannot @bitCast from 'bitcast_extern_struct.TwoBytes'
    const int: u16 = @bitCast(bytes);
                              ^~~~~
/home/ci/.cache/act/4d2db5a0202099f4/hostexecutor/src/download/0.17.0/release-notes/bitcast_extern_struct.zig:1:25: note: struct declared here
const TwoBytes = extern struct {
                 ~~~~~~~^~~~~~

ptrcast_extern_struct.zig

const TwoBytes = extern struct {
    b0: u8,
    b1: u8,
};
test "type pun extern struct" {
    const bytes: TwoBytes = .{ .b0 = 0x12, .b1 = 0xAB };
    const int_ptr: *align(1) const u16 = @ptrCast(&bytes);
    switch (std.lang.Endian.native) {
        .little => try expectEqual(0xAB_12, int_ptr.*),
        .big => try expectEqual(0x12_AB, int_ptr.*),
    }
}
const std = @import("std");
const expectEqual = std.testing.expectEqual;

$ zig test ptrcast_extern_struct.zig
1/1 ptrcast_extern_struct.test.type pun extern struct...OK
All 1 tests passed.

Formally Specified and Fuzzed Grammar

Zig's formal grammar.peg and the actual language implementation did not agree in many places. Probably, the formal grammar has never actually 100% matched the actual handwritten tokenizer and parser.

This problem is now fixed and unblocks future grammar changes and language specification work.

At a high level, the approach was to write a tool that accepts Zig's grammar.peg as input and outputs a simple recursive descent parser. This generated parser is then used as an oracle for fuzz testing and the handwritten std.zig.Ast.parse() is compared against it. This approach ensures a single source of truth and allows for easy iteration as the grammar changes.

More details: #36094

C Translation Moving to External Package

@cImport was deprecated in Zig 0.16.0 and is now removed. Furthermore, in this release std.Build.Step.TranslateC is deprecated in favor of an explicit package dependency on official ZSF translate-c package, which is the same implementation the build step provides, but offers more configuration options for the translated code, and has an independent release cadence from the main Zig toolchain.

Upgrade guide:

zig fetch --save git+https://codeberg.org/ziglang/translate-c

--- a/build.zig
+++ b/build.zig
@@ -1,16 +1,19 @@
 const std = @import("std");
+const Translator = @import("translate_c").Translator;
 
 pub fn build(b: *std.Build) void {
     const target = b.standardTargetOptions(.{});
     const optimize = b.standardOptimizeOption(.{});
 
-    const translate_c = b.addTranslateC(.{
-        .root_source_file = b.path("src/c.h"),
+    const translate_c = b.dependency("translate_c", .{});
+
+    const translator: Translator = .init(translate_c, .{
+        .c_source_file = b.path("src/c.h"),
         .target = target,
         .optimize = optimize,
+ // additional options now available that go here:
+ // https://codeberg.org/ziglang/translate-c#options
     });
-    translate_c.linkSystemLibrary("glfw", .{});
-    translate_c.linkSystemLibrary("epoxy", .{});
+    translator.linkSystemLibrary("glfw3", .{});
+    translator.linkSystemLibrary("epoxy", .{});
 
     const exe = b.addExecutable(.{
         .name = "tetris",
@@ -21,7 +24,7 @@ pub fn build(b: *std.Build) void {
             .imports = &.{
                 .{
                     .name = "c",
-                    .module = translate_c.createModule(),
+                    .module = translator.mod,
                 },
             },
         }),

Added @backingInt and @fromBackingInt

The @backingInt and @fromBackingInt builtins are new. These builtins replace the now-deprecated @intFromEnum and @enumFromInt builtins (#35966).

@backingInt works with all enums and with bitpacks with explicit backing integer types only. It also works with tagged unions, returning the backing integer of the active tag value. An undefined enum or bitpack yields an undefined backing integer.

@fromBackingInt infers its result type, which may be any enum or a bitpack with an explicit backing integer type. It takes a parameter of exactly that backing integer type. For enums, passing a backing integer that is either undefined or would yield an invalid tag value results in safety-checked Illegal Behavior. For bitpacks, passing an undefined backing integer yields an undefined bitpack.

@bitCast now also performs a safety check for invalid tag values if its destination type is an enum.

Also adds a std.meta.BackingInt function to get the result type of @backingInt.

Zig now requires empty enums to have noreturn as their backing integer because they are uninstantiable.

Upgrade example:

--- a/lib/std/Build.zig
+++ b/lib/std/Build.zig
@@ -145,7 +145,7 @@ pub const Graph = struct {
 
     pub fn addGeneratedFile(graph: *Graph, owner: *Step) Configuration.GeneratedFileIndex {
         graph.generated_files.append(graph.arena, owner) catch @panic("OOM");
-        return @enumFromInt(graph.generated_files.items.len - 1);
+        return @fromBackingInt(@intCast(graph.generated_files.items.len - 1));
     }
 
     pub fn dupeString(graph: *const Graph, bytes: []const u8) []const u8 {
@@ -2607,7 +2607,7 @@ pub const LazyPath = union(enum) {
             .src_path, .cwd_relative, .relative, .dependency => {},
             .generated => |gen| {
                 const graph = other_step.owner.graph;
-                const generated_owner_step = graph.generated_files.items[@intFromEnum(gen.index)];
+                const generated_owner_step = graph.generated_files.items[@backingInt(gen.index)];
                 other_step.dependOn(generated_owner_step);
             },
         }

zig fmt automatically performs this upgrade.

Added @SpirvType

SPIR-V has a number of types, such as images and samplers, that have no equivalent in Zig's type system. Previously, the only way to refer to one of them was through inline assembly, which made it impossible to declare a texture or a storage buffer as an ordinary global variable. Zig 0.17.0 implements accepted proposal #35240, adding the @SpirvType builtin alongside the other type-creating builtins:

@SpirvType(comptime options: std.lang.Type.Spirv) type

• .sampler creates an OpTypeSampler.
• .image creates an OpTypeImage.
• .sampled_image creates an OpTypeSampledImage from an image type whose usage is .sampled.
• .runtime_array creates an OpTypeRuntimeArray. It supports indexing and exposes a len field just like the array type.

Using this builtin when not targeting SPIR-V is a compile error. The options are also validated against the target OS.

spirv_type.zig

const std = @import("std");

const Image = @SpirvType(.{ .image = .{
    .usage = .{ .sampled = f32 },
    .format = .unknown,
    .dim = .@"2d",
    .depth = .not_depth,
    .arrayed = false,
    .multisampled = false,
    .access = .unknown,
} });
const SampledImage = @SpirvType(.{ .sampled_image = Image });

const texture = @extern(*addrspace(.constant) const SampledImage, .{
    .name = "texture",
    .decoration = .{ .descriptor = .{ .set = 0, .binding = 0 } },
});
const uv_in = @extern(*addrspace(.input) const @Vector(2, f32), .{
    .name = "uv",
    .decoration = .{ .location = 0 },
});
const color_out = @extern(*addrspace(.output) @Vector(4, f32), .{
    .name = "color",
    .decoration = .{ .location = 0 },
});

export fn main() callconv(.{ .spirv_fragment = .{} }) void {
    color_out.* = std.spirv.imageSampleImplicitLod(texture, uv_in.*);
}

$ zig build-obj spirv_type.zig -target spirv32-vulkan

Array Multiplication Syntax Removed

Array multiplication syntax (a ** b) has been removed in favor of @splat.

Migration:

--- a/player/chromaprint.zig
+++ b/player/chromaprint.zig
@@ -35,7 +35,7 @@ pub const Chroma = struct {
     const max_index = @min(window_size / 2, freqToIndex(max_freq));
     const notes: [window_size]u8 = n: {
         @setEvalBranchQuota(window_size);
-        var result = [1]u8{0} ** window_size;
+        var result: [window_size]u8 = @splat(0);
         for (min_index..max_index) |i| {
             const freq = indexToFreq(i);
             const octave = freqToOctave(freq);
@@ -123,7 +123,7 @@ const RollingIntegralImage = struct {
     num_rows: u32,
 
     pub const init: RollingIntegralImage = .{
-        .data = [1]Float{0} ** data_size,
+        .data = @splat(0),
         .num_rows = 0,
     };

Added @divCeil

The new @divCeil builtin performs integer division rounded toward positive infinity, complementing the existing @divTrunc, @divFloor, and @divExact builtins.

@divCeil(5, 3) == 2
@divCeil(-5, 3) == -1

As with the other division builtins, caller guarantees that denominator != 0 and that result does not overflow.

No more std.math.divCeil(a, b) catch unreachable!

@hasDecl Returns true Only for Public Declarations

Previously, @hasDecl returned true for public declarations and declarations in the same file. Now, the behavior is the same independently of which file @hasDecl is in.

hasdecl.zig

const std = @import("std");

const Foo = struct {
    bar: i32,

    const baz = 1;
    pub var quux = "xxx";
};

test "@hasDecl example" {
    try std.testing.expect(!@hasDecl(Foo, "bar"));
    try std.testing.expect(!@hasDecl(Foo, "baz")); // different in 0.17.0
    try std.testing.expect(@hasDecl(Foo, "quux"));
}

$ zig test hasdecl.zig
1/1 hasdecl.test.@hasDecl example...OK
All 1 tests passed.

Allow Dereference and Coercion to Array Pointer of comptime Length Slices

Now allowed:

const slice: []const u16 = &.{ 1, 2, 3 };
const array: [3]u16 = slice.*;
const array_ptr: *const [3]u16 = slice;

void{} Syntax Removed

void{} is no longer valid syntax. Use {} instead (#15213).

errdefer Capture Removed

errdefer |err| {
    // `err` was the error being returned; you could do stuff with it!
    // Like a normal `defer/`errdefer`, you can't `return` or `try` in this block, so you can't change
    // which error is returned; but you can e.g. log it
}

The capture (|err|) is no longer allowed (#23734).

To migrate, split the function into two:

 fn processOneTarget(job: Job) void {
-    errdefer |err| std.debug.panic("panic: {s}", .{@errorName(err)});
+    processOneTargetInner(job) catch |err| std.debug.panic("panic: {s}", .{@errorName(err)});
+}
+fn processOneTargetInner(job: Job) !void {
     const target = job.target;

i0 Removed

i0 is no longer an allowed primitive integer type.

This type was nonsensical, so does not have a direct alternative. However, any uses of it can almost certainly be transparently replaced with u0.

internal and link_once Global Linkage Removed

The internal and link_once tags of std.lang.GlobalLinkage have been removed as they had unclear semantics and incomplete support in codegen and linking (#36956). Any use of link_once is likely served by weak, while the replacement for internal is to simply not @export the symbol in the first place.

Standard Library

• Added f128 support for @exp and @exp2 based on "Table-Driven Implementation of the Exponential Function in IEEE Floating-Point Arithmetic" by Ping Tak Peter Tang, adapted to work with 128-bit numbers (#31846).
• Added std.Io.Semaphore.waitTimeout (#31924).
• Added std.spirv helpers for sampling, querying, and writing images (#36187).
• ArrayHashMap.setKey no longer recomputes the entire index (#32136).
• std.Target.parseCpuModel now returns optional rather than error.
• std.debug.Pdb: deduplicate inline source locations (#35438).
• hash.crc full namespace audit (#35952).
• std.fs.path add appending variants for relative and resolve (#36784).

Deprecations

• std.heap.memory_pool.AlignedManaged removed in favor of std.heap.memory_pool.Aligned.
• std.heap.memory_pool.ExtraManaged removed in favor of std.heap.memory_pool.Extra.
• Deprecated std.builtin in favor of std.lang.
• Deprecated std.meta.fieldInfo in favor of @typeInfo.
• Deprecated std.meta.fieldNames in favor of @typeInfo.
• Deprecated std.meta.fieldTypes in favor of @typeInfo.
• Deprecated std.DoublyLinkedList.pop in favor of std.DoublyLinkedList.popLast.
• Renamed std.gpu to std.spirv.
• Removed std.ascii.indexOfIgnoreCase in favor of std.ascii.findIgnoreCase.
• Removed std.ascii.indexOfIgnoreCasePos in favor of std.ascii.findIgnoreCasePos.
• Removed std.ascii.indexOfIgnoreCasePosLinear in favor of std.ascii.findIgnoreCasePosLinear.
• Removed std.bit_set.Integer.initEmpty in favor of std.bit_set.Integer.empty.
• Removed std.bit_set.Integer.initFull in favor of std.bit_set.Integer.full.
• Removed std.bit_set.Array.initEmpty in favor of std.bit_set.Array.empty.
• Removed std.bit_set.Array.initFull in favor of std.bit_set.Array.full.
• Removed std.enums.EnumSet.initEmpty in favor of std.enums.EnumSet.empty.
• Removed std.enums.EnumSet.initFull in favor of std.enums.EnumSet.full.
• Removed std.mem.containsAtLeastScalar2 in favor of std.mem.containsAtLeastScalar.
• Removed std.mem.readPackedIntNative in favor of std.mem.readPackedInt.
• Removed std.mem.readPackedIntForeign in favor of std.mem.readPackedInt.
• Removed std.mem.writePackedIntNative in favor of std.mem.writePackedInt.
• Removed std.mem.writePackedIntForeign in favor of std.mem.writePackedInt.

StackFallbackAllocator Reworked

StackFallbackAllocator is an abstraction that is useful for the "small vec" optimization, in which common cases can fit on a pre-allocated stack buffer, but rare cases need dynamic heap allocation. The previous design had a few problems:

• There was no way to specify the alignment of the buffer.
• It was generic over the size of the buffer.
• Calling .allocator().get() mutated the type, unlike all other allocators, requiring a runtime safety check.

Now, the buffer is provided as an argument, like most other std APIs that need a buffer.

var stack align(@max(
    @alignOf(std.heap.StackFallbackAllocator(0)),
    @alignOf(Item)),
) = std.heap.stackFallback(@sizeOf(Item), self.gpa);
const allocator = stack.get();

⬇️

var stack_buf: [1]Item = undefined;
var stack: std.heap.StackFallbackAllocator = .init(@ptrCast(&stack_buf), gpa);
const allocator = stack.allocator();

SafeAllocator Introduced

std.heap.DebugAllocator is replaced by a thread-safe allocator with the following guarantees:

• deinit reports all leaks and frees all backing memory.
• All allocation mismatches result in either a panic or segmentation fault.
• Allocations from other SafeAllocator instances cause a panic (if Options.canary differ).
• Double frees and operation (resize, remap, and free) races panic or segmentation fault.

Given the backing allocator does not reuse memory, it does not reuse memory either and most writes after free will segmentation fault or are eventually detected and panic.

std.heap.DebugAllocator and std.heap.Check are deprecated.

Every allocation is trailed by an AllocFooter which contains metadata for the allocation and stack traces. It is protected by a checksum to catch corruption from allocation overwrites and report canary mismatches. An allocation's memory has a minimum alignment of AllocFooter so that the footer is at a fixed offset determined from the allocation size. An allocation's memory is stored either:

• Inside linearly-filled buckets for small allocations.
• Inside an allocation directly from the backing allocator.

To track allocations, each thread maintains a table of backing allocations. The table may be modified by other threads in the case of a producer-consumer operation, so the table is a linked list only expanded by creating new segments. Each thread maintains a linked list of free entries, which may contain entries from other threads' tables.

In the case of producer-consumer operations, acquire/release ordering is assumed to be provided externally. This is also assumed by all other thread-safe allocators that reuse memory as otherwise there would be data races on reuse of allocated memory.

Two fuzz tests have also been added for the allocator. They check that there is no memory reuse, that returned memory is writable, and that it is not overwritten. The multi-threaded fuzz test spawns a number of worker threads which are used for all the test runs. I have run these tests extensively under TSAN.

ArrayList

• getLastOrNull has been deprecated and renamed to last
• getLast has been deprecated in favor of last combined with .?
• lastPtr has been added which returns ?*T

Upgrade guide:

if (list.getLastOrNull()) |foo| {
    // ...
}
const foo = list.getLast();

⬇️

if (list.last()) |foo| {
    // ...
}
const foo = list.last().?;

ArrayList Pointer Stability

This is an enhancement that can help track down ArrayList usage bugs faster (#36239).

Devlog Entry

debug.SafetyLock Gains Support for Shared Locking

The existing lock and unlock methods continue to act exclusively. They should be used when data may be mutated. New methods, lockShared and unlockShared, may be used for shared locking in situations where multiple independent users are reading but not mutating data.

fmt.allocPrint moved to mem.Allocator

try std.fmt.allocPrint(arena, "{s}={d}", .{ x, y });

⬇️

try arena.print("{s}={d}", .{ x, y });

Formatted Printing Enhancements

The "{q}" specifier which escapes strings so that they can appear in double-quoted string literals has relaxed escaping rules such that UTF-8 encoded data can pass through unmangled.

"{qf}" is introduced for double-quote escaping the output of a format().

std.zon.parse Reworked

std.zon.parse now takes struct args and allocates its result from an arena.

Migration guide:

var diag: Diagnostics = .{};
defer diag.deinit(gpa);
const result = std.zon.fromSlice(
    MyZonType,
    gpa,
    source,
    &diag,
    .{},
) catch |err| switch (err) {
    error.ParseZon => std.process.fatal("input.zon: {f}", .{diag}),
    error.OutOfMemory => |e| return e,
};
defer std.zon.parse.free(result);

⬇️

var diag: Diagnostics = undefined;
const result = std.zon.fromSlice(MyZonType, .{
    .gpa = gpa,
    .arena = arena,
    .source = source,
    .diagnostics = &diag,
}) catch |err| switch (err) {
    error.ParseZon => diag.fatal("input.zon"),
    error.OutOfMemory => |e| return e,
}

Some methods were renamed:

• fromSliceAlloc ➡️ fromSlice
• fromSlice ➡️ fromSliceNoAlloc
• The other "from" methods were renamed following this same scheme.

"updateFrom" variants such as updateFromSlice were added. These update an in memory value, overwriting the value's fields with fields specified in the ZON source. This can be useful when using ZON to load configuration files with varying precedence, for example a text editor that has a global config file and a per-project config file.

Rename bit_set Variants and Deprecate the Managed One

Renames the types for consistency, deprecating the previous names and the managed variant.

• std.bit_set.IntegerBitSet ➡️ std.bit_set.Integer
• std.bit_set.ArrayBitSet ➡️ std.bit_set.Array
• std.StaticBitset, std.bit_set.StaticBitSet ➡️ std.bit_set.Static
• std.DynamicBitSetUnmanaged, std.bit_set.DynamicBitSetUnmanaged ➡️ std.bit_set.Dynamic
• std.DynamicBitSet, std.bit_set.DynamicBitSet ➡️ std.bit_set.DynamicManaged (deprecated)

Struct-Of-Arrays Style for std.lang.Type

When doing type reflection, structs and unions return their information in struct-of-arrays style (#35234).

--- a/lib/compiler/Maker/ScannedConfig.zig
+++ b/lib/compiler/Maker/ScannedConfig.zig
@@ -49,9 +49,10 @@ pub fn print(sc: *const ScannedConfig, w: *Writer) Writer.Error!void {
 }
 
 fn printStruct(sc: *const ScannedConfig, s: *Serializer.Struct, comptime S: type, v: S) !void {
-    inline for (@typeInfo(S).@"struct".fields) |field| {
-        try s.fieldPrefix(field.name);
-        try printValue(sc, s.container.serializer, field.type, @field(v, field.name));
+    const info = @typeInfo(S).@"struct";
+    inline for (info.field_names, info.field_types) |field_name, field_type| {
+        try s.fieldPrefix(field_name);
+        try printValue(sc, s.container.serializer, field_type, @field(v, field_name));
     }
 }

Rename lang.OptimizeMode to lang.Optimize

And remove "release" from the enum tag names.

No functional change, however, despite the addition of backwards-compatibile declarations in this patch, it is breaking because expressions that use == or != operators will not able to use the deprecated names.

• std.lang: OptimizeMode ➡️ Optimize
  • Debug ➡️ debug
  • ReleaseSafe ➡️ safe
  • ReleaseFast ➡️ fast
  • ReleaseSmall ➡️ small

lang.Optimize.runtimeSafety

std.lang.Optimize.runtimeSafety is preferred as an alternative to std.debug.runtime_safety since it will offer callsites knowledge about their own module rather than standard library module.

@import("builtin") Deprecations

The redundant constants cpu, os, abi, and object_format in @import("builtin") have been deprecated and will be removed in 0.18.0. Please replace any usage with the corresponding fields on the target constant:

• @import("builtin").cpu ➡️ @import("builtin").target.cpu
• @import("builtin").os ➡️ @import("builtin").target.os
• @import("builtin").abi ➡️ @import("builtin").target.abi
• @import("builtin").object_format ➡️ @import("builtin").target.ofmt

Handle Floats Correctly in mem.eql and mem.findDiff

The functions std.mem.eql and std.mem.findDiff short-circuit when their two inputs are slices to the same memory. This short-circuiting is only correct when the == operator, for the given type, is reflexive. This isn't the case for floats, as for example std.math.nan(f64) != std.math.nan(f64). The change in this PR disables that optimisation when working on float slices.

Previously-failing, now-succeeding tests:

const x: [3]f64 = .{ 42.0, std.math.nan(f64), 3.1415 };
try std.testing.expect(!std.mem.eql(f64, &x, &x));
try std.testing.expectEqual(1, std.mem.findDiff(f64, &x, &x));

Decouple Uri and net.HostName

Uri was sometimes using HostName.validate for host (in resolveInPlace) and sometimes not (in parseAfterScheme). On its own, this was a problem, but the bigger problem is that RFC3986 (Uri) has a much different idea of what a valid host name is than RFC1123 (HostName), and so just making Uri consistently use HostName.validate would make Uri less useful overall.

Instead, all HostName-related stuff has been removed from Uri. Uri.getHost has been moved to HostName.fromUri (without a graceful deprecation, since the semantics are different enough for users to need to evaluate usage sites), while Uri.getHostAlloc has been removed entirely.

Migration guide:

var host_buf: [HostName.max_len]u8 = undefined;
const host = try uri.getHost(&host_buf);

⬇️

var host_buf: [HostName.max_len]u8 = undefined;
// note: the error set is different than it was before since fromUri does validation
const host = try HostName.fromUri(uri, &host_buf);

#36036

Build System

• b.build_root (Directory) ➡️ b.root (Path)
• ConfigHeader.Options: include_guard_override ➡️ include_guard
• LazyPath: getDisplayName ➡️ format ("{f}")
• LazyPath.basename: removed since the value is not known until make phase
• b.findProgram divided into findProgram and findProgramLazy and API future-proofed.
• ConfigHeader fixed; now reports unused values for all styles
• addArtifactArg, addPrefixedArtifactArg ➡️ addArtifactArg2
• addOutputFileArg, addPrefixedOutputFileArg ➡️ addOutputFileArg2
• addFileContentArg, addPrefixedFileContentArg ➡️ addFileContentArg2
• addOutputDirectoryArg, addPrefixedOutputDirectoryArg ➡️ addOutputDirectoryArg2
• addDirectoryArg, addPrefixedDirectoryArg, addDecoratedDirectoryArg ➡️ addDirectoryArg2
• addDepFileOutputArg, addPrefixedDepFileOutputArg ➡️ addDepFileOutputArg2
• addFileArg, addPrefixedFileArg ➡️ addFileArg2

Separate the Maker Process from the Configurer Process

zig build now runs projects' build.zig code in a separate executable than the one that performs Package Management and executes the build graph, making zig build faster for several reasons (#35428):

• The maker executable remains unmodified when build.zig script is edited, and therefore only needs to be built exactly once ("first time setup") after installing Zig.
• The maker executable is built with optimizations enabled, which is starting to become more valuable now that we have introduced --watch and --fuzz.
• build.zig logic can be skipped sometimes depending on what CLI flags are used with zig build.

Furthermore, configuration is now serialized into a compact binary format that can be consumed by third party tooling and is part of the new Build Server Protocol. The prior way of satisfying this use case by forking the build runner is no longer supported.

To render configuration as .zon to stdout, pass --print-configuration.

Cache System Reworked

New features:

• Directory support. Ability for entries added, removed, or renamed in directories to cause a cache miss.
• Metadata mode. Normally, only changed contents causes a cache miss. In metadata mode, when size, inode, or mtime changes, it always causes a cache miss independent of contents.

All four combinations are possible (is_directory=true/false, metadata_mode=true/false). These features are exposed as new API in the Build System.

Since the Zig toolchain is heavily reliant on the caching system, this release also switches to a binary format, saving roughly 25% on file size, which eases a bit of pressure on the file system cache while also simplifying the work the computer needs to do - directly copy bytes from disk rather than parsing text files. The new zig cache-cat subcommand is available for troubleshooting or tinkering with files inside a zig-cache directory.

The cache system also now has the capability to explain why a "miss" happened. The public-facing API of std.Build.Cache has many breaking changes, but outside of compiler tooling, this is an uncommon API to be used, and all the changes make it harder to misuse.

This change has been observed to speed up cache hits by 5-10% (#36822).

Introduce the Concept of Configure Cache Poisoning

If the cache is poisoned means that the configure logic had side effects, or otherwise did something that could not be tracked by the cache system.

This is not to be confused with whether individual steps may have side effects when being evaluated; it has to do with the logic inside build.zig itself. For example, a Run step that prints "hello world" has side effects at make time and therefore does not warrant setting this flag, while checking for the existence of scdoc at configure time in order to choose the default value for a configuration option does.

Keeping the cache pure will make zig build faster, bypassing the configurer process when identical configuration would be generated.

When the cache is poisoned, the maker process will delete the build configuration file upon ingesting it since it cannot be reused.

Ways to poison the cache include calling findProgram, or more directly std.Build.Graph.poisonCache. A better alternative than cache poisoning is to explicitly declare the configuration dependencies with these new functions:

• std.Build.dependOnFileContents - indicates that the build.zig logic depends on a particular file's contents.
• std.Build.dependOnFileMetadata - indicates that the build.zig logic depends on a particular file's size, inode, mtime, and contents.
• std.Build.dependOnDirectoryContents - indicates that the build.zig logic depends on a particular directory's entries.
• std.Build.dependOnDirectoryMetadata - indicates that the build.zig logic depends on a particular directory's last modification date.

Advanced users can override the cache poisoning behavior with a new CLI option:

  --cache-poison[=mode]        Override configuration caching behavior
      pure                     (default) Avoid false positive cache hits
      poisoned                 Don't cache the configuration
      disallowed               Panics when cache would be poisoned
      ignored                  A little poison never hurt anybody

findProgram

Immediately (in the configure phase), searches for an executable on the host that has more than one possible name.

Names are searched in order, observing search prefixes first and then PATH environment variable.

Calling this function poisons the configuration cache, so it is only appropriate when the existence of the program or its output needs to be observed by configuration logic. That's why there is also findProgramLazy now.

findProgramLazy

Creates an anonymous Step that searches for an executable on the host that has more than one possible name.

Unlike findProgram, this function does not poison the configuration cache, however the result cannot be used in the configuration phase, hence the return type being LazyPath.

Returns the LazyPath of the found executable. The search only takes place if the LazyPath will be used by a depending Step.

This API is useful in the following cases:

• The binary is not named the same across all systems (for example "python" vs "python3").
• The binary may be produced by building from source rather than being globally installed and will therefore be possibly found in one of the search prefix paths.

Run Step: Passthru Args

In the Run step, passthru args are all together now, not observable in configure phase whether run args are provided.

--- build.zig
+++ build.zig
@@
-if (b.args) |args| {
-    run_cmd.addArgs(args);
-}
+run_cmd.addPassthruArgs();

This removes a capability from build scripts since they can no longer observe those arguments. In exchange, it means that when changing those arguments, build scripts no longer must be rebuilt from source.

Fmt Step: Options

paths and exclude_paths are now LazyPath lists. There is a convenience method to create them: b.pathList.

--- build.zig
+++ build.zig
@@
-    const fmt_include_paths = &.{ "lib", "src", "test", "tools", "build.zig", "build.zig.zon" };
-    const fmt_exclude_paths = &.{ "test/cases", "test/behavior/zon" };
+    const fmt_include_paths = b.pathList(&.{ "lib", "src", "test", "tools", "build.zig", "build.zig.zon" });
+    const fmt_exclude_paths = b.pathList(&.{ "test/cases", "test/behavior/zon" });

Step.Options: add addOptionPathDirectory

Now, when adding an option that is a file path, one must explicitly choose between (#36876):

• addOptionPath (must be a file)
• addOptionPathDirectory (must be a directory)
• addOptionPathUntracked (opt out of dependency tracking)

Lazy Dependency Ergonomic Enhancements

• Log when lazy dependencies are fetched.
• std.Build.dependency: support lazy dependencies
• Introduce std.Build.dependencyLazy which possibly returns error.LazyDependencyNeeded instead of null, so that you can use try
• When user build functions return error.LazyDependencyNeeded, build system proceeds to fetch them rather than failing configuration.

Removed Ability to Override Build Runner

There is no concept of a "build runner" any more; it has been split into: configurer and maker

This use case is now handled by the Build Server Protocol.

Package Management

All package management functionality has been moved out of the Compiler and into the Build System. This includes the following sub-commands:

• zig build
• zig fetch
• zig init
• zig libc
• zig cache-cat

This means that large parts of what used to be included in the compiler executable are now shipped in source form instead, including:

• package fetching logic
• http client and networking
• TLS (Transport Layer Security) and associated crypto
• git protocol
• xz, gzip, zstd, flate, zip
• parsing, validation, and otherwise dealing with build.zig.zon files

All of this functionality is now compiled in -Osafe optimization mode rather than -Ofast due to being in the compiler. When hacking on the build system itself, the environment variable ZIG_DEBUG_CMD=1 may be used to compile the build system in debug mode instead.

Miscellaneous changes:

• Bug fix: reject path deps that escape the parent package root.

Ability to Override Package Path

--pkg-path CLI arg and ZIG_LOCAL_PKG_DIR env var are now observed for both fetch and build commands.

Global vs Local Fetching

Now zig fetch only fetches into the global cache, just like it used to. However, if --save (or any variant) is used, then it also fetches into the local package path. When fetching globally, does not require build.zig to be present. zig build always fetches locally (in addition to globally).

Notably, this fixes the regressed use case zig fetch .

When fetching by path, the hash is always computed, recompressed tarball is always created, always overwrites any existing global cache entry.

Slight Difference in PATH for DLL Arguments

It used to be the case that, when targeting Windows or Wine, artifact args added to Run steps modified PATH based on the set of directories containing the recursive set of DLL dependencies. Now this is only done for argv[0]. The motivation for also doing this for the other command line arguments is unclear, since those DLLs don't need to be loaded in order to execute argv[0].

Build Server Protocol

Now, when --listen=- is passed, the build system serves a protocol that allows connected clients to monitor and control the build graph as it executes. This is intended to be consumed by third-party tooling such as IDEs.

Current things you can do:

• Get full access to the entire build graph's static, post-configuration information, such as which build steps are available, which options are set, dependencies, etc. There are a couple things yet to be included, such as the exposed set of module names.
• Get notified when a build step starts and completes, including information about errors and which files were generated.
• Request specific steps to build.

In particular, the separation of maker process and configurer process is a breaking change that prevents the ZLS project from working with 0.17.0. Although some progress was made to restore functionality in this release cycle, Zig team and ZLS team are still working together to enhance the build server protocol further to the point that ZLS can not only restore functionality, but surpass the power and capabilities compared to before.

In the future it is expected for much of Zig's own first-party build system tooling to become a client of the build server protocol, dogfooding it to ensure that third-party tooling enjoys equivalent capabilities (#36497).

It is also planned for the build server to multiplex compiler server protocol for the compilation steps, providing type-system information, refactoring, and other advanced editing capabilities (#615).

Compiler

Incremental Compilation

The Zig compiler's implementation of incremental compilation—a feature allowing near-instant rebuilds of projects after changing the code—has been significantly improved in Zig 0.17.0. Many bugs have been fixed, and the new ELF Linker introduced in the previous release has gained good support for the feature.

Thanks to these enhancements, it is now possible for most projects targeting x86_64-linux to take advantage of incremental compilation. To do so, add the arguments -fincremental --watch to your zig build command (e.g. zig build -fincremental --watch)—this will cause the Zig build system to listen for changes to source files, and react to them by performing an incremental rebuild.

For more information on ways to use incremental compilation in your own projects, or to learn more about how this feature works under the hood, consider checking out this blog post by a Zig core team member.

Future releases will continue to focus on improving this feature, including introducing a new Mach-O linker and self-hosted aarch64 Backend with good support for incremental compilation; adding support for using incremental compilation without --watch; and fixing any remaining bugs.

SPIR-V Backend

The self-hosted SPIR-V backend is now multi-threaded like the other backends.

Execution modes such as LocalSize and OriginUpperLeft are now derived from the function's calling convention instead of being set through inline assembly, and the new spirv_task and spirv_mesh calling conventions add support for task and mesh shaders (#35676).

Declaring capabilities and extensions in inline assembly with OpCapability and OpExtension is no longer allowed. They are enabled through target CPU features instead, i.e. the -mcpu option.

22 bugs were fixed in the SPIR-V backend during this release cycle.

aarch64 Backend

Progress towards this is blocked on Linker enhancements, many of which were completed during this release cycle.

loongarch Backend

Initial implementation of self-hosted backend for loongarch64 has been contributed (#36418). It is still experimental and not yet usable. There are two ways to contribute to this backend: working on it directly, and contributing to AIR Legalization Features, which helps all unfinished backends reach the finish line quicker.

WebAssembly Backend

Zig's WebAssembly backend is now passing 2060/2054 (100%) behavior tests compared to the LLVM backend. However, it is not yet the default when compiling in debug optimization mode due to lack of debug info support (#37032).

Linker

ELF

This release makes significant progress towards replacing Zig's legacy self-hosted ELF linker with its new implementation introduced in the previous release. Specific enhancements include:

• Full x86_64 support
• Full SPARC64 support
• Partial Loongarch support
• Static library generation
• Shared library generation
• Errors for undefined symbols in executables
• GOT generation
• Copy relocations
• GNU symbol versioning
• DWARF debug information
• Symbol hash table generation
• Mostly-reproducible binaries
• Arbitrary section alignment
• Support for small host file system block sizes

While this linker has not quite reached feature parity with our old self-hosted ELF linker yet—and so remains disabled by default—it is already capable in practice of building the vast majority of Zig projects targeting x86_64-linux. This unlocks the ability to use Incremental Compilation for these projects—like in Zig 0.16.0, the new linker is enabled by default in this case.

In the next release of Zig, we hope to fully eliminate the legacy ELF linker in favour of this implementation.

COFF

COFF support in

From ever-increasing subscription prices to outages and data harvesting: we don’t like what the cloud has come to represent. So we’re redefining what an online service should be: private, optional, and free from lock-in or walled gardens.

That’s why today Nabu Casa is renaming Home Assistant Cloud to more accurately describe what the service actually does, and to better reflect our values. Allow us to introduce:

Home Assistant Link

I’m Carl, Vice President of Commercial at Nabu Casa. You probably know us as the folks making all that sleek, highly optimized Home Assistant hardware. Beyond hardware, we also manage and run Home Assistant Link, and as one of the Open Home Foundation’s commercial partners, we’re here to help fund all their amazing work. We feel pretty passionately about the word cloud, and we’d love to explain how the old name never fit, and why Link finally does.

Created for the community

Home Assistant began with a group of core developers working nights and weekends alongside their regular jobs to create the platform – a good recipe for burnout, and one that has ended plenty of similar open source projects. So in 2018, we founded Nabu Casa and created Home Assistant Cloud to make sure that didn’t happen.

Home Assistant Cloud set out to make Home Assistant easier for more people to use, starting with a problem many of you had: reaching your Home Assistant when you’re not at home, without having to spend a weekend on it. It was also built to make Home Assistant’s development sustainable.

The intent was never to just ask for donations, but to build an optional service that benefited the community and funded the work at the same time. The majority of profits from subscriptions now fund the Open Home Foundation. That money supports everyone working on Home Assistant – from salaried staff to volunteers – keeping the project sustainable. That shift took Home Assistant from a passion project to one that could invest back into its community, and one that could stick around for the long haul.

A breath of fresh air

We even took it out of the Nabu Casa logo… did we take this too far? 🤔

We had a service that we and the community loved, but the name just didn’t feel right. For example, there were times when Paulus, founder of Home Assistant and President of the Open Home Foundation, was on stage saying “don’t buy products that require the cloud to work,” then in the next breath having to explain how Home Assistant Cloud is different, despite the name. That created unnecessary friction.

It also caused confusion, since some new users thought (and continue to think) Home Assistant Cloud is a way to run Home Assistant in the cloud. This has never been the case, because we believe Home Assistant should always be run locally, in your home.

Big Tech has given the cloud a bad name, and while Link does run online, it is very different from other cloud-powered smart home services:

Home Assistant Link	A Big Tech cloud
Optional: your smart home will still work without it, lights and all.	Required: all or most features won’t work without it.
No lock-in: you can use this service or someone else’s, and you’ll never be stuck.	A walled garden: you’ll be locked into that one service, and all its outages or price increases.
Your data’s private: your data is yours, and will always stay that way.	Your data’s monetized: you’re the product, and your data is used for ads, AI training, and sometimes sold to third parties.
Funds a nonprofit: Nabu Casa contributes the majority of profits from subscriptions to the Open Home Foundation, supporting their fight for privacy, choice, and sustainability.	Funds investors first: profits flow to shareholders, debt repayment, and a bunch of other stuff first, and funding developers is an afterthought.

Your subscriptions help sustain Home Assistant, but we’ve been clear from the beginning that you do not need Link to use the platform. We hate what Big Tech has done to smart devices, turning them into paperweights when they drop support. Thermostats that can’t be scheduled or cameras that can’t detect motion, giving the smart home a bad reputation and making a mountain of e-waste. By not using Link, you’ll miss out on some extras, but that’s all they are: extras. And if you do use Link but have to unsubscribe, your smart home will keep working.

Big Tech treats your data as a commodity and a tool for mass surveillance: sold to advertisers, used to train AI, and dealt to third parties for the best price. We think this is morally bankrupt. That’s why when you use Home Assistant Link, your data is encrypted, and only you have the key. Neither Nabu Casa nor the Open Home Foundation want your data, and we work hard to never have an opportunity to see it.

This is what tech serving people looks like: data that’s yours, and a smart home that answers to you – not corporate shareholders.

Choose your own path

Many of you build DIY projects to customize your setup, and Home Assistant isn’t going anywhere on that front. But for those who’d like a simpler approach, Link makes using Home Assistant easier, opening up the local and private smart home to more people. For example, connecting to Alexa and Google Home can be complex to set up yourself, but Link allows you to… ahem… link them to Home Assistant without the hassle. Not having the time or know-how shouldn’t be a barrier to using the platform, and Link ensures it isn’t.

On top of things that can only be done online, there are other features that just work better with Link’s connected services. For instance, online speech-to-text tends to be faster, supports more languages, and is more reliable than self-hosted alternatives. Likewise, Link offers a way to store a backup online, so your data is always recoverable while remaining private. Plus, if you run into trouble with a feature, we have real humans you can contact to help you out. You heard that right. A real person.

See everything at a glance on our new account page.

We’re also constantly improving the service and are now working to add new features. You may have noticed the new, easier-to-use account page, the speech-to-text Labs test, or the new settings page in Home Assistant with a setup wizard. What you probably won’t notice is the massive backend update to improve the responsiveness of your remote access (we’ve migrated to a new bare-metal setup that always tries to get you on the closest server, and it’s fast 🏎️). Most importantly, these updates let us add new security features, account management tools, and more.

What’s in a name?

In the end, our actions speak louder than product names, and we’ll continue to run a subscription that’s about privacy, transparency, and not locking users in, all the while supporting the development of Home Assistant.

Whenever features get renamed, we always come to you, the community, first. Even though this is a service from Nabu Casa, Home Assistant is a community project, and we value your opinion and thoughts. Love the new name? Something we didn’t consider? We’re all ears. We intend to make the name change official in the December 2026.12 release, so please provide all your feedback well before then! 👇

Here are the 30+ questions in the matchmaking tool that Singapore is deploying on government workers.

Those signing up to the FirstDate pilot programme must first complete a questionnaire of over 30 questions.

Three years after the demise of the Social Development Network, it looks like a new government-run matchmaker is back on the cards for Singapore.

Earlier this month, a pilot progamme by GovTech called FirstDate was announced, with government workers set to be the first batch of daters. If this sounds familiar, that’s because I was the first to report on GovTech testing the waters with this idea all the way back in April for The Straits Times.

How will the matchmaking work? What questions are even in the matchmaking questionnaire? (Read on for the full list)

On FirstDate’s website, one line stands out: “FirstDate uses a Nobel prize-winning framework called the Gale-Shapley Stable Marriage Algorithm”. It’s a brow-raising detail because, despite the name, the algorithm has almost nothing to do with marriage, but more on this later.

The dating service will use Singpass to verify the identity of users, match people in cycles (you get only one match each cycle), and share contact details only when both users agree to their match.

To get a sense of how the matchmaking works, here’s the questionnaire that the government workers signing up must fill out. The questions are a mix of close-ended and open-ended ones, across 8 categories, spanning topics like interests and passions, lifestyle and daily habits, and communication and relationship style.

These are the questions:

1. What are you into these days? (pick up to 5 out of a checklist of items like gaming, film and cinema, volunteering, cafe-hopping, etc)
2. Now, spill! What do you actually love about your hobbies? (open-ended, optional)
3. What cuisines do you eat on repeat and never get sick of? (pick up to 3 out of a checklist)
4. Which restaurant do you keep going back to and why? (open-ended, optional)
5. How often do you find an excuse to leave the country? (close-ended, with options like every chance I get (4+ trips a year) to I prefer staying in Singapore (never))
6. What kind of traveler are you, really? (close-ended, with options like adventure junkie, culture seeker, and I don’t travel much)
7. What’s a country that’s ruined all other countries for you? (open-ended, optional)
8. Team sunrise, or team “it’s 2am and I’m still up”? (close-ended)
9. Gym rat, occasional jogger, or exercise is a myth to you? (close-ended)
10. Any food rules we should know about? (close-ended, with options like vegetarian, pescatarian, halal)
11. Do you smoke? (close-ended)
12. Be honest! What does your room look like right now? (close-ended, with options like spotless, organised chaos, and tidy up only when needed)
13. Hustle mode, or protecting your personal time? (close-ended, with options like career comes first right now and personal life comes first)
14. Real talk. How much of your day disappears into your phone? (close-ended)
15. Describe your social energy. Are you the life of the party, or the one who left an hour ago? (close-ended)
16. How important is it for you that a match brings the same energy, or do opposites attract for you? (close-ended)
17. After a brutal work week, what’s your reset button? (close-ended, with options like alone time at home and going out and socialising)
18. New city, new hobby, new anything. How do you feel about the unknown? (close-ended, with options like love it and prefer to stick to what I know)
19. When you’re feeling a lot, what do you actually do about it? (close-ended, with options like express openly and through actions rather than words)
20. How do you like to be loved? (close-ended, pick up to three, with the five love languages as options)
21. How do you express love? (close-ended, pick up to three, also with the five love languages as options)
22. Non-stop texting, or comfortable silence. Where do you land? (close-ended)
23. Mid-disagreement, what’s your gut instinct? (close-ended)
24. Paint us a picture. What does your dream first date look like? (open-ended, optional)
25. What are your non-negotiable green flags in a partner? (pick 3 that matter most to you, out of options like kindness, humour, and honesty)
26. Are you always working on yourself, or is “good enough” good enough? (close-ended)
27. Do you see yourself having children? (close-ended, with options like yes, open to it, and definitely not)
28. Saver, spender, or “I’ll figure it out eventually”? (close-ended)
29. What’s your religion, if any? (close-ended)
30. Any hard nos for you? Be honest, we won’t judge. (close-ended, optional, with options like smoking, different dietary needs, and someone of a different religion)
31. What’s the youngest age you’d consider dating? (open-ended)
32. What’s the oldest age you’d consider dating? (open-ended)
33. Write a short note for your future match! Tell us about yourself in a few sentences. (open-ended)

After a question about the name you prefer to go by and your mobile number, the questionnaire also collects information about how many first dates you’ve been on in the past year, whether you’ve used a dating app or matchmaking service before, and when you last went on a first date.

An earlier prototype of GovTech’s dating service proposed free meals for first dates, which is what I assume all the food-related questions are for.

But how will the rest of the data collected through these questions be used? The fascinating history of the Gale-Shapley Stable Marriage Algorithm (also known as the deferred acceptance algorithm) gives us some clues.

Before the algorithm earned its name, a similar system was used to match medical school residents with residency programmes in hospitals in the United States since the 1950s. After an interview process, doctors and hospitals provide a rank ordered list of their preferences, which the algorithm turns into a stable match.

What makes the match stable is that after all the matching has concluded, no pair would rather be paired with one another over their current partners.

Confused? This YouTube video explains it better than I can:

What made the algorithm so novel was that it proved that such a stable match always exists when there are equal participants of each type (and that there is a solution to achieve it). The 2012 Nobel Prize in economics went to one of the mathematicians who developed the algorithm (Shapley) and an economist who pointed out the medical resident example and used it to develop other real world applications.

It’s called a marriage algorithm because the theory used marriage proposals as a memorable but theoretical example. The real world applications of the algorithm (like school choice systems) tend to have little to do with dating, for reasons that I’ll elaborate on below.

What does this mean for those signing up to FirstDate? Well, the algorithm is why FirstDate’s matching takes place in what its developers call “cycles” or “programmatic rounds”.

Presumably, the algorithm uses each user’s questionnaire answers to rank all participants of the opposite gender based on compatibility. The algorithm then matches everyone until all couples are in stable matches (see above).

After you decide to say yes or no to your match, that’s it for the cycle. You’ll have to wait for the next one to get a new stable match with a new pool of participants.

Why dating is not game theory

From my perspective, there are three glaring issues that emerge when applying this kind of game theory to dating:

Problem 1: The algorithm was intended as a solution to a matching problem where there are two groups of people that need to be paired with the other, such that no two people would both prefer each other over the partners they are assigned.

This is not a guarantee that the match will be a satisfactory or happy one. It is only a guarantee that they will not prefer someone else who also prefers them in the pool. (Side note: While the nature of the algorithm might imply that same-sex pairings are not possible, other dating-related implementations of the algorithm have allowed for same-sex pairings. It is doubtful that this will happen here though, because, well, Singapore.)

This is why the algorithm has been so useful in contexts like matching medical school residents to hospitals, school choice systems, or matching US army recruits to their units. These are matches that participants have committed to, even if the outcome is not their ideal or top choice.

All of this is further complicated when there are outside options. Like, say, other online dating services or your workplace crush who isn’t participating in the process. Because there is no commitment to the process (because this isn’t your state-assigned waifu, thank god), the maths that underpins the algorithm doesn’t really make sense.

We just need to look at the biggest example of a dating app using the Gale-Shapley algorithm: Hinge. The company claims to use the algorithm, using your past behaviour to deliver the “most compatible” matches that you occasionally see surfaced to the top of your feed. Are they the most compatible within the app? Possibly! Do you care? Probably not!

In short, stable matches mean nothing when nobody is committed and the best options might exist outside of the matchmaking pool.

In 2024, I interviewed one of the folks behind the Aphrodite Project, a university-based matching system that spits out just one ideal match each year, using a modified version of the Gale-Shapley algorithm. Their users definitely don’t experience swiping fatigue, but, notably, even with just the one algorithmically-determined match each cycle, people still get ghosted.

Problem 2: The algorithm was designed to match people in terms of ranked preferences.

This becomes an issue when the questionnaire includes open-ended fields and ambiguous questions without a clear objective indication of how it translates to preference, in that it often conflates who you are with what you want. For instance, if you value humour in a partner, does that mean that you’re a good match for someone who also values humour in a partner?

If you’re a gym rat, does that mean you also want to match with other gym rats?

Another sign that a questionnaire isn’t the best way to understand preferences is that the forerunner example of the algorithm in action had medical residents and hospitals submit their preferences after they had conducted interviews with each other.

Basically, the information gathering process matters for determining what one’s preferences even are and it isn’t clear that a questionnaire is the ideal way for daters to signal their preferences to each other (or in this case, an algorithm), despite what the creators of OKCupid and compatibility questionnaires in lifestyle magazines might argue.

Will indicating that you’re a gym rat or a hustler match you with other gym rats and hustlers? Girls, if you’re looking for a himbo on FirstDate, I think you know how you should be answering question 9.

Problem 3: Finally, and most importantly, it is not at all logical that dating successfully is about finding the person who most matches your stated preferences. In this regard, FirstDate is really not unlike the online dating apps that it is looking to innovate on.

This point is so important that it bears repeating: The problem with modern dating is not simply a problem of mismatched preferences!

What’s wrong with online dating today

According to FirstDate’s website, it “started with a question among a group of GovTech officers: does having more potential matches necessarily make it easier to find a suitable match?”

This is a similar diagnosis to what the folks behind the Aphrodite Project came to, but I feel that it captures an incomplete part of the whole picture.

The rise of online dating paralleled the rise of a particular way of thinking about love that’s more checklist oriented than it is holistic, where daters increasingly screen their options ahead of time against a predetermined list of green and red flags.

This checklist of things is, in my view, one of the biggest issues with online dating, in that it tends to amplify and exacerbate our personal biases rather than inviting us to step outside of them. What’s the common denominator to being constantly unlucky in love? Why that, dear reader, is you.

How does a system for matchmaking people account for the fact that the people who need matchmaking also tend to be the worst at understanding what they really want in a relationship?

Let me paint you a picture of what seems to be the common dating experience in Singapore: You’re on a first date with someone in a chain restaurant in a mall somewhere in central Singapore. The conversation revolves almost entirely around the biodata and information that HR and recruiters would collect from you.

Where do you live? Where did you study? What job do you have?

An earlier prototype of FirstDate had a free first meal as its headline item. Read the full story here.

There’s nothing innately wrong with having preferences relating to these things, but dating that’s all about these preferences betrays a deeply transactional and instrumentalist view of love that sees other people not as potential life partners, but pathways to potential lifestyles. Not lovers, but co-owners of a financial venture. Not people, but breeders of sought-after children.

It’s a mindset that’s enabled by the market-driven logic of dating apps, where we commodify ourselves to score swipes. It’s also a mindset that gives intensely unattractive only child energy.

In Singapore, this transactional view is only sharpened and reinforced by policies like the BTO system for public housing, where the rational move for financially savvy couples is to apply before marriage, often while one is still studying, so that they can get the best subsidies.

For these couples, it means that they’ll likely have spent no time at all living with their partner-to-be, and navigating messy questions of how you actually are in states of boredom and stress. Instead, they’re spending all their time planning for their financial futures and screening their partner in terms of their viability for a rigid life path.

The algorithm does not fix or challenge this HR interviewer mindset. It actually requires it and makes it the primary lens through which to view love.

It says something that FirstDate specifically excludes those aged 36 and up, who are too old for loving, it seems. Or, as some commentators point out, too old to breed and increase the fertility rate.

It is also telling that before the launch of FirstDate, its developers sent out a survey to prospective users on CrowdTask (the government’s survey platform) asking them why they want to be in a relationship.

In April, GovTech sought public feedback for a potential government-run dating service. This was one of the survey questions.

The options included “overcoming loneliness”, “creating a family unit”, “financial partnership”, and “social expectations” but not, you know, LOVE. As in, the kind of love that isn’t selfish and totally centered around what your partner can do for you.

Perhaps that’s filed under “other” or “enjoying romantic intimacy”?

This is not me saying that shared values are not important. Studies do indicate that the couples that do end up together tend to have similar values. But that is not the same as screening your partners based on adherence to your ideas of what hobbies, love language, or dietary preferences they should have.

What I am saying is that perhaps, we shouldn’t be treating our choice of partners with the same mindset as how we approach schools and jobs, through the lens of competition in pursuit of optimal choices. Or through an algorithm used for matching people to their schools and workplaces.

Incels and the gamification of online dating

I wish I could send this meme to FirstDate’s developers. And also, my proposal for what GovTech could do instead (see below).

To be clear, I do think that this GovTech pilot programme is an admirable initiative. More experimentation in the public sector is always a net positive, and I hope this doesn’t read as me just clowning on a good faith attempt at fixing what’s wrong with online dating.

There are clear benefits to a model of online dating driven less by profit incentives and shareholder value, and driven more by user needs.

Notably though, this isn’t the first attempt at a state-run matchmaker. I find it hilarious that the previous effort, the Social Development Unit (SDU), has a Wikipedia page with a section dedicated to how people used to joke that it stands for ‘Single, Desperate and Ugly’.

The similarities between FirstDate and the SDU (and later, the Social Development Network) go beyond the involvement of the state. As this 1992 article from American libertarian magazine Reason points out, the SDU too analysed its matchmaking pool’s responses to questionnaires to compute a list of compatible dates. The Singaporean urge to quantify and computerise is a long-running one.

Still, if the goal of FirstDate is to make a better product than dating apps, they’ve already succeeded (for hetero sinkies aged 21 to 35). But, mind you, the bar is in hell.

The dating app industry has long made the exploitation of the artificial scarcity that it creates in online dating its primary source of revenue. This is coupled with the perception of perpetual abundance, the idea that there’s always somebody better out there, so it can keep dangling ever more matches and paid-for features to woo them with. All of this so Tinder can milk as much profit out of you as possible. Online dating is the archetypal example of enshittification.

I’m not convinced that a better algorithm is the solution (though I’d be glad to be proven wrong). Really, the clamouring for it is symptomatic of our redpilled and incel-inflected times.

The truth is that we don’t really know what exactly makes love work, such that we can articulate and implement it on a societal scale. It’s too messy, too complex, too idiosyncratic, and too human. Anyone who claims otherwise probably has a course to sell you on negging and pickup artistry.

This is why even spending US$65,000 on the highest-end matchmaking is not a guarantee that you’ll find love.

The techno-solutionist idea that an algorithm will solve love is borne of the same mindset from which inceldom springs. This is a narrative that permeates so much of the online discourse surrounding dating today: I bought the meals, spent so much time offering my shoulder to them, gave so much of myself to them, and they still chose someone else. This entitlement feeds into the self-victimisation: they’re all just gold diggers, people only value appearance, nice guys finish last.

People feel entitled to love from the people that they want, seeing others not as ends in themselves, but a means to achieving some long-for happiness. This worldview is so persistent precisely because of the inherently market-driven logic of online dating. In today’s social culture, this logic has become inescapable, manifest in how formerly fringe terms like looksmaxxing and looksmatching have entered the mainstream lexicon.

It is no coincidence that the hierarchical and self-commodifying nature of dating apps (and algorithmic matchmaking) is frighteningly similar to the hierarchical and deterministic worldview of incels and pick-up artists. (I want to scream: love is not a rank ordered list!!) After interviewing incels and former incels, I came away with the sense that yes, the solution is to go outside and ditch dating through a screen.

Rather than creating an off-ramp from a system of alienating self-commodification, FirstDate creates another platform for people to game.

There’s a good reason why Singaporeans are still – according to surveys by the National Population and Talent Division at least – more likely to find love through offline methods (their schools, workplaces, family friends) than online channels.

This is not only because these are situations where one’s stated preferences melt away to reveal their actual personality, but also because boredom, hardship, and chaos are the things that reveal whether your personalities actually work together. This is otherwise known as chemistry.

What’s worrying is that all of these offline methods (with the exception of social activities and places of leisure) are declining as channels for meeting prospective partners. That people are increasingly meeting their partners through social activities is a promising sign though.

In my view, the problem of dating in Singapore has less to do with what technical tools are available to us, and more to do with the decline of the nation’s third spaces, the nightlife scene, and places for people (both the youth and those aged 36 and up) to just be. A better solution would be to invest in these spaces.

Make dating fun again

The urge to quantify compatibility is understandable. This is Singapore after all, a country where we just can’t resist tying our self worth to a score. But, even a casual look around you at the couples that do work would tell you that this impulse to quantify defies logic.

If the man I’m marrying in January were to fill out this questionnaire, he’d probably fill it out like an introspective soft boy and express a preference for softspoken people that fit into that lifestyle.

If I were to fill out this questionnaire (as a queer person, this is strictly a hypothetical), I’d fill it out like a demon twink that wants a partner in crime to party with all the time.

The result would likely mean being matched up to somebody like our exes.

Instead, we met over Grindr, an app where one has little to go off of besides appearance, distance, and sexual compatibility. And over the next year, he became my plus one to all the nightclubs and bars and parties I write about as a lifestyle journalist. And he, in turn, drags me out to the fandom conventions and game jams that he loves (and that I admittedly am lukewarm on). I fell in love with him on the dancefloor, and he fell in love with me during the quiet times in between.

I’d argue this surprise and unpredictability is key to finding chemistry.

And, also, that there’s something deeply unsexy about someone setting you up with someone who is perfect for you on paper. We spend so much time in the rat race, surely love should be the one space free of optimisation at all costs.

So, here’s my proposal: Let’s fund culture clubs, theatre groups, video game conventions, music festivals, whatever!

Instead of promoting them as places where people can come to meet their prospective partners (you’ll be accused of trying to resurrect the Single, Desperate, and Ugly club), let’s bet that happy and fulfilled people with friends and access to thriving third spaces will couple up if they want to.

Instead of ramming pro-fertility rhetoric down our throats, let’s focus instead on eroding the barriers that so many people feel when it comes to being part of a community, like the steep cost of just existing in public in capitalist Singapore or the exorbitant cost of late night transportation or the reality that it’s hard to have friends over (let alone a prospective date) when one is expected to live with their family until their 30s.

Let’s focus on broadening the extremely narrow horizon of social possibility in Singapore, where everyone complains that there is no nature, no culture, and nothing to do but eat and sleep and travel. Is it any wonder that an earlier prototype of FirstDate places such a big emphasis on free first meals? What else is there to do?

If this sounds like a radical solution to you, it’s only because you haven’t been paying attention, because it’s already happening.

Take a look at the sober rave (and friendship festival) at Funan co-organised by the Ministry of Social and Family Development (MSF) in 2025 that most participants probably didn’t even realise was a government-led operation.

It offers a fascinating window into what government-funded culture activities that are also not-so-secretly trying to get people to make babies could look like. Festival attendees were literally handed out bracelets to signal to other attendees their openness to a relationship, and yet, the reception from everyone I spoke to was almost unanimously positive (towards the event, not the bracelets).

Customising your bracelet at the For Real Fest 2025.

In a time of shuttering nightclubs, bookstores, theatre groups, and whatever else you’d consider a common social space, I’d argue that this kind of support is badly needed. And, I would wager that MSF’s bet on third spaces is more likely to produce happy couples (and babies, if you care about that) than this.

If we must introduce some kind of app-based solution, have people match themselves to the things they want to do, rather than the people they want to have. I would argue that this is far more revealing of one’s character than a questionnaire, and also, far less alienating.

Let the cosplayers meet their kindred souls at the government-funded con. Let the book lovers meet at the talk at the indie bookstore. And let the nightlife enthusiasts meet at the sober (or not so sober) rave.

And if you don’t get the love of your life out of it, well, at least you’ll have had a good time doing it.

If you want to see how far U.S. sanctions can reach, ask Kimberly Prost's Alexa.

After the United States sanctioned her, the Canadian judge at the International Criminal Court began losing access to services from companies in different countries. Her credit cards were also canceled.

"You start to lose services from American companies, Amazon, Google, potentially Apple, whatever it may be," she told Morning Edition. "Completely randomly, though, you don't know when something's going to happen."

One of those moments came during an ordinary moment at home.

"I went home and Alexa wouldn't talk to me," she told NPR's Steve Inskeep.

Her credit cards, issued in the Netherlands and Canada, were canceled. She has managed to keep some bank accounts, but says her banking services are extremely limited and even small transfers can be blocked.

The sanctions themselves are American. Still, businesses abroad may comply because they have ties to the U.S.

"We have this massive overcompliance by companies," she said.

One of the most serious examples is her health insurance. Prost receives coverage through AXA, the French company that provides insurance for the court. She says the company has refused to pay her claims even though it is not legally required to follow the U.S. sanctions.

"It's a business decision," she said.

Her phone still works — "so far" — but some email, cloud and other technology services are limited.

She has lived with the restrictions for more than a year.

Why was she sanctioned?

Prost said her sanction stems from Trump's executive order targeting ICC officials involved in cases concerning Israel and Gaza or Afghanistan.

Her own case goes back six years.

At the time, Prost was temporarily serving on the ICC's Appeals Chamber when prosecutors sought authorization to open an investigation into alleged crimes connected to the war in Afghanistan. Prost and four other judges unanimously approved the request.

The investigation covered alleged crimes involving the Taliban and ISIS and included what Prost described as "a small component related to the United States."

That U.S. component was never pursued and was later deprioritized by prosecutors, she said.

"And it is for that decision that I'm sanctioned," Prost said.

Her role was judicial, not investigative. She said the appeals judges were required to decide whether prosecutors had the proper legal basis and jurisdiction to proceed — similar, she said, to a judge authorizing a search warrant.

"There is no investigation related to the American component in Afghanistan, and I have nothing to do with the Israel-Gaza situation," Prost said.

Her designation came amid a much wider confrontation between Washington and the ICC that intensified after the Oct. 7, 2023, Hamas-led attack on Israel and the ensuing war in Gaza.

For Prost, the broader concern is what sanctions like these mean for judges on international courts making decisions from the bench.

"We are judges, and we are being told that rather than deciding our cases on the basis of the facts and the law before us, as we are duty bound to do, we're being asked to decide the cases or not decide them in accordance with the wishes of the U.S. government," she said.

By August 2026, nine of the court's 18 judges were under U.S. sanctions, along with both deputy prosecutors, its former prosecutor and one staff member.

The Trump administration has threatened to go further, announcing what it called a "whole-of-government campaign" to "systematically dismantle" the ICC over its investigations involving Americans and Israelis.

NPR reached out to the State Department for more information about whether and when the administration plans to impose additional sanctions on the court. The department did not respond.

Prost is challenging the sanction in U.S. court. In June, she and fellow ICC judges Reine Alapini-Gansou and Solomy Balungi Bossa sued President Trump and other administration officials in federal court in New York, arguing that the measures were unlawful.

The work goes on in The Hague

For now, the sanctions have changed how she lives outside the courtroom, but not the work she continues to do inside it.

Her current case involves alleged crimes tied to the jihadist takeover of Timbuktu in Mali, including persecution, torture and inhumane treatment.

"I will never quit my job as a judge," Prost said. "These methods that they're using, these coercive measures, are completely futile."

She said she and other sanctioned judges and prosecutors continue to do their jobs "objectively, independently and in accordance with the oath that we've taken."

[Epistemic status: intuitions and anecdotes.]

Recently, several posts and projects (Thoughts Memo, Babel Translation, Please Give Them a Chance) have taken important steps towards raising AI safety awareness and sharing rationalist philosophy in China. It’s great that we’re recognizing the importance of solving the messaging problem for China, and thus laying the groundwork for an international AI pause. Below I record my perspective on cultural differences which are relatively underdiscussed, which may become roadblocks to this communication program.

Background: I’m a “first-generation” Chinese-American who moved to the States at the age of four. The beliefs in this essay are primarily drawn from interactions with my parents and their generation of immigrants, and from consumption of Chinese media (dramas, webnovels, games, and manhua) which are not necessarily representative of the realities on the ground. I am likely over-indexed on the older generation and internet culture, and would appreciate corrections from folks who have direct lived experience. The picture I aim to paint is also complicated by a massive generational gap, and my understanding is that some of the below sentiments (e.g. the cynicism and nationalism) are partly inherited by the younger generation, and partly rejected through a variety of countercultures.

Briefly, I point to four axes along which China is strikingly different. These differences are not black-and-white, but I think if you take the liberal middle-class western bubble I live in and shift the mode ~1 standard deviation in these directions you would get a substantively more accurate model of China:

1. Chinese social media is like American junk food. Chinese people find American food disgusting: inauthentic slop inundated with additives and high fructose corn syrup. Westerners will find Chinese social media similarly disgusting: uncanny-valley filters are everywhere, and social media is omnipresent in every corner of life.
2. Primacy of social reality, and of shame and “face.” Shame is seen as something that just works in China, and is the dominant lever by which virtue is enforced.
3. Dark World thinking as described in Truth or Dare – a deep cynicism about human nature. People are by default out to get you. Emphasis on strength/competence and de-emphasis on kindness/virtue. Closely related to, but distinct from, scarcity mindset.
4. Chinese nationalism as collective insecurity. The narrative is that China experienced a “century of humiliation” being brought to its knees by western colonizers, the Opium War, and Japanese atrocities in WW2, and the world still sees Chinese as “East Asian weaklings.” Through this lens, the primary drive of Chinese people is to prove themselves equal or superior to westerners and usher in the Chinese century.

Chinese Social Media is like American Junk Food

One thing I was shocked by when visiting China is that my grandparents went down to the supermarket every afternoon to buy fresh veggies to cook dinner. Chinese people, at least the older generation, are extremely careful about what they ingest, and have extremely high standards about freshness and culinary discernment. The idea of Americans storing fruit, veggies, and preserved food from the grocery store for weeks in the fridge is repulsive to them.

I think the exact reverse of this dynamic exists for social reality. Chinese beauty filters are out of control. Similarly, here’s what much of pre-AI manhuas look like:

Left to right: 重生都市天尊; 都市仙王; 最强仙尊陈北玄; 武炼巅峰.

Westerners sometimes tell a story that China embraces AI because of some philosophical positivity towards technological progress. I don’t entirely discount this story, but my impression is that Chinese consumers already had a high tolerance for slop and AI content fit naturally into this ecosystem without ever triggering an uncanny-valley reflex. If anything, AI slop is of higher quality than some of the existing mass-produced content. According to this article, one new AI mini-drama (several hours in length) launches every 36 seconds on Douyin.

Another striking feature of Chinese media is the ever-presence of audience reactions and the surrounding cultural conversation. Here is what I see if I pull up the first episode of idol drama “Pursuit of Jade” with 弹幕 (bullet comments) on by default:

Here’s the first chapter of a randomly-selected popular novel on Qidian (the largest site for Chinese webnovels):

See for yourself: Qidian chapter.

Every sentence is annotated with reader comments – so interacting with the reactions of other netizens is now part of the reading experience. Often these comments are filled with memes and in-jokes (梗) which take years of internet immersion to understand. And thus reading a novel, something I classify as one of the most private experiences, is embedded into the cultural conversation.

There is a lot more I could say: writing is filled with “clickbait” attention-grabbers; astroturfing and doxxing are entrenched industries; and it is typical for important events in slop novels to be padded by pages of fictional “social media reactions” showcasing in-universe virality. The basic message is: how others react to something is as important as the thing itself.

The Primacy of Social Reality

Here is the first verse of a popular children’s song:

小嘛小儿郎
背着那书包上学堂
不怕太阳晒
也不怕那风雨狂
只怕先生骂我懒哪
没有学问啰无颜见爹娘
朗里格朗里呀朗格里格朗
没有学问啰无颜见爹娘

I'm a small student.
I carry my backpack to school
I’m not afraid of the sun.
I’m also not afraid of the wind or the rain.
I'm only afraid that my teacher would scold me for being lazy
I'd lose face before my parents without the knowledge of school
Lan lee eh lan lan lee eh lan lan lee eh lan
I'd lose face before my parents without the knowledge of school.

This basic message is inculcated throughout Chinese upbringing: push through and ignore physical discomfort, but attend to and be subject to social censure. It’s okay to be buffeted by the elements, but if your grades are bad, you’ll be too ashamed to face your parents.

China lives inside an intricate and cynical theory of social reality. I wish I had some good writeups of this to point to; something that comes close is 48 Laws of Power, which cries out “this writer is sourcing from Chinese philosophy” but goes too far in the nuance-less sociopath manifesto direction.

To give some examples, the phrase 社死, “social death,” which means being so embarrassed that one might as well be dead socially, has gained a lot of popularity. I think there is a genuine sense in which people (everywhere, but more so in China) are more viscerally afraid of humiliation than death. (Again, there exists a nuanced dialectic about this phrase, and it is now used mostly ironically to joke about minor embarrassment. Further, many fictional protagonists are written as bold iconoclasts who do what is right despite social censure. I think this example still points to a culture preoccupied with social grace.)

Another example, as depicted in media, is a complex of subtle and entrenched rules “潜规则” (lit. “unspoken rules” or “underwater rules”) about social/corporate power that serve to enforce dominance hierarchies. The most salient such rule is “sleep with your boss to get ahead,” but more broadly, it points to dynamics like bribery and nepotism. Depending on status dynamics, being late is either a faux pas or a power move. Similarly with refusing to get drunk at a work dinner.

The Dark World Frame

A lot of anti-social behavior I used to intuitively attribute to "Dark Triad" pathologies – narcissism, Machiavellianism, psychopathy – I now attribute to a cluster of cynical/self-defensive beliefs that Duncan Sabien identifies in Truth or Dare as “The Dark World frame.”

Dark World thinking is typified by Peter Thiel’s recent viral quote: “If you’re evil, at least you’re not bad.” Dark World thinking is everywhere, but in my experience there’s a particularly brazen strain in China. Key tenets of the Dark World:

No good deed goes unpunished.

It is better to be strong than good.

It is better to be evil than weak.

It is better to be honest than kind.

A chain is only as strong as its weakest link.

That which can be destroyed should be.

Kindness to others is cruelty to oneself.

A common trope in Chinese stories is what I call parenting-by-cauterization. A cruel master forces a young boy to kill his best friend: “He was your greatest weakness, kill him and you have one fewer.” Forming attachments is weakness. Breaking attachments makes you strong. (To be fair, this pattern is usually attributed to antagonists, and generally rejected as needlessly cruel by the overarching plot. My reading is that this is a real dialectic-in-progress to reject a pattern of generational trauma.)

Dark World thinking sees all virtue and kindness as pretense. Among many such tropes, a common derogatory trope is of women who act nice and innocent 白莲花 (white lotus) while being deceitful and manipulative on the inside. Chinese media creates trapped priors that people acting kind, altruistic, and pure are more likely to be evil. Similarly, the phrase 圣母 (Virgin Mary) is derogatory slang for someone who displays excessive (read: normal-to-westerners) levels of empathy. If all kindness is pretense and deceit, the only way to signal trustworthiness is cruelty. My father used to say, “Everyone will be nice to you, but only your family will be honest.”

One time I was having lunch with my wife and a Chinese friend, and the conversation meandered to why my wife entered college as a premed in her distant past life. Among the many reasons – money, respectability, parental approval – my wife brought up the motivation of “saving lives and helping people.” My friend laughed open-mouthed at that suggestion, taking it as an obvious joke. (Again, I don’t mean to say this person is representative of China. I suspect that their reaction was two-standard-deviations more Dark-World than the mode in China, and three-standard-deviations more Dark-World than the mode in the West.)

Zvi Mowshowitz once wrote a book review of The Three-Body Problem, where his thesis was “The real aliens are the Chinese people”:

Instead, the humans are written a lot stranger, to my American eyes, than the Trisolarians. Most characters are Chinese, but even those who are not continue to mostly think and act in this similarly alien style. I appreciated the opportunity to see the view of humanity from someone in a completely different culture. But it points out how ordinary the Trisolarians are that they are, at least, not obviously less like the humans I know, than are the humans in the book. How much of this is how the Chinese or some Chinese group view humans and think about the world, versus how the author does? I cannot say.

The viewpoint expressed is deeply, deeply conservative and cynical.

People, all but a handful of them, are absurdly fickle, petty, short-sighted, self-interested and self-defeating. They are obsessed with status and how they are relative to others, and on the margin wish others harm rather than well. If anyone tries to escape disaster or otherwise rise on their own, universally mankind's response is to band together to kill them.

The Three-Body Problem is a particularly extreme example of the Dark World frame, and it’s an outlier because science fiction is grim-dark by default. My guess is that half of the Dark-Worldness of The Three-Body Problem derives from the nature of science fiction, and half from Chinese culture. There’s a reason the second book is called The Dark Forest.

Chinese nationalism as collective insecurity

At some point I was watching American Ninja Warrior, and one season hosted national teams from various countries. When the interviewer came around to hear people’s stories, all the western teams were like “I’m doing this to set a good example for my wife and kids at home.” The Chinese team was like “I’m doing this to prove to the world that Chinese people can be great athletes.”

In 2025 we saw the launch of an absolutely peak FMV game “Road to Empress” about instrumental convergence a fictionalized account of China’s only official female ruler Wu Zetian. Ludwig went viral in China for streaming it on Twitch, to the extent that the creators flew him out to China to film a cameo in the sequel:

Ludwig’s cameo.

The top comment on the Bilibili playthrough, which Ludwig reacted to in this clip, went, “This game is really good-looking. It can let foreigners know that Asians are not all squinty-eyed as in the stereotype [grin] There are also many handsome men and beautiful women.” Ludwig’s response was “I'm laughing that their idea of America is that before playing this game, I thought all people in Asia were the stereotype with the squinty eyes.”

Even among strains of nationalism, Chinese nationalism seems to be particularly chip-on-your-shoulder. My impression is that this kind of insecurity is less in your face, but still present, in younger Chinese today. It is concerning how much Chinese AI models catching up in the AI race is entangled with this national insecurity.

—

The point of this post is to open for the reader my fairly narrow window into Chinese culture, and to draw attention to certain features I find alien as an American.

I suspect that if the rationalist project wants to take root in China, it has to solve problems like not being immediately branded as holier-than-thou “圣母”, and adjusting to the cutthroat attention economy of Chinese social media. HPMOR is an example of something (grimdark power-scaling quasi-isekai fantasy) that likely appeals to Chinese netizens; Peter Singer is not.

I like to say that if LessWrong is “on the spectrum” and “more autistic than normal,” where normal is set to the ambient western culture, then China lives past the right endpoint of the spectrum, at “even more allistic than normal.” My current hypothesis is that the locally optimal message to China is in the vein of “give us your autists who feel alienated by the monoculture,” but others may prefer a more conciliatory approach that directly appeals to the dominant culture.

John von Neumann was a brilliant mathematician who made important contributions to quantum physics, to logic, to meteorology, to war, to the theory and applications of high-speed computing machines, and, via the mathematical theory of games of strategy, to economics.

Youth

He was born December 28, 1903, in Budapest, Hungary. He was the eldest of three sons in a well-to-do Jewish family. His father was a banker who received a minor title of nobility from the Emperor Franz Josef; since the title was hereditary, von Neumann’s full Hungarian name was Margittai Neumann Janos.

(Hungarians put the family name first. Literally, but in reverse order, the name means John Neumann of Margitta. The ‘“‘of’’, indicated by the final “‘1’’, is where the “‘von”’ comes from; the place name was dropped in the German translation. In ordinary social intercourse such titles were never used, and by the end of the first world war their use had gone out of fashion altogether. In Hungary von Neumann is and always was known as Neumann Janos and his works are alphabetized under N. Incidentally, his two brothers, when they settled in the U.S., solved the name problem differently. One of them reserves the title of nobility for ceremonial occasions only, but, in daily life, calls himself Neumann; the other makes it less conspicuous by amalgamating it with the family name and signs himself Vonneuman.)

Even in the city and in the time that produced Szilard (1898), Wigner (1902), and Teller (1908), von Neumann’s brilliance stood out, and the legends about him started accumulating in his childhood. Many of the legends tell about his memory. His love of history began early, and, since he remembered what he learned, he ultimately became an expert on Byzantine history, the details of the trial of Joan of Arc, and minute features of the battles of the American Civil War.

He could, it is said, memorize the names, addresses, and telephone numbers in a column of the telephone book on sight. Some of the later legends tell about his wit and his fondness for humor, including puns and off-color limericks. Speaking of the Manhattan telephone book he said once that he knew all the numbers in it — the only other thing he needed, to be able to dispense with the book altogether, was to know the names that the numbers belonged to.

Most of the legends, from childhood on, tell about his phenomenal speed in absorbing ideas and solving problems. At the age of 6 he could divide two eight-digit numbers in his head; by 8 he had mastered the calculus; by 12 he had read and understood Borel’s Théorie des Fonctions.

These are some of the von Neumann stories in circulation. I’ll report others, but I feel sure that I haven’t heard them all. Many are undocumented and unverifiable, but I’ll not insert a separate caveat for each one: let this do for them all. Even the purely fictional ones say something about him; the stories that men make up about a folk hero are, at the very least, a strong hint to what he was like.

In his early teens he had the guidance of an intelligent and dedicated high-school teacher, L. Ratz, and, not much later, he became a pupil of the young M. Fekete and the great L. Fejér, “the spiritual father of many Hungarian mathematicians”. (“Fekete” means “Black”, and “Fejér” is an archaic spelling, analogous to “Whyte”.)

According to von Karman, von Neumann’s father asked him, when John von Neumann was 17, to dissuade the boy from becoming a mathematician, for financial reasons. As a compromise between father and son, the solution von Karman proposed was chemistry. The compromise was adopted, and von Neumann studied chemistry in Berlin (1921-1923) and in Zürich (1923-1925). In 1926 he got both a Zürich diploma in chemical engineering and a Budapest Ph.D. in mathematics.

Early work

His definition of ordinal numbers (published when he was 20) is the one that is now universally adopted. His Ph.D. dissertation was about set theory too; his axiomatization has left a permanent mark on the subject. He kept up his interest in set theory and logic most of his life, even though he was shaken by K. Gödel’s proof of the impossibility of proving that mathematics is consistent.

He admired Gödel and praised him in strong terms: “Kurt Gödel’s achievement in modern logic is singular and monumental — indeed it is more than a monument, it is a landmark which will remain visible far in space and time. ... The subject of logic has certainly completely changed its nature and possibilities with Gödel’s achievement.” In a talk entitled “The Mathematician”, speaking, among other things, of Gödel’s work, he said: “This happened in our lifetime, and I know myself how humiliatingly easily my own values regarding the absolute mathematical truth changed during this episode, and how they changed three times in succession!”

He was Privatdozent at Berlin (1926-1929) and at Hamburg (1929-1930). During this time he worked mainly on two subjects, far from set theory but near to one another: quantum physics and operator theory. It is almost not fair to call them two subjects: due in great part to von Neumann’s own work, they can be viewed as two aspects of the same subject. He started the process of making precise mathematics out of quantum theory, and (it comes to the same thing really) he was inspired by the new physical concepts to make broader and deeper the purely mathematical study of infinite-dimensional spaces and operators on them. The basic insight was that the geometry of the vectors in a Hilbert space has the same formal properties as the structure of the states of a quantum-mechanical system. Once that is accepted, the difference between a quantum physicist and a mathematical operator-theorist becomes one of language and emphasis only. Von Neumann’s book on quantum mechanics appeared (in German) in 1932. It has been translated into French (1947), Spanish (1949), and English (1955), and it is still one of the standard and one of the most inspiring treatments of the subject. Speaking of von Neumann’s contributions to quantum mechanics, E. Wigner, a Nobel laureate, said that they alone “would have secured him a distinguished position in present day theoretical physics”.

Princeton

In 1930 von Neumann went to Princeton University for one term as visiting lecturer, and the following year he became professor there. In 1933, when the Institute for Advanced Study was founded, he was one of the original six professors of its School of Mathematics, and he kept that position for the rest of his life. (It is easy to get confused about the Institute and its formal relation with Princeton University, even though there is none. They are completely distinct institutions. The Institute was founded for scholarship and research only, not teaching. The first six professors in the School of Mathematics were J. W. Alexander, A. Einstein, M. Morse, O. Veblen, J. von Neumann, and H. Weyl. When the Institute began it had no building, and it accepted the hospitality of Princeton University. Its members and visitors have, over the years, maintained close professional and personal relations with their colleagues at the University. These facts kept contributing to the confusion, which was partly clarified in 1940, when the Institute acquired a building of its own, about a mile from the Princeton campus.)

In 1930 von Neumann married Marietta Kévesi; in 1935 their daughter Marina was born. (In 1956 Marina von Neumann graduated from Radcliffe summa cum laude, with the highest scholastic record in her class. In 1972 Marina von Neumann Whitman was appointed by President Nixon to the Council of Economic Advisers.)

In the 1930’s the stature of von Neumann, the mathematician, grew at the rate that his meteoric early rise had promised, and the legends about Johnny, the human being, grew along with it. He enjoyed life in America and lived it in an informal manner, very differently from the style of the conventional German professor. He was not a refugee and he didn’t feel like one. He was a cosmopolite in attitude and a U.S. citizen by choice.

The parties at the von Neumanns’ house were frequent, and famous, and long. Johnny was not a heavy drinker, but he was far from a teetotaller. In a roadside restaurant he once ordered a brandy with a hamburger chaser. The outing was in honor of his birthday and he was feeling fine that evening. One of his gifts was a toy, a short prepared tape attached to a cardboard box that acted as sounding board; when the tape was pulled briskly past a thumbnail, it would squawk “Happy birthday!” Johnny squawked it often. Another time, at a party at his house, there was one of those thermodynamic birds that dips his beak in a glass of water, straightens up, teeter-totters for a while, and then repeats the cycle. A temporary but firm house rule was quickly passed: everyone had to take a drink each time that the bird did.

He liked to drive, but he didn’t do it well. There was a “von Neumann’s corner” in Princeton, where, the story goes, his cars repeatedly had trouble. One often quoted explanation that he allegedly offered for one particular crack-up goes like this:

It was proceeding down the road. The trees on the right were passing me in orderly fashion at 60 miles an hour. Suddenly one of them stepped in my path. Boom!

He once had a dog named “Inverse”. He played poker, but only rarely, and he usually lost.

In 1937 the von Neumanns were divorced; in 1938 he married Klara Dan. She learned mathematics from him and became an expert programmer. Many years later, in an interview, she spoke about him. “He has a very weak idea of the geography of the house. ...Once, in Princeton, I sent him to get me a glass of water; he came back after a while wanting to know where the glasses were. We had been in the house only seventeen years. ...He has never touched a hammer or a screwdriver; he does nothing around the house. Except for fixing zippers. He can fix a broken zipper with a touch.”

Von Neumann was definitely not the caricatured college professor. He was a round, pudgy man, always neatly, formally dressed. There are, to be sure, one or two stories of his absentmindedness. Klari told one about the time when he left their Princeton house one morning to drive to a New York appointment, and then phoned her when he reached New Brunswick to ask: “Why am I going to New York?”

It may not be strictly relevant, but I am reminded of the time I drove him to his house one afternoon. Since there was to be a party there later that night, and since I didn’t trust myself to remember exactly how I got there, I asked how I'd be able to know his house when I came again. “That’s easy,” he said; “it’s the one with that pigeon sitting by the curb.”

Normally he was alert, good at rapid repartee. He could be blunt, but never stuffy, never pompous. Once the telephone interrupted us when we were working in his office. His end of the conversation was very short; all he said between “Hello” and “Goodbye” was “Fekete pestis!”, which means “Black plague!” Remembering, after he hung up, that I understood Hungarian, he turned to me, half apologetic and half exasperated, and explained that he wasn’t speaking of one of the horsemen of the Apocalypse, but merely of some unexpected and unwanted dinner guests that his wife just told him about.

On a train once, hungry, he asked the conductor to send the man with the sandwich tray to his seat. The busy and impatient conductor said “I will if I see him”. Johnny’s reply: “This train is linear, isn’t it?”

Speed

The speed with which von Neumann could think was awe-inspiring. G. Pólya admitted that “Johnny was the only student I was ever afraid of. If in the course of a lecture I stated an unsolved problem, the chances were he’d come to me as soon as the lecture was over, with the complete solution in a few scribbles on a slip of paper.” Abstract proofs or numerical calculations — he was equally quick with both, but he was especially pleased with and proud of his facility with numbers.

When his electronic computer was ready for its first preliminary test, someone suggested a relatively simple problem involving powers of 2. (It was something of this kind: what is the smallest power of 2 with the property that its decimal digit fourth from the right is 7? This is a completely trivial problem for a present-day computer: it takes only a fraction of a second of machine time.) The machine and Johnny started at the same time, and Johnny finished first.

One famous story concerns a complicated expression that a young scientist at the Aberdeen Proving Ground needed to evaluate. He spent ten minutes on the first special case; the second computation took an hour of paper and pencil work; for the third he had to resort to a desk calculator, and even so took half a day. When Johnny came to town, the young man showed him the formula and asked him what to do. Johnny was glad to tackle it. “Let’s see what happens for the first few cases. If we put m = 1, we get...” — and he looked into space and mumbled for a minute. Knowing the answer, the young questioner put in “2.31?” Johnny gave him a funny look and said “Now if n = 2,...”, and once again voiced some of his thoughts as he worked. The young man, prepared, could of course follow what Johnny was doing, and, a few seconds before Johnny finished, he interrupted again, in a hesitant tone of voice: “7.49?” This time Johnny frowned, and hurried on: “If n = 3, then...”. The same thing happened as before — Johnny muttered for several minutes, the young man eavesdropped, and, just before Johnny finished, the young man exclaimed: “11.06!” That was too much for Johnny. It couldn’t be! No unknown beginner could outdo him! He was upset and he sulked till the practical joker confessed.

Then there is the famous fly puzzle. Two bicyclists start twenty miles apart and head toward each other, each going at a steady rate of 10 m.p.h. At the same time a fly that travels at a steady 15 m.p.h. starts from the front wheel of the southbound bicycle and flies to the front wheel of the northbound one, then turns around and flies to the front wheel of the southbound one again, and continues in this manner till he is crushed between the two front wheels. Question: what total distance did the fly cover? The slow way to find the answer is to calculate what distance the fly covers on the first, northbound, leg of the trip, then on the second, southbound, leg, then on the third, etc., etc., and, finally, to sum the infinite series so obtained. The quick way is to observe that the bicycles meet exactly one hour after their start, so that the fly had just an hour for his travels; the answer must therefore be 15 miles. When the question was put to von Neumann, he solved it in an instant, and thereby disappointed the questioner: “Oh, you must have heard the trick before!” “What trick?” asked von Neumann; “all I did was sum the infinite series.”

I remember one lecture in which von Neumann was talking about rings of operators. At an appropriate point he mentioned that they can be classified two ways: finite versus infinite, and discrete versus continuous. He went on to say: “This leads to a total of four possibilities, and, indeed, all four of them can occur. Or — let’s see — can they?” Many of us in the audience had been learning this subject from him for some time, and it was no trouble to stop and mentally check off all four possibilities. No trouble — it took something like two seconds for each, and, allowing for some fumbling and shifting of gears, it took us perhaps 10 seconds in all. But after two seconds von Neumann had already said “Yes, they can,” and he was two sentences into the next paragraph before, dazed, we could scramble aboard again.

Speech

Since Hungarian is not exactly a lingua franca, all educated Hungarians must acquire one or more languages with a popular appeal greater than that of their mother tongue. At home the von Neumanns spoke Hungarian, but he was perfectly at ease in German, and in French, and, of course, in English. His English was fast and grammatically defensible, but in both pronunciation and sentence construction it was reminiscent of German. His “Sprachgefühl” was not perfect, and his sentences tended to become involved. His choice of words was usually exactly right; the occasional oddities (like “a self-obvious theorem”) disappeared in later years. His spelling was sometimes more consistent than commonplace: if “commit”, then “ommit”.

S. Ulam tells about von Neumann’s trip to Mexico, where “he tried to make himself understood by using ‘neo-Castilian’, a creation of his own — English words with an ‘el’ prefix and appropriate Spanish endings”.

He prepared for lectures, but rarely used notes. Once, five minutes before a non-mathematical lecture to a general audience, I saw him as he was preparing. He sat in the lounge of the Institute and scribbled on a small card a few phrases such as these: “Motivation, 5 min.; historical background, 15 min.; connection with economics, 10 min.;...”

As a mathematical lecturer he was dazzling. He spoke rapidly but clearly; he spoke precisely, and he covered the ground completely. If, for instance, a subject has four possible axiomatic approaches, most teachers content themselves with developing one, or at most two, and merely mentioning the others. Von Neumann was fond of presenting the “complete graph” of the situation. He would, that is, describe the shortest path that leads from the first to the second, from the first to the third, and so on through all twelve possibilities.

His one irritating lecturing habit was the way he wielded an eraser. He would write on the board the crucial formula under discussion. When one of the symbols in it had been proved to be replaceable by something else, he made the replacement not by rewriting the whole formula, suitably modified, but by erasing the replaceable symbol and substituting the new one for it. This had the tendency of inducing symptoms of acute discouragement among note-takers, especially since, to maintain the flow of the argument, he would keep talking at the same time.

His style was so persuasive that one didn’t have to be an expert to enjoy his lectures; everything seemed easy and natural. Afterward, however, the Chinese-dinner phenomenon was likely to occur. A couple of hours later the average memory could no longer support the delicate balance of mutually interlocking implications, and, puzzled, would feel hungry for more explanation.

Style

As a writer of mathematics von Neumann was clear, but not clean; he was powerful but not elegant. He seemed to love fussy detail, needless repetition, and notation so explicit as to be confusing. To maintain a logically valid but perfectly transparent and unimportant distinction, in one paper he introduced an extension of the usual functional notation: along with the standard φ(x) he dealt also with something denoted by φ((x)). The hair that was split to get there had to be split again a little later, and there was φ(((x))), and, ultimately, φ((((x)))). Equations such as

(φ((((a)))))* = φ(((a)))

have to be peeled before they can be digested; some irreverent students referred to this paper as von Neumann’s onion.

Perhaps one reason for von Neumann’s attention to detail was that he found it quicker to hack through the underbrush himself than to trace references and see what others had done. The result was that sometimes he appeared ignorant of the standard literature. If he needed facts, well-known facts, from Lebesgue integration theory, he waded in, defined the basic notions, and developed the theory to the point where he could use it. If, in a later paper, he needed integration theory again, he would go back to the beginning and do the same thing again.

He saw nothing wrong with long strings of suffixes, and subscripts on subscripts; his papers abound in avoidable algebraic computations. The reason, probably, is that he saw the large picture; the trees did not conceal the forest from him. He saw and he relished all parts of the mathematics he was thinking about. He never wrote “down” to an audience; he told it as he saw it. The practice caused no harm; the main result was that, quite a few times, it gave lesser men an opportunity to publish “improvements” of von Neumann.

Since he had no formal connections with educational institutions after he was 30, von Neumann does not have a long list of students; he supervised only one Ph.D. thesis. Through his lectures and informal conversations he acquired, however, quite a few disciples who followed in one or another of his footsteps. A few among them are J. W. Calkin, J. Charney, H. H. Goldstine, P. R. Halmos, I. Halperin, O. Morgenstern, F. J. Murray, R. Schatten, I. E. Segal, A. H. Taub, and S. Ulam.

Work habits

Von Neumann was not satisfied with seeing things quickly and clearly; he also worked very hard. His wife said “he had always done his writing at home during the night or at dawn. His capacity for work was practically unlimited.”

In addition to his work at home, he worked hard at his office. He arrived early, he stayed late, and he never wasted any time. He was systematic in both large things and small; he was, for instance, a meticulous proofreader. He would correct a manuscript, record on the first page the page numbers where he found errors, and, by appropriate tallies, record the number of errors that he had marked on each of those pages. Another example: when requested to prepare an abstract of not more than 200 words, he would not be satisfied with a statistical check — there are roughly 20 lines with about 10 words each — but he would count every word.

When I was his assistant we wrote one paper jointly. After the thinking and the talking were finished, it became my job to do the writing. I did it, and I submitted to him a typescript of about 12 pages. He read it, criticized it mercilessly, crossed out half, and rewrote the rest; the result was about 18 pages. I removed some of the Germanisms, changed a few spellings, and compressed it into 16 pages. He was far from satisfied, and made basic changes again; the result was 20 pages. The almost divergent process continued (four innings on each side as I now recall it); the final outcome was about 30 typescript pages (which came to 19 in print).

Another notable and enviable trait of von Neumann’s was his mathematical courage. If, in the middle of a search for a counterexample, an infinite series came up, with a lot of exponentials that had quadratic exponents, many mathematicians would start with a clean sheet of paper and look for another counterexample. Not Johnny! When that happened to him, he cheerfully said: “Oh, yes, a theta function...”, and plowed ahead with the mountainous computations. He wasn’t afraid of anything.

He knew a lot of mathematics, but there were also gaps in his knowledge, most notably number theory and algebraic topology. Once when he saw some of us at a blackboard staring at a rectangle that had arrows marked on each of its sides, he wanted to know what that was. “Oh just the torus, you know — the usual identification convention.” No, he didn’t know. The subject is elementary, but some of it just never crossed his path, and even though most graduate students knew about it, he didn’t.

Brains, speed, and hard work produced results. In von Neumann’s Collected Works there is a list of over 150 papers. About 60 of them are on pure mathematics (set theory, logic, topological groups, measure theory, ergodic theory, operator theory, and continuous geometry), about 20 on physics, about 60 on applied mathematics (including statistics, game theory, and computer theory), and a small handful on some special mathematical subjects and general non-mathematical ones. A special number of the Bulletin of the American Mathematical Society was devoted to a discussion of his life and work (in May 1958).

Pure mathematics

Von Neumann’s reputation as a mathematician was firmly established by the 1930’s, based mainly on his work on set theory, quantum theory, and operator theory, but enough more for about three ordinary careers, in pure mathematics alone, was still to come. The first of these was the proof of the ergodic theorem. Various more or less precise statements had been formulated earlier in statistical mechanics and called the ergodic hypothesis. In 1931 B. O. Koopman published a penetrating remark whose main substance was that one of the contexts in which a precise statement of the ergodic hypothesis could be formulated is the theory of operators on Hilbert space — the very subject that von Neumann used earlier to make quantum mechanics precise and on which he had written several epoch-making papers. It is tempting to speculate on von Neumann’s reaction to Koopman’s paper. It could have been something like this: “By Koopman’s remark the ergodic hypothesis becomes a theorem about Hilbert spaces — and if that’s what it is I ought to be able to prove it. Let’s see now....” Soon after the appearance of Koopman’s paper, von Neumann formulated and proved the statement that is now known as the mean ergodic theorem for unitary operators. There was some temporary confusion, caused by publication dates, about who did what before whom, but by now it is universally recognized that von Neumann’s theorem preceded and inspired G. D. Birkhoff’s point ergodic theorem. In the course of the next few years von Neumann published several more first-rate papers on ergodic theory, and he made use of the techniques and results of that theory later, in his studies of rings of operators.

In 1900 D. Hilbert presented a famous list of 23 problems that summarized the state of mathematical knowledge at the time and showed where further work was needed. In 1933 A. Haar proved the existence of a suitable measure (which has come to be called Haar measure) in topological groups; his proof appears in the Annals of Mathematics. Von Neumann had access to Haar’s result before it was published, and he quickly saw that that was exactly what was needed to solve an important special case (compact groups) of one of Hilbert’s problems (the 5th). His solution appears in the same issue of the same journal, immediately after Haar’s paper.

In the second half of the 1930’s the main part of von Neumann’s publications was a sequence of papers, partly in collaboration with F. J. Murray, on what he called rings of operators. (They are now called von Neumann algebras.) It is possible that this is the work for which von Neumann will be remembered the longest. It is a technically brilliant development of operator theory that makes contact with von Neumann’s earlier work, generalizes many familiar facts about finite-dimensional algebra, and is currently one of the most powerful tools in the study of quantum physics.

A surprising outgrowth of the theory of rings of operators is what von Neumann called continuous geometry. Ordinary geometry deals with spaces of dimension 1, 2, 3, etc. In his work on rings of operators von Neumann saw that what really determines the dimension structure of a space is the group of rotations that it admits. The group of rotations associated with the ring of all operators yields the familiar dimensions. Other groups, associated with different rings, assign to spaces dimensions whose values can vary continuously; in that context it makes sense to speak of a space of dimension 3/4, say. Abstracting from the “concrete” case of rings of operators, von Neumann formulated the axioms that make these continuous-dimensional spaces possible. For several years he thought, wrote, and lectured about continuous geometries. In 1937 he was the Colloquium Lecturer of the American Mathematical Society and chose that subject for his topic.

Applied mathematics

The year 1940 was just about the half-way point of von Neumann’s scientific life, and his publications show a discontinuous break then. Till then he was a topflight pure mathematician who understood physics; after that he was an applied mathematician who remembered his pure work. He became interested in partial differential equations, the principal classical tool of the applications of mathematics to the physical world. Whether the war made him into an applied mathematician or his interest in applied mathematics made him invaluable to the war effort, in either case he was much in demand as a consultant and advisor to the armed forces and to the civilian agencies concerned with the problems of war.

His papers from this point on are mainly on statistics, shock waves, flow problems, hydrodynamics, aerodynamics, ballistics, problems of detonation, meteorology, and, last but not least, two non-classical, new aspects of the applicability of mathematics to the real world: games and computers.

Von Neumann’s contributions to war were manifold. Most often mentioned is his proposal of the implosion method for bringing nuclear fuel to explosion (during World War II) and his espousal of the development of the hydrogen bomb (after the war). The citation that accompanied his honorary D.Sc. from Princeton in 1947 mentions (in one word) that he was a mathematician, but praises him for being a physicist, an engineer, an armorer, and a patriot.

Politics

His political and administrative decisions were rarely on the side that is described nowadays by the catchall term “liberal”. He appeared at times to advocate preventive war with Russia. As early as 1946 atomic bomb tests were already receiving adverse criticism, but von Neumann thought that they were necessary and (in, for instance, a letter to the New York Times) defended them vigorously. He disagreed with J. R. Oppenheimer on the H-bomb crash program, and urged that the U.S. proceed with it before Russia could. He was, however, a “pro-Oppenheimer” witness at the Oppenheimer security hearings. He said that Oppenheimer opposed the program “in good faith” and was “very constructive” once the decision to go ahead with the super bomb was made. He insisted that Oppenheimer was loyal and was not a security risk.

As a member of the Atomic Energy Commission (appointed by President Eisenhower, he was sworn in on March 15, 1955), having to “think about the unthinkable”, he urged a United Nations study of world-wide radiation effects. “We willingly pay 30,000-40,000 fatalities per year (2% of the total death rate),” he wrote, “for the advantages of individual transportation by automobile.” He mentioned a fall-out accident in an early Pacific bomb test that resulted in one fatality and danger to 200 people, and he compared it with a Japanese ferry accident that “killed about 1,000 people, including 20 Americans — yet the...fall-out was what attracted almost world-wide attention.” He asked: “Is the price in international popularity worth paying?” And he answered: “Yes: we have to accept it as part payment for our more advanced industrial position.”

Game theory

At about the same time that he began to apply his analytic talents to the problems of war, von Neumann found time and energy to apply his combinatorial insight to what he called the theory of games, whose major application was to economics. The mathematical cornerstone of the theory is one statement, the so-called minimax theorem, that von Neumann proved early (1928) in a short article (25 pages); its elaboration and applications are in the book he wrote jointly with O. Morgenstern in 1944. The minimax theorem says about a large class of two-person games that there is no point in playing them. If either player considers, for each possible strategy of play, the maximum loss that he can expect to sustain with that strategy, and then chooses the “optimal” strategy that minimizes the maximum loss, then he can be statistically sure of not losing more than that minimax value. Since (and this is the whole point of the theorem) that value is the negative of the one, similarly defined, that his opponent can guarantee for himself, the long-run outcome is completely determined by the rules.

Mathematical economics before von Neumann tried to achieve success by imitating the technique of classical mathematical physics. The mathematical tools used were those of analysis (specifically the calculus of variations), and the procedure relied on a not completely reliable analogy between economics and mechanics. The secret of the success of the von Neumann approach was the abandonment of the mechanical analogy and its replacement by a fresh point of view (games of strategy) and new tools (the ideas of combinatorics and convexity).

The role that game theory will play in the future of mathematics and economics is not easy to predict. As far as mathematics is concerned, it is tenable that the only thing that makes the Morgenstern-von Neumann book 600 pages longer than the original von Neumann paper is the development needed to apply the abstruse deductions of one subject to the concrete details of another. On the other hand, enthusiastic proponents of game theory can be found who go so far as to say that it may be “one of the major scientific contributions of the first half of the 20th century”.

Machines

The last subject that contributed to von Neumann’s fame was the theory of electronic computers and automata. He was interested in them from every point of view: he wanted to understand them, design them, build them, and use them. What are the logical components of the processes that a computer will be asked to perform? What is the best way of obtaining practically reliable answers from a machine with unreliable components? What does a machine need to “remember”, and what is the best way to equip it with a “memory”? Can a machine be built that can not only save us the labor of computing but save us also the trouble of building a new machine — is it possible, in other words, to produce a self-reproducing automaton? (Answer: in principle, yes. A sufficiently complicated machine, embedded in a thick chowder of randomly distributed spare parts, its “food”, would pick up one part after another till it found a usable one, put it in place, and continue to search and construct till its descendant was complete and operational.) Can a machine successfully imitate “randomness”, so that when no formulae are available to solve a concrete physical problem (such as that of finding an optimal bombing pattern), the machine can perform a large number of probability experiments and yield an answer that is statistically accurate? (The last question belongs to the concept that is sometimes described as the Monte Carlo method.) These are some of the problems that von Neumann studied and to whose solutions he made basic contributions.

He had close contact with several computers — among them the MANIAC (Mathematical Analyzer, Numerical Integrator, Automatic Calculator), and the affectionately named JONIAC. He advocated their use for everything from the accumulation of heuristic data for the clarification of our intuition about partial differential equations to the accurate long-range prediction and, ultimately, control of the weather. One of the most striking ideas whose study he suggested was to dye the polar icecaps so as to decrease the amount of energy they would reflect — the result could warm the earth enough to make the climate of Iceland approximate that of Hawaii.

The last academic assignment that von Neumann accepted was to deliver and prepare for publication the Silliman lectures at Yale. He worked on that job in the hospital where he died, but he couldn’t finish it. His notes for it were published, and even they make illuminating reading. They contain tantalizing capsule statements of insights, and throughout them there shines an attitude of faith in and dedication to knowledge. While physicists, engineers, meteorologists, statisticians, logicians, and computers all proudly claim von Neumann as one of theirs, the Silliman lectures prove, indirectly by their approach and explicitly in the author’s words, that von Neumann was first, foremost, and always a mathematician.

Death

Von Neumann was an outstanding man in tune with his times, and it is not surprising that he received many awards and honors. There is no point in listing them all here, but a few may be mentioned. He received several honorary doctorates, including ones from Princeton (1947), Harvard (1950), and Istanbul (1952). He served a term as president of the American Mathematical Society (1951-1953), and he was a member of several national scientific academies (including, of course, that of the U. S.). Somewhat to his embarrassment, he was elected to the East German Academy of Science, but the election didn’t seem to take — in later years no mention is made of it in the standard biographical reference works.

He received the Enrico Fermi award in 1956, when he already knew that he was incurably ill.

Von Neumann became ill in 1955. There was an operation, and the result was a diagnosis of cancer. He kept on working, and even travelling, as the disease progressed. Later he was confined to a wheelchair, but still thought, wrote, and attended meetings. In April 1956 he entered Walter Reed Hospital, and never left it. Of his last days his good friend Eugene Wigner wrote: “When von Neumann realized he was incurably ill, his logic forced him to realize that he would cease to exist, and hence cease to have thoughts. ...It was heartbreaking to watch the frustration of his mind, when all hope was gone, in its struggle with the fate which appeared to him unavoidable but unacceptable.”

Von Neumann was baptized a Roman Catholic (in the U. S.), but, after his divorce, he was not a practicing member of the church. In the hospital he asked to see a priest — “one that will be intellectually compatible”. Arrangements were made, he was given special instruction, and, in due course, he again received the sacraments. He died February 8, 1957.

The heroes of humanity are of two kinds: the ones who are just like all of us, but very much more so, and the ones who, apparently, have an extra-human spark. We can all run, and some of us can run the mile in less than 4 minutes; but there is nothing that most of us can do that compares with the creation of the Great G-minor Fugue. Von Neumann’s greatness was the human kind. We can all think clearly, more or less, some of the time, but von Neumann’s clarity of thought was orders of magnitude greater than that of most of us, all the time. Both Norbert Wiener and John von Neumann were great men, and their names will live after them, but for different reasons. Wiener saw things deeply but intuitively; von Neumann saw things clearly and logically.

What made von Neumann great? Was it the extraordinary rapidity with which he could understand and think and the unusual memory that retained everything he had once thought through? No. These qualities, however impressive they might have been, are ephemeral; they will have no more effect on the mathematics and the mathematicians of the future than the prowess of an athlete of a hundred years ago has on the sport of today.

The “axiomatic method” is sometimes mentioned as the secret of von Neumann’s success. In his hands it was not pedantry but perception; he got to the root of the matter by concentrating on the basic properties (axioms) from which all else follows. The method, at the same time, revealed to him the steps to follow to get from the foundations to the applications. He knew his own strengths and he admired, perhaps envied, people who had the complementary qualities, the flashes of irrational intuition that sometimes change the direction of scientific progress. For von Neumann it seemed to be impossible to be unclear in thought or in expression. His insights were illuminating and his statements were precise.

A look at the Shimano Bike Museum with praise for its focus on bicycles over its own corporate history. For anyone in the Kansai area of Japan, perhaps visiting Kyoto or Osaka, this has a prodigious collections of machines and within a well-designed setting.

The museum itself is striking, a modern building that’s glass and steel. To see pictures of it online is to imagine it might be Shimano’s head office in a prime location, and that there’s a museum inside. However it is all museum, and the surrounding area more ordinary.

“In Japanese, we call a bicycle “jitensha,” which literally means “wheels rotated by oneself.” This means a bicycle is operated by the rider and that there are as many ways of enjoying cycling as there are riders.”

This English text is from the welcome message written on the wall at the start of the museum tour. You might learn the word for bicycle here as you enter, by the time you leave the message of many ways to enjoy cycling will come through. The sign is of course in Japanese too and the museum is bilingual.

Head upstairs and you enter a large darkened room with a procession of bicycles under spotlights. These cover the chronology of the machine, from rudimentary hobby horses to the arrival of pedals, the chain, tires more evolution. This large space also doubles as an auditorium and an educational film is played at times that covers the history of the bicycle and the origins of cycle sport too, all within a wider societal context that touches on war, industrialisation and consumerism.

Then it’s into a bright white room where frosted glass lets in daylight and more spotlights highlight exhibits such as Freddy Maerten’s steel Flandria. You can get close to touch it – not that you would or should – but it’s not behind glass or roped off, just raised on a small stage. You can see the Ishiwata tubing decal and the Shimano Crane rear mech, the beginnings of Shimano in the pro peloton. All the other bikes are similarly accessible. You can see bikes used at Paralympic games and notice the custom modifications up close. A Breezer, one of the first mountain bikes to go on sale, sits there and you can spot a Campagnolo headset and motorbike brake levers among the components on the “clunker”.

As well as history there’s the humdrum. A Crescent bike in the yellow and blue of the Swedish postal service, complete with studded tires to show you can ride on ice, even with a heavy cargo. A very much used Cannondale is loaded with luggage, spare tires wrapped around the bags like boa constrictors, and all caked in dust, as if Tatsu Sakimoto had come in and parked it mid-way during his four year, 55,000km journey around the world. A Merida bike from the 2021 Olympics road race is there, complete with scratches galore and crash dents. The event feels like yesterday but the bike already looks ancient. Plenty of kids bikes feature too, shopping bikes and more. Everyone ought to recognise something they’ve ridden.

Stands explores materials science with a comparison of steel, aluminium and titanium tubing and the chance to feel the weight of these metals yourself. Another lets you pick up racing bike to feel how light it is. But among all this educational material is the simple message that bikes can do plenty.

It’s actually hard to find much about Shimano and its origins here. There’s a mention that gun blacksmiths in Sakai started repairing imported bikes in the late 19th century and soon began manufacture. For what it’s worth the city Sakai has long been a big steel production area, first for swords and then into other goods including guns and cutlery. It’s here that Shimano started too but it’s only later and in passing that you come across a small item that was Shimano’s first product: a freewheel.

Shozaburo Shimano founded the company to make these and one thing led to another. Including fishing freewheels and gearing can be applied inside reels and today one quarter of Shimano’s revenue coming from fishing tackle, about a billion Euros, comes from fishing but there’s not a rod nor reel in sight.

Still the museum is visibly the Shimano museum in other ways. There’s excellent stand where a racing bike has been broken into pieces, apparently there are 3,200 parts in one bike if you really count every chain pin, bolt and electronic circuit component. Of course it’s a Shimano Dura-Ace groupset in the display. Good luck finding SRAM or Campagnolo but there are a few examples, even a Mavic rear mech.

The top floor of the museum includes also a set of display cases for the flagship Dura-Ace and XTR groups starting with the 1973 version, then 1984, 1996, 2004, 2012, 2016, 2021, complete with four empty displays waiting to house 2027 and the rest of what the future brings.

There’s also a library and behind this, a locked archive for researchers. This is valuable, the museum might house one of each type of bike but here the shelves are full of books, brochures and catalogues. A treasure of primary source material. This section marks the end of the tour but you’re free to wander rather than guided to a gift store and the exit.

The Verdict
An enjoyable celebration of the bicycle and a good visual history of the evolution of machines. This might be the Shimano Bicycle Museum, and it is full of Shimano componentry, but this is firmly a bicycle museum with very little about corporate history and no hard sell either. If you want a Shimano t-shirt or some components you won’t find them here.

It covers the history of bicycles and puts the machine first, all sorts sit under spotlights and pleasantly within reach if you want to look at any details up close, from the crinkled cast iron of early bikes to the exploded disassembly of a modern race bike down to the last component.

There are other bicycle museums in the world but many are smaller and have the feel of hobby projects. Sometimes there can be excellent temporary collections in science or art museums, Merckx-Ickx was a fun example. This one works well as a permanent collection – Giant has a possibly similar one in Taiwan – and enhanced by its architecture, it is spacious (4,223m² says the museum spec) and peaceful inside. The top floor with its research archive bolsters all of this.

Access
Sakai is a city about 15km south of Osaka, Japan. It’s a 30 minute train ride from Osaka central station to Sakai or Sakaihigashi stations, the latter is closer to the museum. There’s bike parking of course.

Admission is listed JPY 500 (less than €3) but has the price gone up? I didn’t keep the receipt but a vague memory of having paid more. It’s still cheap if they doubled the price.