{ "description": "Browse aymeric's, an independent, searchable archive of readable snapshots from followed feeds, preserved in Git with aggr.", "feed_url": "https://aggr.aymericbeaumet.com/sources/andrewkelley.me/feed.json", "home_page_url": "https://aggr.aymericbeaumet.com/sources/andrewkelley.me/", "items": [ { "content_html": "

This is a blog post version of the talk I delivered at Software Should Work 2026. Shoutouts to Isaac Van Doren for running such a delightful conference and nailing it first try, and for infecting us all with his charming enthusiasm for Columbia, Missouri.

\n

Japanese translation: 黒い錠剤、服すべからじ (日本語)

\n

Part 1: The Pill

\n

\"matrix

\n

When I gave this talk, I warmed up the crowd by asking the audience who liked the 1999 film The Matrix. Roughly half raised their hands. But the kicker was the followup question, "who has never seen this movie?". 10 brave youngsters raised their hands to audible gasps.

\n

In this movie, there's an iconic moment where our hero, Ted "Theodore" Logan, is presented with two choices, the red pill or the blue pill.

\n

The question is essentially "Do you want to know an uncomfortable truth?"; the blue pill means "no" and the red pill means "yes".

\n

\"matrix

\n

To the audience, the answer is obvious. If the main character chose blue, the credits would roll before anything happened. But the metaphor is so strong and the cinematography kicks so much ass that the scene influenced our culture and language to the point where people who haven't even heard of the film say the phrase "based and red-pilled".

\n

Let's talk about the "black pill".

\n

\"sad \"sad

\n

It comes from "incel" culture. The word is a portmanteau of "involuntary" and "celibate". Basically, young men who had trouble dating started complaining about it together on the Internet. So far, so good, but an unfortunate feedback cycle emerged. Those who used the space in a productive manner, such as brainstorming, encouragment, mentorship, etc., tended to shape up, mature, work through their problems, and, to put it bluntly, get laid. At that point, they didn't really feel like sticking around and commiserating anymore, so they left. This was a natural filtering process. Thus, when new, impressionable youngsters entered the community, they were greeted only by miserable, hopeless, antisocial losers. Over time the culture became so toxic that the accepted wisdom became, essentially, "Give up. The game is rigged. There is nothing you can do. You might as well lie down and rot."

\n

In short, the "black pill" is nihilism mixed with depression mixed with anger, and in the worst case leads to outcomes like suicide or school shootings.

\n

I almost fell into this trap. Speaking from experience, entering the dating scene as a young man can be challenging to the point of despair. I was raised by conservative Christian parents and had so, so much to learn and to unlearn about the world in order to date comfortably and confidently.

\n

\"party \"party

\n

Perhaps you may be surprised to hear this but what helped me get out of this spiral was listening to pick up artists. Looking back, I think what these guys mainly have to offer is its own form of nihilistic, manipulative toxicity, but one of them said something that I instantly realized was key. He said that you shouldn't focus on the outcome of "the pick up". The actual move, he said, is to work on being attractive, in general, to everybody. Platonic friends included. You should try to make everyone want to be around you, because you genuinely care about them. Listen intently to what they say. Make them laugh. You offer people whom you interact with meaningful experiences that make them remember you and invite you to future events. You put effort in to make everyone have a good time. By doing this, you create more circumstances where there is a chance for romance to spark. It's genius!

\n

My takeaway here is that the kids are alright. Even when exposed to a bunch of bad ideas, if good ideas are also in the mix, they'll figure it out.

\n

Let's bring this a little closer to home.

\n

\"Cory

\n

This is Cory Doctorow. He's the guy who coined the term "Enshittification". He worked for Electronic Frontier Foundation for a while before becoming a fulll-time writer. In 2019 he published a short story called "Radicalized". The story centers around an online forum of people who commiserate together because they got screwed over by heath insurance companies. Listen to this excerpt and see if it sounds familiar:

\n
\n

In a forum for ex-drunks, there’s a big group of elder statespeople who’ve been sober for years and years. They’re a wise, moderating voice, and they are the existence of proof of life after addiction. Whenever someone on the forums went on a bender and was recriminating with themselves, there was a dried-out elder who could tell a story to top theirs, about being put out on the street, losing their kids, losing their limbs, even, and coming back from it.

\n

Fuck Cancer Right In Its Fucking Face did not have those people. The people who got over their furious grief left [the forum], chased away by its rage culture. The people who stayed were really into their anger, clinging to it like a drunk refusing to let go of a bottle.

\n

If your anger took you to a place you couldn’t handle, a place that scared you, the elders of [the forum] would help you all right: they’d explain to you that this was the right reaction, the only reaction, and it was never, ever going to get better. This was your life from here on in.

\n
\n

Five years after Doctorow published this fictional short story, the real life CEO of the American health insurance company UnitedHealthcare was shot to death, bullets cased with the words "deny, defend, depose".

\n

Part 2: Software Should Work

\n

\"software

\n

The main purpose of a conference like this is technical. At its core, it's a "safe space" where the attendees already agree that software should work, and it should be fast, and it should prioritize the user experience, and so all we have to do is share tips, tricks, demos, and research with each other on how to better accomplish these things.

\n

But if we neglect the meta examination here, our efforts are in vain. The implication of the phrase "software should work" is that often in the real world, we find that it doesn't work.

\n

Right?

\n

Why not?

\n

What's stopping software from working?

\n

\"moon

\n

Is the problem simply ignorance?

\n

Are programmers not programming hard enough?

\n

Is the software engineering field too nascent?

\n

Have we not discovered how to make robust software yet?

\n

I would argue that mankind discovered how to make robust software before I was even born. There's a case to be made that the overall robustness and performance of software has decreased since then, despite hardware being many orders of magnitude more capable.

\n

What gives?

\n

Have you, dear reader, ever attempted to make software work better at a company you worked for as an employee or contractor, and you were shot down by management, saying that the business had other priorities?

\n

\"pictures

\n

You know the kind of relationship I'm talking about. Management is Pointy Haired Boss, and you're Dilbert. Management is Rusty Venture, and you're Brock Sampson. Management is Michael Scott, and you're...any other character from The Office.

\n

The reality is that we software engineers already have a strong drive to make software work well, but there is a non-technical opposition.

\n

Let's talk about Benevolent Noncompliance: a form of rebellion where the beneficiary is also the authority.

\n

Asking for forgiveness rather than permission. When I gave this talk at SSW '26, about 75% of the audience fessed up to having done this (including myself).

\n

Secrecy. Normally you want to claim credit for doing good things at work. But sometimes we find ourselves doing the necessary things to make the business run smoothly in full secret, knowing that if management found out they would actually stop it.

\n

Inception. You have a meeting with management, and fool them into believing they have come up with an innovative, brilliant solution to the problem you bring to their attention. Of course, this "innovation" just so happens to be exactly what you carefully planted in their head during the meeting.

\n

Misdirection. Management wants to argue with you about something so whenever you do important work, you time it to coincide with less important work that you intentionally create more fanfare around. Management takes the bait and gets involved in the trivial distraction work, leaving your important work alone. It's kind of like giving your child a Fisher Price toy oven so they stop fucking around with the hot stove and burning themselves.

\n

The "duck". You intentionally put an obvious problem for management to identify and claim credit for removing, again leaving your important work alone. As the lore goes:

\n
\n

The artist working on the queen animations for Battle Chess was aware of this tendency, and came up with an innovative solution. He did the animations for the queen the way that he felt would be best, with one addition: he gave the queen a pet duck. He animated this duck through all of the queen’s animations, had it flapping around the corners. He also took great care to make sure that it never overlapped the “actual” animation.

\n

Eventually, it came time for the producer to review the animation set for the queen. The producer sat down and watched all of the animations. When they were done, he turned to the artist and said, “that looks great. Just one thing - get rid of the duck.”

\n
\n

Of course, all of these amusing tricks are alternative coping mechanisms to either quitting, confrontation, or acceptance. Consider that all of these, other than accepting your fate to create subpar software, are gambles. If you be tricky, you risk getting caught and reprimanded, possibly fired without severance. If you quit, you endure stress and uncertainty in the job market. If you confront management, you risk silent retaliation and loss of political advantage within the company.

\n

Now consider how the job market affects this dilemma. When the supply/demand ratio favors software engineers, we enjoy stronger negotation power. Rather than being afraid of getting fired, our managers are afraid of us quitting.

\n

When computers were first invented, we drew incredibly strong negotiation power from the scarcity of fellow programmers. But now the free market is catching up with us, and we face the same struggle as workers of other industries. We are learning that software quality was maintained only through the will of software engineers combined with their accidentally strong negotiation position in the job market.

\n

Part 3: Agency

\n

\"drawing \"drawing

\n

This is a transistor - the fundamental unit of modern electronics.

\n

The key concept here is that it's an automated switch. Even just a teeny weeny smidge of voltage into the base terminal controls whether a relatively large current flows through the other two terminals.

\n

We practically worship these things.

\n

\"the

\n

It's beautiful because it is both literally how computers work at a microscopic scale, and also metaphorically what they do at a macro scale. It is a mechanism by which something weak controls something strong; a device where an arbitrary amount of power is wielded by an effortless indication of intent.

\n

But who gets to decide whether "true" or "false" is sent into the base terminal?

\n

Whom does the software serve?

\n

This is something that I would like to try to help non-tech-savvy people be a little bit more savvy about.

\n

For example, when I run a browser on my computer, that's literally called a "user-agent". The browser is acting on my behalf; it serves my interests, not those of websites I visit. That's why I can use AdBlock even though websites don't want me to, and they can't do a lick about it.

\n

DRM is an example of software that is actively hostile to the end user. DRM makes the user's own hardware serve the interests of a third party. You might argue that DRM indirectly is in the interest of consumers because it's the only reason that copyright holders will allow them to view their copyrighted works. I'm not talking about indirect interest, or consumers. I'm talking about end users of software, those who are directly interacting with it.

\n

\"book

\n

Computers should always serve the person directly interacting with them.

\n

I always thought it was interesting that Isaac Asimov encoded this into his laws of robotics:

\n
\n
    \n
  1. A robot may not injure a human being or, through inaction, allow a human being to come to harm.
    2. \n
  2. A robot must obey the orders given it by human beings except where such orders would conflict with the First Law.
    3. \n
  3. A robot must protect its own existence as long as such protection does not conflict with the First or Second Law.
    4. \n
\n
\n

In Asimov's sci fi universe, robots are flat out exempt from participating in the hierarchical power structures of humanity, other than those strictly necessary to prevent harm.

\n

For instance, if the police got a warrant for a suspect's arrest for a nonviolent crime, and they told a robot, go arrest that person, when the robot arrived at the door, the suspect could just tell the robot to fuck off, and the robot would say "of course, sorry for bothing you."

\n

\"All

\n

Another expression of the same concept is this meme. It's a goofy formulation but it expresses a fundamental ideal: machines are meant to serve humans. This is a line that must not be crossed on a spiritual level.

\n

What we're seeing instead in the modern real world, is computers harnessed for coercion. We take the Holy Device - the transistor - and operate the control terminal as usual. But rather than wield the power of machines, we perform forbidden alchemy to bond our fellow humans to the transistor, indulging our sick, perverted fantasy of manipulating people as if they were soulless robots whose purpose is to do our bidding.

\n

Everywhere we look, we can see examples of Coercionware: attempting to treat the human mind as an instruction set architecture.

\n

Mechanical Turk. This is right on the nose. It's a business model that directly treats humans as robots, paying them less than minimum wage.

\n

Bossware. Trying to control employees to a fine degree all the way down to eye and bowel movements.

\n

\"scene

\n

Intrusive Advertisement. To whatever degree it is effective, it is literal mind control. But even ineffective advertisements interrupt our thought patterns and steal our attention, depriving us of agency.

\n

Push Notifications. Unless the user specifically and intentionally enables such a feature, it's an effort to not only programmatically control their behavior, but to reduce the latency of compliance.

\n

A/B Testing. It prioritizes outcome over intentionality. How should we design our user experience? Don't worry about it, just maximize clicks and revenue, even if that ends up being a dark pattern. In fact it offers plausible deniability for this case. Maybe the red button causes more clicks because it subconsciously instills fear in the user. Now we don't have a paper trail of doing this with intent.

\n

\"Andrew

\n

YouTube. Both content creators and viewers are being controlled by "the algorithm". Content creators are forever stuck chasing the ephemeral preferences of the algorithm, often at the expense of the integrity of their content. Have you ever noticed how modern YouTube thumbnails are evolving to look like this? Meanwhile on the viewing side we have absolutely absurd concepts like "Crunchy-to-Alt-Right Pipeline". What in the actual fuck kind of Chthulu hell portal have we opened, that this is a thing?

\n

\"granola

\n

AI Agents. Sleight of hand. AI agents purport to serve the user, but in reality the agency they serve is that of the AI company who controls the model and the closed source software surrounding it. If you don't control the source code, you are not in control.

\n

Dark Patterns. These are just openly coercive, not much to say here. It is mindblowing to me the degree to which computer users regularly tolerate this outright hostility.

\n

\"Mini

\n

Doomscrolling. This is software that maximizes engagement by using content algorithms and infinite scroll. It keeps users glued to the screen and accustomed to consuming content chosen for them. To be clear, most people when they say "doomscrolling" are talking about a bad habit, e.g. they used Facebook too much on one particular day. I'm saying that the user-facing software of Facebook is categorically, fundamentally coercive. It's like an arbitrary code execution exploit running on our brains. Scrolling down is the program counter, and the content that pops up is the instructions.

\n

A weird side effect of this is that it means our brains can get hacked, just like computers. Although the content selected by the algorithm is intended to serve the company which is providing the software, it leaves our brains also vulnerable to malicious third parties.

\n

This is a quote from the Office of the Director of National Intelligence in January 2017, summarizing work of the FBI, the CIA and the NSA:

\n
\n

President Vladimir Putin ordered an influence campaign in 2016 aimed at the U.S. presidential election. Russia's goals were to undermine public faith in the U.S. democratic process, denigrate Secretary Clinton, and harm her electability and potential presidency. We further assess Putin and the Russian Government developed a clear preference for president-elect Trump. We have high confidence in these judgments.

\n
\n

No matter what your political leanings are, if you value democracy, this should be alarming.

\n

The primary methodology used was a state-sponsored troll farm waging a social media campaign. It's really not far-fetched to say that we were mind-hacked, and that the vulnerability stems from the manipulative software practices of social media, and that the vulnerability has not been patched, and is still being actively exploited.

\n

\"Mark

\n

No one is even working on a fix. Certainly not this guy:

\n
\n

I think the idea that fake news on Facebook influenced the election in any way, I think is a pretty crazy idea.

\n

- Mark Zuckerberg, 2016

\n
\n

Each year that goes by, it gets more difficult to be an empathetic person who loves computers. Seeing the potential for what software could be doing for humanity versus the stark reality developing before our eyes is depressing. It can feel hopeless. Sure, we want things to be different, but is there actually anything we can do? It seems like every day we're being asked to "call our representative" or sign a petition or deal with the next emergency. We're always losing ground, never getting anything back.

\n

"I'm tired, boss."

\n

Our agency is under attack from all sides, and we're losing even the ability to opt out as more of our society becomes integrated with software. I lost touch with an entire group of friends because they exclusively do their event organization on Discord.

\n

The black pill offers relief in the same way that submission offers peace. To take the black pill is to relinquish the magic of computers, and surrender to their oppression.

\n

I would like to call attention to some black-pilled takes that I've seen in the wild. I want to be crystal clear here: the point is not blame or shame, but empathy. Even the last one. These are examples of attempts to cope with a very real sense that something is wrong.

\n

Let's start with a low stakes one.

\n

"Computers were a mistake."

\n

Sigh. I find it aggravating when a fellow programmer says this. I hear this occasionally from people who have not only made their entire career out of programming but also made it their primary hobby. I understand that they're just being edgy, it's supposed to be a tongue-in-cheek, it's a self-aware joke. But in my head I'm screaming, you are the one making computers do stuff! It denies all agency.

\n

Using AI even though you don't like it, or in a way that you find distasteful, because you think you have to. If you legitimately like to use AI, it's a different story. But I've seen way too many blog posts of people describing the joyless way in which they've begrudgingly started using it at work and how it makes them depressed but this is their new reality now. I have a friend who manages a team of people who told me that they are working 50+ hour weeks, using AI to try to eliminate the jobs of other teams at the same company, out of fear that if they don't do it, it will happen to them.

\n

\"screenshot

\n

Another one is Anubis. We've all seen this pop up right? It's web scraping deterrence software. I know it's being used by Linux kernel mailing list, Codeberg, FFmpeg, Wine, and a few other things.

\n

Some people take issue with the fact that the default configuration has an image of an anime girl mascot. Honestly I feel bad for those people. Imagine living such a bland, colorless existence that this cutie is offensive. They probably think ketchup is spicy.

\n

\"depressed

\n

On the other hand, I find deployment of the software, at its core, depressing, because of its "salt the earth" approach. It changes something that should be computationally cheap and anonymous - visiting a website - to being, by design, an order of magnitude more expensive. It breaks forum link previews, it depletes batteries, it removes the option for the visitor to disable JavaScript, and it excludes bots from accessing the web for legitimate reasons. It whispers bitterly in your ear, "there is no winning. There is only deferred loss" as it surrenders the open web without a fight.

\n

\"screenshot

\n

Next we have... myself! This is a screenshot of me declaring, on Hacker News, "The Site Is Trash Now" which I'm not gonna lie is a pretty black-pilled take. Go ahead, you can have a laugh at my expense. It's melodramatic, I know. But also, this comes from a real place. It saddens me that the value I used to derive from this website is eroding.

\n

Another pattern I've seen recently is people giving up on Free and Open Source Software out of disillusionment, particularly due to AI companies. They'll say things like, "the joy is gone. I'm not going to share my code anymore because it'll just get scraped and used to build the next LLM." To me this is completely missing the point, which is to pool effort in order to ensure that, in general, users of software remain in control of that software. To this end, it doesn't really matter if your code gets picked up by AI companies. It primarily matters whether high quality Free Software is available to users, providing competition that limits the degree to which proprietary software can get away with being coercive. If you refrain from participating in the software of the commons, the only thing you're doing is surrendering more of our collective agency to abusive, centralized powers.

\n

Finally we have dismissal of ethical considerations with the excuse "if I don't do it, someone else will". Deep down, we know that some lines should never be crossed. But this kind of fatalistic thinking sends our moral compass spinning and erases our willingness to stand up for our beliefs.

\n

Part 4: Faith

\n

\"Book

\n

When I was a child my parents raised me to believe in Protestant Christianity. I didn't have a choice. Right and wrong was given to me as a package deal.

\n

As I reached adulthood, I started to untangle that upbringing little by little. The process is called "deconversion", and it takes many years. For some, a lifetime. If you have a similar background as me, or you're curious to learn more, I recommend the audio version of this book which is narrated by the author, Seth Andrews. He has a really nice voice.

\n

\"photograph

\n

One of the challenges deconverts must face is forging a morality framework. You can't derive right and wrong from nothing. If you try, you'll get stuck at "I think therefore I am". Philosophically, there is nothing beyond this that can be proven without introducing a core, foundational premise.

\n

\"Album

\n

We are technologists. We love machine.

\n

As technologists, our role is to accelerate humanity along its current trajectory. The same technology can be a force for Good or a force for Evil depending on who wields it. Nuclear energy as it exists today is literally the controlled explosion of an atomic bomb. The fruit of our labor is indiscriminate multiplication of the path humanity is already walking. Thus, if humanity is Good, then technology is Good. And if humanity is Evil, then technology is Evil.

\n

This is why we must believe that humanity is generally Good.

\n

Otherwise, what are we even doing?

\n

\"portrait

\n

This is Stanislav Petrov. In 1983, during the Cold War, his job was to monitor an early reporting system for attacks and notify his superiors for immediate retaliation. On September 26th, the system reported five missiles had been launched by the United States. Thinking quickly and critically, he suspected it to be a false alarm, and disobeyed orders, disregarding Soviet military protocol to wait for an additional confirmation. (source)

\n

The confirmation never came. It was indeed a false alarm in the computer detection system. Had he followed protocol, it's very likely that his superiors would have launched an assault against the United States, triggering an all out nuclear war.

\n

Later in an interview, Petrov said that he was never absolutely sure that it was a false alarm. He said he thought the odds were 50-50. Can you imagine what he must have felt in that moment? Think of the sheer magnitude of risk that he bore to disregard protocol.

\n

50-50. That means when it came down to it, he made a choice based on something other than the evidence before him. He chose to believe that mankind is Good. He chose faith in humanity.

\n

Part 5: Youth

\n

This is the cover art for Ninajirachi's debut full length album, I Love My Computer. Take a moment to let it wash over your neurons...

\n

\"Album

\n

If this tickles your curiosity, do yourself a favor, go watch her music video for Infohazard, then come back.

\n

...

\n

...

\n

...

\n

Welcome back. I know, right?!

\n

I don't know how this hits for other generations, but for millenials like me, there's just something about Ninajirachi's art that strikes a chord. I'll do my best to put it into words for you.

\n

This is someone who still believes in the magic of computers. She captures and evokes precious, nostalgic feelings that I have deep within me from when I was growing up and discovering that magic for myself. But she's one decade younger than me, so you can see the modern web on full display. In this very article I complained about YouTube and Discord, while they're featured prominently in that music video. I don't think I'm wrong to call out dark patterns where I see them, but at the same time, I've lost something along the way.

\n

Young people lack the wisdom that comes from hardship. They fall for scams, uncritically participate in corporate viral marketing campaigns specifically aimed to take advantage of them, believe improbable things, and take risks that could lead to permanent harm. They try stuff that, to an older person, is obviously going to fail. This is because they are not yet jaded. Their belief system has not yet been scarred by living in this world. They lack the coping mechanisms that older people have developed over time to avoid getting hurt the same way over and over again. This is both a blessing and a curse. Older people are more adapted to living in the real world, but young people are more driven to change it. We need the wisdom that comes with age, but we also need the blind eagerness of youth, the willingness to try again something that has already failed a million times. We need unfettered optimism; the ability to find joy even in the wasted ruins of what was once a great city.

\n

\"Young

\n

There's a scene from Hunter x Hunter where the main protagonist, a 12 year old boy who goes out adventure seeking, faces a betrayal so devastating, that he ages 10 years on the spot in order to gain the power necessary to defeat his adversary. It's an extremely powerful scene. His despair is too great to bear, and when he turns to apathy as a coping mechanism, his body literally transforms into an adult. It depicts in a singular moment, what typically happens to us gradually over time.

\n

Our task, as the older generation, is to shield the youth from those who would exploit their naïveté, without infecting them with our own accumulated pain and cynicism.

\n

I'll leave you with one final message, addressed to people of all ages, whether you are younger than me, a peer, or my elder.

\n

We don't have to take it lying down.

\n

Next time you're feeling alone, count your allies: VideoLAN Organization, Blender Foundation, Software Freedom Conservancy, Electronic Frontier Foundation, Linux Foundation, Signal Foundation, KDE e.V., the PostgreSQL Community, the Debian Community, and so, so many more.

\n

Just look at how eager people were to come together, even from places as far away as Greece, for the inauguration of a conference with a manifesto as simple as "software should work".

\n
\n

"I wish it need not have happened in my time," said Frodo.

\n

"So do I," said Gandalf, "and so do all who live to see such times. But that is not for them to decide. All we have to decide is what to do with the time that is given us."

\n

J.R.R. Tolkien, The Fellowship of the Ring

\n
\n

The battle against Coercionware is only beginning, and we find ourselves on the frontlines whether we like it or not, because we are the ones who make computers do what they do.

\n

But we are not alone, and computers truly are magic. Do not mistake lost ground for lost hope. We can win this thing if we collectively choose to believe it and bet on it.

\n

All in.

\n

\"burning

\n

Thanks for reading my blog post.

\n", "date_modified": "2026-07-31T17:59:33+00:00", "date_published": "2026-07-31T17:59:33+00:00", "external_url": "https://andrewkelley.me/post/dont-take-black-pill.html", "id": "urn:aggr:item:b1f199255bb1329aa52b4cca31e6ffd4c429a704", "language": "en-US", "summary": "Don't Take the Black Pill (Text Adaptation) This is a blog post version of the talk I delivered at Software Should Work 2026. Shoutouts to Isaac Van Doren for running such a delightful conference and nailing it first try, and for infecting…", "tags": [ "programming" ], "title": "Don't Take the Black Pill (Text Adaptation)", "url": "https://aggr.aymericbeaumet.com/items/andrewkelley-me/2026-07-31-don-t-take-the-black-pill-text-adaptation/" }, { "content_html": "

Context: Rewriting Bun in Rust

\n

History

\n

When Jarred joined the Zig community about 5 years ago, I described him as someone who had strong "beginner energy". That is, he moved fast and tried a lot of different stuff, jumping head first into problems that he was not yet equipped to solve, leading to mediocre outcomes in terms of engineering, but learning a whole heck of a lot in the process. I see it as quite a healthy attitude, particularly for young people and students. This is the best way to level up and learn new things.

\n

As he focused his efforts on Bun he began to attract attention. JavaScript being the most popular programming language in the world, there are a lot of potential eyeballs on a promising new toolchain.

\n

This attention could have been harnessed in a few different ways. For example, he could have easily achieved a solid living via crowdfunding, even for San Francisco standards. But having graduated from the Thiel Fellowship school of thought rather than university, he was essentially groomed from a young age into uncritically embracing the Silicon Valley mindset, and he took venture capital.

\n

From the beginning, Jarred was appreciative towards the Zig project. He credited Zig on the Bun website for the project's performance achievements. He set up a monthly donation to Zig Software Foundation that amounted to $60,000 per year. He didn't have to do either of those things, but he did, and it was pretty cool of him. Even in his blog post that I'm referencing, he expresses what I perceive as sincere grattitude towards the Zig project.

\n

However, once Bun became a VC-backed startup, he started racing towards the finish line. Now, instead of working on a free and open source project, learning and growing with the community, Jarred was running a business. It was at this point - when he suddenly became a manager - that this "beginner energy" started to hit differently for me. It's one thing to choose a poor work-life balance for oneself; a different thing entirely to demand it of others:

\n
\n

"Oven is going to be a grind, especially the first nine months or so. If work-life balance to you means a lot of time spent not working, it’s probably not a good fit right now."

\n
\n

Fun fact: people talk to each other.

\n

I talked to those who interviewed for a job at Oven. I talked to people who worked there. Those people talked to each other. Everybody talked to everybody. The grapevine was large and healthy and full of juicy grapes, and all those grapes contained the juice of the same message: Jarred was a stinky manager. Poor communication, unrealistic expectations, low empathy, no experience. Just a total shit show, from an employment perspective.

\n

Consequently, although Zig community members were eager to find work coding in Zig on the clock, most of the talent pool steered clear of Oven and Bun.

\n

At the same time, a rift between Zig and Jarred started widening. His singular focus on productivity and his startup's exit strategy was increasingly at odds with my longer term vision for the Zig project. I remember he kept nagging me to drop all my other priorities and work on a Language Server Protocol implementation and VSCode integration, while I had bigger plans.

\n

The main problem, however, was code quality.

\n

The Zig team regularly checks in on our users' projects. We read source code to find out how the language is affecting users, we test changes to see how problematic breakage might be, and we check for performance regressions.

\n

We became increasingly horrified at the programming practices we saw in Bun's codebase. Hacks on top of hacks. Abuse of assertions. Most of all, recklessly speeding past feature after feature with very little time taken for reflection and elimination of bugs and technical debt. Jarred was already writing slop well before he had access to LLMs. Now, it's not our business to police what our users do, but you may have noticed people screaming in our faces about memory safety constantly. You can imagine how we might want to put some social distance between ourselves and a project whose irresponsible software engineering practices invite the exact kind of criticism that people are eager to level.

\n

We made futile attempts to guide them towards better programming practices. There were a few exceptional heroes who did their very best in a dysfunctional company. You know who you are. But you can't stop a rising tide.

\n

By this time, we all felt at ZSF that Bun was a net liability, and this was before RoboBun became the #1 contributor. Along with the discomfort of the publicly presumed poster child for Zig programming language actually being the prime example of How Not To Write Zig Code, at some point they would sell out (let's be honest, their vague "sell some cloud something" business plan was a farce from the get-go), we would receive some negative publicity by proxy, and we'd stop getting that regular donation.

\n

So, when the Anthropic aquisition finally happened, we at ZSF breathed a sigh of relief. When the donation silently stopped, our bank account was ready for it. When they neither canceled their monthly meeting with us, nor showed up, we were not surprised. The relationship was over.

\n

The (re)writing was on the wall. Even within a couple days, we already suspected a Rust rewrite was coming. And we were rooting for it! The acquisition by a large AI company was a burden, because even the indirect connection of Claude being written in Bun being written in Zig caused not only a surge of drive by slop contributions, but also an influx of tasteless AI enthusists into Zig communities who had to be informed that it's antisocial to paste LLM output into forum posts. For a moment, I feared Zig's identity would become known colloquially as a programming language associated with AI.

\n

When Jarred announced the Rust rewrite, we were ecstatic. It seemed too good to be true. I have to admit, I didn't think the technology was there, to pull off this stunt. But he did it, and now I'm metaphorically sipping delicious tea from a mug that says "It Tastes Like It's Not My Problem Anymore".

\n

Addressing the Blog Post

\n

The blog post is expertly written. It's almost like the marketing department of a trillion dollar company has a lot of money riding on this article.

\n

I do have some bones to pick however.

\n

There's a dichotomy being presented here where you have to either choose a "style guide" or a programming language feature in order to avoid bugs. The sleight of hand misdirects the reader away from the main way bugs are eliminated: by dedicating engineering resources to it. You're not giving TigerBeetle nearly enough credit. Quite simply they put in the time to find and eliminate the bugs, they make an effort to maintain a healthy relationship with ZSF, and Bun did neither of those things.

\n

The argument for shipping all the million lines of unreviewed code is that the test suite is good enough to catch everything. Then why are you saying you have so many annoying bugs in the Zig code? What happened to the test suite being sufficient to catch everything? It's not sufficient to catch bugs in Zig code but it is sufficient to catch bugs in 1 million lines of unreviewed slop?

\n

Performance increase is attributed to LTO, which Zig has supported for all of Bun's existence. It used to be enabled by default until we ran into too many LLVM bugs, all of which also affect Rust. We probably tried to tell you to try enabling it and you didn't listen. We have good advice, damn it!

\n

The post implies you were diligently fuzzing your Zig code, while during our calls the Bun team told us that they were not fuzzing anything.

\n

The blog post outlines a bunch of engineering work done to reduce binary size, to better make the case that "Bun is better in Rust". But all that engineering work had nothing to do with the rewrite. I think this (specifically the "binary size" section of the blog post) is precisely why it took so long for the blog post to come out, you were doing the engineering work that you should have done in the Zig codebase since the beginning. We've been trying to warn you about your comptime abuse for years. We even made this time report thing specifically for projects that need to audit their use of comptime/inline usage and compile times.

\n

I noticed that you neglected to mention compilation speed. Zig compiler project is about 600,000 lines of code - roughly the same size as Bun before the rewrite, and I'm clocking 16s to build from scratch with a clean cache, followed by 90ms for each subsequent edit with incremental compilation enabled. What are the corresponding measurements of Bun post-rewrite?

\n

Moving On

\n

The main issue here had nothing to do with the language features of Zig vs Rust, and everything to do with the diverging value systems of the two projects and the relationship breakdown that followed.

\n

Zooming out a bit, I want to make one thing clear.

\n

While I resent Jarred for making Bun into an embarassment for Zig, and I blame him partially for some of the slop we've been dealing with, and I stand by my criticism of his leadership, I also empathize with him. He has different values than me, he wants different things out of life than me. But I think he's actually happy and successful exactly where he is. He figured out how to accomplish all the stuff that he wants. He gets to live out his productivity fantasy fever dream, he's probably already super wealthy. He has minor tech celebrity status.

\n

Honestly, I think he did well for himself, and despite my feelings of resentment, and despite the fact that I find myself battling the marketing arm of Anthropic, I don't wish him any ill will. Even in the midst of my frustration, I am happy for him and his success, by his own standards.

\n

This blog post has been characterized as a personal attack against Jarred, while I originally framed it as telling the story of a failed business relationship. My framing didn't work because I had unprocessed emotions of resentment, that were obvious to the reader, but not to myself. I've updated this conclusion section after self-reflection and chatting with friends. Feel free to go look at the original text in this website's public source repository.

\n

The other critical mistake I made with this post was failing to consider the rather obvious and important point that this might affect Zig users who knew next to none of these facts and have only the surface level understanding that an ex-Zig-user is getting trashed by the language creator. Such people might reasonably worry that might happen to them. I'm sorry to those who I made feel this way. At this point, all I can say is that myself and other ZSF folks have outstanding relationships with essentially everyone who openly uses Zig and talks about it publicly, and this incident is the one exception. Plenty of people have decided to move away from Zig with zero fuss. I hope you can give me some grace considering a trillion dollar company fired the first shot.

\n

Clearly, the move from here is to focus my blog on positive things like demoing what I've been working on lately, in order to better give an accurate impression of reality about what's going on in the Zig community: a bunch of chill people are collaborating on cool stuff, and having a great time doing it.

\n

Thanks for reading my blog post.

\n", "date_modified": "2026-07-09T04:56:58+00:00", "date_published": "2026-07-09T04:56:58+00:00", "external_url": "https://andrewkelley.me/post/my-thoughts-bun-rust-rewrite.html", "id": "urn:aggr:item:953a951041bd7bcd8072ebe8ce87d96c7a8a9563", "language": "en-US", "summary": "My Thoughts on the Bun Rust Rewrite Context: Rewriting Bun in Rust History When Jarred joined the Zig community about 5 years ago, I described him as someone who had strong \"beginner energy\". That is, he moved fast and tried a lot of…", "tags": [ "programming" ], "title": "My Thoughts on the Bun Rust Rewrite", "url": "https://aggr.aymericbeaumet.com/items/andrewkelley-me/2026-07-09-my-thoughts-on-the-bun-rust-rewrite/" }, { "content_html": "

In celebration of the std.Io introduction patchset landing today, here is the text version of a short, interactive demo I gave at Zigtoberfest 2025.

\n

This is a preview of the new async I/O primitives that will be available in the upcoming Zig 0.16.0, to be released in about 3-4 months. There is a lot more to get into, but for now here is an introduction into some of the core synchronization API that will be available for all Zig code to use.

\n

To begin, let's try to keep it simple and understand the basics, and then we'll then slowly add more asynchronous things into it.

\n

Example 0

\n

With our first example, there is nothing asynchronous here. It's basically "Hello, World!" in Zig.

\n
const std = @import("std");\n\npub fn main() !void {\n    doWork();\n}\n\nfn doWork() void {\n    std.debug.print("working\\n", .{});\n    var timespec: std.posix.timespec = .{ .sec = 1, .nsec = 0 };\n    _ = std.posix.system.nanosleep(&timespec, &timespec);\n}\n
\n

Output:

\n
0s $ zig run example0.zig\n0s working\n1s $\n
\n

Example 1

\n

Next, we're going to set up a little bit. Still not using async/await yet, but I need some tools in my toolbox before we add complexity.

\n
const std = @import("std");\nconst Io = std.Io;\nconst Allocator = std.mem.Allocator;\nconst assert = std.debug.assert;\n\nfn juicyMain(gpa: Allocator, io: Io) !void {\n    _ = gpa;\n\n    doWork(io);\n}\n\nfn doWork(io: Io) void {\n    std.debug.print("working\\n", .{});\n    io.sleep(.fromSeconds(1), .awake) catch {};\n}\n\npub fn main() !void {\n    // Set up allocator.\n    var debug_allocator: std.heap.DebugAllocator(.{}) = .init;\n    defer assert(debug_allocator.deinit() == .ok);\n    const gpa = debug_allocator.allocator();\n\n    // Set up our I/O implementation.\n    var threaded: std.Io.Threaded = .init(gpa);\n    defer threaded.deinit();\n    const io = threaded.io();\n\n    return juicyMain(gpa, io);\n}\n
\n

Output (same as before):

\n
0s $ zig run example0.zig\n0s working\n1s $\n
\n

Setting up a std.Io implementation is a lot like setting up an allocator. You typically do it once, in main(), and then pass the instance throughout the application. Reusable code should accept an Allocator parameter if it needs to allocate, and it should accept an Io parameter if it needs to perform I/O operations.

\n

In this case, this is an Io implementation based on threads. This is not using KQueue, this is not using IO_Uring, this is not using an event loop. It is a threaded implementation of the new std.Io interface.

\n

This setup will be the same in all the examples, so now we can focus on our example code, which is the same as last time. Still nothing interesting - we just call doWork which of course is just calling sleep().

\n

Example 2

\n

Redundant setup code omitted from here on out.

\n
fn juicyMain(gpa: Allocator, io: Io) !void {\n    _ = gpa;\n\n    var future = io.async(doWork, .{io});\n\n    future.await(io); // idempotent\n}\n\nfn doWork(io: Io) void {\n    std.debug.print("working\\n", .{});\n    io.sleep(.fromSeconds(1), .awake) catch {};\n}\n
\n

Output (same as before):

\n
0s $ zig run example0.zig\n0s working\n1s $\n
\n

Now we're using async/await to call doWork. What async/await means to Zig is to decouple the calling of the function to the returning of the function.

\n

This code is the same as before. It's exactly the same, because we didn't put any code between the async and await. We do the call, and then immediately wait for the return.

\n

Example 3

\n

In the next example, we have two things at the same time:

\n
fn juicyMain(gpa: Allocator, io: Io) !void {\n    _ = gpa;\n\n    var a = io.async(doWork, .{ io, "hard" });\n    var b = io.async(doWork, .{ io, "on an excuse not to drink Spezi" });\n\n    a.await(io);\n    b.await(io);\n}\n\nfn doWork(io: Io, flavor_text: []const u8) void {\n    std.debug.print("working {s}\\n", .{flavor_text});\n    io.sleep(.fromSeconds(1), .awake) catch {};\n}\n
\n

Output:

\n
0s $ zig run example3.zig\n0s working on an excuse not to drink Spezi\n0s working hard\n1s $\n
\n

If you look carefully, you can see that it did not wait two seconds; it waited one second because these operations are happening at the same time. This demonstrates why using async/await is useful - you can express asynchrony. Depending on the I/O implementation that you choose, it may be able to take advantage of the asynchrony that you have expressed and make your code go faster. For example in this case, std.Io.Threaded was able to do two seconds of work in one second of actual time.

\n

Example 4

\n

Let's start to bring the example closer to a real world scenario by introducing failure.

\n
fn juicyMain(gpa: Allocator, io: Io) !void {\n    var a = io.async(doWork, .{ gpa, io, "hard" });\n    var b = io.async(doWork, .{ gpa, io, "on an excuse not to drink Spezi" });\n\n    try a.await(io);\n    try b.await(io);\n}\n\nfn doWork(gpa: Allocator, io: Io, flavor_text: []const u8) !void {\n    // Simulate an error occurring:\n    if (flavor_text[0] == 'h') return error.OutOfMemory;\n\n    const copied_string = try gpa.dupe(u8, flavor_text);\n    defer gpa.free(copied_string);\n    std.debug.print("working {s}\\n", .{copied_string});\n    io.sleep(.fromSeconds(1), .awake) catch {};\n}\n
\n

It's the same code as before, except the first task will return an error.

\n

Guess what happens when this code is run?

\n

Output:

\n
0s $ zig run example4.zig\n0s working on an excuse not to drink Spezi\n1s error(gpa): memory address 0x7f99ce6c0080 leaked:\n1s /home/andy/src/zig/lib/std/Io/Threaded.zig:466:67: 0x1053aae in async (std.zig)\n1s     const ac: *AsyncClosure = @ptrCast(@alignCast(gpa.alignedAlloc(u8, .of(AsyncClosure), n) catch {\n1s                                                                   ^\n1s /home/andy/src/zig/lib/std/Io.zig:1548:40: 0x1164f94 in async__anon_27344 (std.zig)\n1s     future.any_future = io.vtable.async(\n1s                                        ^\n1s /home/andy/misc/talks/zigtoberfest/async-io-examples/example4.zig:8:21: 0x116338a in juicyMain (example4.zig)\n1s     var b = io.async(doWork, .{ gpa, io, "on an excuse not to drink Spezi" });\n1s                     ^\n1s /home/andy/misc/talks/zigtoberfest/async-io-examples/example4.zig:35:21: 0x1163663 in main (example4.zig)\n1s     return juicyMain(gpa, io);\n1s                     ^\n1s /home/andy/src/zig/lib/std/start.zig:696:37: 0x1163c83 in callMain (std.zig)\n1s             const result = root.main() catch |err| {\n1s                                     ^\n1s /home/andy/src/zig/lib/std/start.zig:237:5: 0x1162f61 in _start (std.zig)\n1s     asm volatile (switch (native_arch) {\n1s     ^\n1s \n1s thread 1327233 panic: reached unreachable code\n1s error return context:\n1s /home/andy/src/zig/lib/std/Io.zig:1003:13: 0x11651a8 in await (std.zig)\n1s             return f.result;\n1s             ^\n1s /home/andy/misc/talks/zigtoberfest/async-io-examples/example4.zig:10:5: 0x11633e8 in juicyMain (example4.zig)\n1s     try a.await(io);\n1s     ^\n1s \n1s stack trace:\n1s /home/andy/src/zig/lib/std/debug.zig:409:14: 0x103e5a9 in assert (std.zig)\n1s     if (!ok) unreachable; // assertion failure\n1s              ^\n1s /home/andy/misc/talks/zigtoberfest/async-io-examples/example4.zig:27:17: 0x1163698 in main (example4.zig)\n1s     defer assert(debug_allocator.deinit() == .ok);\n1s                 ^\n1s /home/andy/src/zig/lib/std/start.zig:696:37: 0x1163c83 in callMain (std.zig)\n1s             const result = root.main() catch |err| {\n1s                                     ^\n1s /home/andy/src/zig/lib/std/start.zig:237:5: 0x1162f61 in _start (std.zig)\n1s     asm volatile (switch (native_arch) {\n1s     ^\n1s fish: Job 1, 'zig run example4.zig' terminated by signal SIGABRT (Abort)\n1s $\n
\n

The problem is that when the first try activates, it skips the second await which is then caught by the leak checker.

\n

This is a bug. It's unfortunate though, isn't it? Because we would like to write the code this way.

\n

Example 5

\n

Here's a fix:

\n
fn juicyMain(gpa: Allocator, io: Io) !void {\n    var a = io.async(doWork, .{ gpa, io, "hard" });\n    var b = io.async(doWork, .{ gpa, io, "on an excuse not to drink Spezi" });\n\n    const a_result = a.await(io);\n    const b_result = b.await(io);\n\n    try a_result;\n    try b_result;\n}\n\nfn doWork(gpa: Allocator, io: Io, flavor_text: []const u8) !void {\n    // Simulate an error occurring:\n    if (flavor_text[0] == 'h') return error.OutOfMemory;\n\n    const copied_string = try gpa.dupe(u8, flavor_text);\n    defer gpa.free(copied_string);\n    std.debug.print("working {s}\\n", .{copied_string});\n    io.sleep(.fromSeconds(1), .awake) catch {};\n}\n
\n

We do the awaits, then we do the tries. This will fix the problem.

\n

Output:

\n
0s $ zig run example5.zig\n0s working on an excuse not to drink Spezi\n1s error: OutOfMemory\n1s /home/andy/src/zig/lib/std/Io.zig:1003:13: 0x11651d8 in await (std.zig)\n1s             return f.result;\n1s             ^\n1s /home/andy/misc/talks/zigtoberfest/async-io-examples/example5.zig:13:5: 0x1163416 in juicyMain (example5.zig)\n1s     try a_result;\n1s     ^\n1s /home/andy/misc/talks/zigtoberfest/async-io-examples/example5.zig:38:5: 0x11636e9 in main (example5.zig)\n1s     return juicyMain(gpa, io);\n1s     ^\n1s $\n
\n

This failed successfully. The error was handled and no resources leaked. But it's a footgun. Let's find a better way to express this...

\n

Example 6

\n

This is where cancellation comes in. cancellation is an extremely handy primitive, because now we can use defer, try, and await like normal, and not only do we fix the bug, but we also get more optimal code.

\n
fn juicyMain(gpa: Allocator, io: Io) !void {\n    var a = io.async(doWork, .{ gpa, io, "hard" });\n    defer a.cancel(io) catch {};\n\n    var b = io.async(doWork, .{ gpa, io, "on an excuse not to drink Spezi" });\n    defer b.cancel(io) catch {};\n\n    try a.await(io);\n    try b.await(io);\n}\n\nfn doWork(gpa: Allocator, io: Io, flavor_text: []const u8) !void {\n    // Simulate an error occurring:\n    if (flavor_text[0] == 'h') return error.OutOfMemory;\n\n    const copied_string = try gpa.dupe(u8, flavor_text);\n    defer gpa.free(copied_string);\n    std.debug.print("working {s}\\n", .{copied_string});\n    io.sleep(.fromSeconds(1), .awake) catch {};\n}\n
\n

Thanks to cancellation, we now get instant results, because the moment that the first task returns an error, the cancels get run.

\n

Output:

\n
0s $ zig run example6.zig\n0s working on an excuse not to drink Spezi\n0s error: OutOfMemory\n0s /home/andy/misc/talks/zigtoberfest/async-io-examples/example6.zig:13:5: 0x116348c in juicyMain (example6.zig)\n0s     try a.await(io);\n0s     ^\n0s /home/andy/misc/talks/zigtoberfest/async-io-examples/example6.zig:38:5: 0x1163909 in main (example6.zig)\n0s     return juicyMain(gpa, io);\n0s     ^\n0s $\n
\n

cancel is your best friend, because it's going to prevent you from leaking the resource, and it's going to make your code run more optimally.

\n

cancel is trivial to understand: it has identical semantics as await, except that it also requests cancellation. The conditions under which cancellation requests are honored are defined by each I/O implementation.

\n

Both cancel and await are idempotent with respect to themselves and each other.

\n

Example 7

\n

Next, let's introduce another real-world scenario: resource allocation. In this case, we allocate a string on success, which the caller needs to manage.

\n
fn juicyMain(gpa: Allocator, io: Io) !void {\n    var a = io.async(doWork, .{ gpa, io, "hard" });\n    defer if (a.cancel(io)) |s| gpa.free(s) else |_| {};\n\n    var b = io.async(doWork, .{ gpa, io, "on an excuse not to drink Spezi" });\n    defer if (b.cancel(io)) |s| gpa.free(s) else |_| {};\n\n    const a_string = try a.await(io);\n    const b_string = try b.await(io);\n    std.debug.print("finished {s}\\n", .{a_string});\n    std.debug.print("finished {s}\\n", .{b_string});\n}\n\nfn doWork(gpa: Allocator, io: Io, flavor_text: []const u8) ![]u8 {\n    const copied_string = try gpa.dupe(u8, flavor_text);\n    std.debug.print("working {s}\\n", .{copied_string});\n    io.sleep(.fromSeconds(1), .awake) catch {};\n    return copied_string;\n}\n
\n

Now we see why cancel and await have the same API. The deferred cancel calls above free the allocated resource, handling both successful calls (resource allocated) and failed calls (resource not allocated).

\n

Output:

\n
0s $ zig run example7.zig\n0s working on an excuse not to drink Spezi\n0s working hard\n1s finished hard\n1s finished on an excuse not to drink Spezi\n1s $\n
\n

The important thing here is that by doing resource management like this, we are able to write standard, idiomatic Zig code below, using try and return like normal without worrying about special resource management cases.

\n

Example 8

\n

Now we're switching gears a little bit. It's time to learn why asynchrony is not concurrency.

\n

In this example we have a producer sending one item across an unbuffered queue to a consumer.

\n
fn juicyMain(io: Io) !void {\n    var queue: Io.Queue([]const u8) = .init(&.{});\n\n    var producer_task = io.async(producer, .{\n        io, &queue, "never gonna give you up",\n    });\n    defer producer_task.cancel(io) catch {};\n\n    var consumer_task = io.async(consumer, .{ io, &queue });\n    defer _ = consumer_task.cancel(io) catch {};\n\n    const result = try consumer_task.await(io);\n    std.debug.print("message received: {s}\\n", .{result});\n}\n\nfn producer(\n    io: Io,\n    queue: *Io.Queue([]const u8),\n    flavor_text: []const u8,\n) !void {\n    try queue.putOne(io, flavor_text);\n}\n\nfn consumer(\n    io: Io,\n    queue: *Io.Queue([]const u8),\n) ![]const u8 {\n    return queue.getOne(io);\n}\n
\n

We use async to spawn the producer and async to spawn the consumer.

\n

Output:

\n
0s $ zig run example8.zig\n0s message received: never gonna give you up\n0s $\n
\n

This incorrectly succeeds. Depending on your perspective, we either got "lucky" or "unlucky" due to the thread pool having spare concurrency that happened to be available.

\n

To observe the problem, we can artificially limit the std.Io.Threaded instance to use a thread pool size of one:

\n

Example 9

\n
// Set up our I/O implementation.\n    var threaded: std.Io.Threaded = .init(gpa);\n    threaded.cpu_count = 1;\n    defer threaded.deinit();\n    const io = threaded.io();\n\n    return juicyMain(io);\n}\n
\n

Output: (deadlock)

\n

Now that it's only using one thread, it deadlocks, because the consumer is waiting to get something from the queue, and the producer is scheduled to run, but it has not run yet.

\n

The problem is that we needed concurrency, but we asked for asynchrony.

\n

Example 10

\n

In order to fix this, we use io.concurrent instead of io.async. This one can fail with error.ConcurrencyUnavailable.

\n
fn juicyMain(io: Io) !void {\n    var queue: Io.Queue([]const u8) = .init(&.{});\n\n    var producer_task = try io.concurrent(producer, .{\n        io, &queue, "never gonna give you up",\n    });\n    defer producer_task.cancel(io) catch {};\n\n    var consumer_task = try io.concurrent(consumer, .{ io, &queue });\n    defer _ = consumer_task.cancel(io) catch {};\n\n    const result = try consumer_task.await(io);\n    std.debug.print("message received: {s}\\n", .{result});\n}\n\nfn producer(\n    io: Io,\n    queue: *Io.Queue([]const u8),\n    flavor_text: []const u8,\n) !void {\n    try queue.putOne(io, flavor_text);\n}\n\nfn consumer(\n    io: Io,\n    queue: *Io.Queue([]const u8),\n) ![]const u8 {\n    return queue.getOne(io);\n}\n
\n

Output:

\n
0s $ zig run example10.zig\n0s message received: never gonna give you up\n0s $\n
\n

Now the code is fixed because we correctly expressed that we needed concurrency, which std.Io.Threaded honored by oversubscribing.

\n

If I add -fsingle-threaded which truly limits the executable to one thread, oversubscription is not available, causing this output:

\n
error: ConcurrencyUnavailable\n/home/andy/src/zig/lib/std/Io/Threaded.zig:529:34: 0x1051863 in concurrent (std.zig)\n    if (builtin.single_threaded) return error.ConcurrencyUnavailable;\n                                 ^\n/home/andy/src/zig/lib/std/Io.zig:1587:25: 0x1158b5f in concurrent__anon_26591 (std.zig)\n    future.any_future = try io.vtable.concurrent(\n                        ^\n/home/andy/misc/talks/zigtoberfest/async-io-examples/example10.zig:9:25: 0x1157198 in juicyMain (example10.zig)\n    var producer_task = try io.concurrent(producer, .{\n                        ^\n/home/andy/misc/talks/zigtoberfest/async-io-examples/example10.zig:48:5: 0x115776a in main (example10.zig)\n    return juicyMain(io);\n    ^\n
\n

Conclusion

\n

There are proof-of-concept std.Io implementations using IoUring and KQueue combined with stackful coroutines which show a lot of promise, however that work depends on some language enhancements to be practical. There is also ongoing design work about stackless coroutines. Here are some relevant issues to track for those interested:

\n\n

These APIs are not set in stone. It will probably take a few iterations to get it right. Please try them out in real world applications and let us know how it goes! Let's collaborate on making the I/O interface practical and optimal.

\n

Thanks for reading my blog post.

\n", "date_modified": "2025-10-29T18:44:33+00:00", "date_published": "2025-10-29T18:44:33+00:00", "external_url": "https://andrewkelley.me/post/zig-new-async-io-text-version.html", "id": "urn:aggr:item:f3ae0a3092330a9affbcce672a9c1587534f1cc9", "language": "en-US", "summary": "Zig's New Async I/O (Text Version) In celebration of the std.Io introduction patchset landing today, here is the text version of a short, interactive demo I gave at Zigtoberfest 2025. This is a preview of the new async I/O primitives that…", "tags": [ "programming" ], "title": "Zig's New Async I/O (Text Version)", "url": "https://aggr.aymericbeaumet.com/items/andrewkelley-me/2025-10-29-zig-s-new-async-i-o-text-version/" }, { "content_html": "

Note: This blog post is not a reaction to recent events or some kind of apology. Nothing happened; this is just me doing self-reflection.

\n

Zig turned 10 years old, and I've been thinking a lot about the project overall, and what another ten years of my life might look like.

\n

More specifically, I've been thinking about my interactions with people over the years, both positive and negative.

\n

Since Zig's inception, I never stepped down from the "creator" role. Although the core team has grown to about five active people, I never stopped triaging. I never stopped thinking critically about the language. I never stopped helping newbies get their bearings. I never stopped welcoming contributors to join the project. I never stopped reviewing code. I never stopped working on major features.

\n

While I'm not willing to put up with advertisements, I am perfectly willing to help beginners and advanced users alike in a traditional forum setting, where relationships can be forged.

\n

Over the last decade, I've had a fair share of negative interactions with various individuals. This actually really bothers me, because I love people. Naturally, I love my friends and family, but I also love my neighbors, and random people walking down the street. I love chit-chatting with people I haven't met before. When I was a teenager I used to make fun of the idea of "small talk", but now I proudly have mastered the art in order to spark conversations with strangers. I love people in other countries. I love people who are different than me. I love people who make fun of me. I love people with different political opinions than me. I love the person who cuts me off in traffic and flips me off. They're just having a bad day, you know?

\n

So I've been trying to figure out: why do these negative interactions happen?

\n

The reasons behind this can be complex, but I think in relation to Zig, there is one pattern in particular that has strong explanatory power.

\n

Programming language and toolchain technology can have a huge impact. Specifically, even minor differences can affect the day-to-day lives of a large number of hours for a large number of people. For example, time spent waiting to compile is multiplied by a person's time spent in a workday, multiplied by how long they are employed to use that technology, multiplied by how much that technology is used in the industry.

\n

Meanwhile, workers do not have the choice of which technology to use. They are generally stuck using what their company tells them to. Of course, one can use tricks like "it's easier to ask forgiveness than it is to get permission", but people who are bold enough to employ such tricks are typically the same people who are capable of being entrepreneurs themselves.

\n

Anyway, my point is that most people on our beautiful, precious planet will not have the opportunity to create a programming language project that reaches a level of maturity such that it can be part of their careers, or even a realistic choice for their hobby projects.

\n

And that's incredibly frustrating.

\n

Just because you don't have the madness required to dedicate 10+ years of your life working on an unproven technology, doesn't mean you don't have a valid opinion about tabs vs spaces.

\n

You, along with 99.999% of programmers, are faced with the reality of picking your favorite set of practical programming language technologies for tackling whatever problems you encounter. This presents two nasty problems:

\n\n

There is a huge range of decision-making in which the effects weigh heavily on any particular individual, and yet forking is not a realistic option.

\n

In these moments, it's only natural to be angry. I really, truly get it. I do! Because I'm a hypocrite. I do the exact same thing. There are plenty of projects that I depend on and use daily, but I know that, sadly, I'll never have time to compete with them or even meaningfully contribute to them. For example, as much as I'd love to create a mainstream operating system, I simply have too many other competing interests lined up first. And I catch myself, repeatedly, complaining about operating systems and saying harsh things about those who develop and maintain them.

\n

In other words: it comes down to lack of agency. When we care about something, but we perceive futility in our efforts to change it, our only resort is to lash out.

\n

Directly addressing those whom I've had unpleasant Zig-related exchanges with:

\n

First of all, I've had plenty of bad days. I've done issue triaging while grumpy. For that, I'm sorry. I hope in the future, I can have a more consistent pattern of expressing the warmth I feel inside my heart for my fellow humans through my everyday interactions on the Zig issue tracker.

\n

Even if I disagree with you, even if I blocked your GitHub account, even if I locked an issue after you made a comment, even if I ignored your pull requests for a long time and then closed them without even a word, I still think that you are not only justified in wanting what you want, you are also justified in feeling angry about not getting it.

\n

My friend - it's not personal. I care about you. I actually do value your opinion. I'm interested in your thoughts and feelings. I want to make you happy. I'm sad that I can't serve you better with my open source project. I want to. I wish I could.

\n

I'm hustling. I'm playing the game. I'm doing what it takes to make this thing mainstream and a viable, practical choice for individuals and companies. If you talk shit about Zig in public, I'm going to fight back. But I respect you. I see you. I understand you. I don't hate you. I would literally buy you a drink.

\n

With the dawn of another decade, I hope to maintain this perspective in my day-to-day interactions. I think I can level up - cranking up the empathy dial with my interactions - even the contentious ones - while still cultivating this budding technology; protecting it from those who would destroy or corrupt it; growing it into a flourishing global community that brings digital prosperity to all who congregate under its inclusive, welcoming tent.

\n

Thanks for reading my blog post.

\n", "date_modified": "2025-08-29T05:52:28+00:00", "date_published": "2025-08-29T05:52:28+00:00", "external_url": "https://andrewkelley.me/post/open-letter-everyone-butted-heads.html", "id": "urn:aggr:item:8410738a5aab41bddf15e62bb18d3b4e5f1e5f52", "language": "en-US", "summary": "An Open Letter to Everyone I've Butted Heads With Note: This blog post is not a reaction to recent events or some kind of apology. Nothing happened; this is just me doing self-reflection. Zig turned 10 years old, and I've been thinking a…", "tags": [ "programming" ], "title": "An Open Letter to Everyone I've Butted Heads With", "url": "https://aggr.aymericbeaumet.com/items/andrewkelley-me/2025-08-29-an-open-letter-to-everyone-i-ve-butted-heads-with/" }, { "content_html": "

A genie offers you a choice:

\n\n

Which do you pick?

\n

Your answer, of course, depends on how much capital you have. If you are struggling to pay rent, then taking the less risky gamble is quite attractive, while if you already have 10 million sitting in the bank, it's a no-brainer to press the button with the higher expected value (1 mil vs 5 mil).

\n

Despite living in a world without genies, we are presented with choices like this constantly - having more capital absorbs risk, offering choices with higher expected value.

\n

For instance, getting a payday loan is insane from a financial perspective, unless you won't be able to feed your kids this week without begging for help from an abusive relative, in which case it starts to become tempting.

\n

Paying interest on a car is equally ridiculous, unless you live in a city like my hometown where you really can't get by without a car, and you lack the capital to buy one.

\n

There's no excuse for renting a couch. Just sit on the floor.

\n

The pattern here is a reverse Robin Hood effect: those without capital borrow stuff and then pay interest to the owners.

\n

This is managing your personal finances 101, really basic stuff.

\n

But what if I told you that we are in the midst of an entire upper-middle-class not only willingly giving up ownership, but gleefully bragging about it, while transferring massive amounts of wealth from smaller companies and individuals to approximately three large companies?

\n

Manufactured Consent

\n

The section title here is of course a reference to the famous book by Edward S. Herman and Noam Chomsky but I'm going to take it in a little bit of a different direction.

\n

The introduction of this blog post is intended to be completely obvious, uncontroversial stuff.

\n

Why is it, then, that people think "moving to the cloud" is a good idea?

\n

You know what I mean, right? If you ask your colleagues, or random people on the Internet, there will be a general consensus that moving to the cloud is Good. "Oh yeah," someone will say, "we've been working on moving to the cloud, you know." "We gotta move more of our stuff to the cloud!" - totally normal thing to say.

\n

Why is something that flies in the face of basic financial planning considered good? You're switching from owning a computer to renting one, and paying two orders of magnitude more money for it.

\n

For example let's look at Microsoft pricing. Using a single macOS runner for 1 year costs 0.08 * 60 * 24 * 365 = 42 thousand USD. Meanwhile, for Zig's CI testing we purchased a beefy mac mini for $3000 two years ago.

\n

So why is everybody moving to the cloud?!

\n

My hypothesis is that this is clever strategy from cloud provider companies. Since, as demonstrated above, there is so much potential money to be gained for them, given that they are starting with a high amount of capital, they have an enormous budget, which they spend in order to capture more of the market.

\n

And what they're up against is basic math. In the words of Drew DeVault, "cloud computing is like taking money, and lighting it on fire."

\n

So how do you convince people to ignore basic math and give you their money? It's a tall order, isn't it?

\n

They do conferences. Ever notice how major software conferences are often sponsored by cloud companies? Developers are inundated with astroturfed talks which take as a premise that moving to the cloud is a sound decision. Entire careers are built upon this. Nobody is immune to propaganda. Eventually, the Illusory Truth Effect kicks in and we all start to believe it, at least to some degree, and then we start participating in doing the marketing for them, by virtue of trying to keep up to date with the industry 1 2 .

\n

When I worked at OkCupid, I was tasked with migrating from a data center full of computers, to Kubernetes in the cloud. Something always felt off about it but I couldn't quite place my finger on it at the time. I didn't get very far, and I don't know where they landed with that stuff, but I would bet you anything it ended up being nothing but a colossal waste of time and money.

\n

Renting is for suckers.

\n

It's Happening Again

\n

Personal computers today are magnificent beasts. You could run one of the top 100 most popular websites from a 5 year old laptop.

\n

And yet, people are using LLMs to code when they have a powerful machine that they actually own sitting there, idle.

\n

Consider where we are now. We own the devices that we use to program. The act of programming uses a trickle of electricity and is effectively free. It's one of the cheapest hobbies you can get into.

\n

Programming has no dependency on the Internet. Maybe you download some documentation, search for some troubleshooting tips, participate in a community, fetch some dependencies. But being offline does not compromise one's ability to code.

\n

It's happening again. We're being told the industry will leave us behind if we don't move programming itself to the cloud.

\n

So let's get this straight by doing some basic math.

\n

My monthly costs as a programmer are $0. I use free software to create free software. I can program on the train, I can program on a plane, I can program when my ISP goes down. I never have to trust any third party with my private information, nor trust them to run arbitrary commands on my computer.

\n

Now I switch to agentic coding.

\n

First of all, the costs are difficult to calculate, and that's part of the problem. Same thing with cloud computing - funny how it's the cloud that does the accounting and tells you how much you owe, isn't it?

\n

In this case it's even more suspicious because the company that bills you not only counts how much you owe them, it also controls the agent's behavior in terms of how many requests it tries to make. So they could easily insert into their system prompt something like, "our earnings this quarter are a little short so try to pick strategies when doing agentic coding that end up earning us more API requests, but keep it subtle." There's no oversight. They could even make it target specific companies.

\n

They could also change the model so that it favors trying to solve problems using their own cloud solutions or pushes their marketing agenda, and it would be basically impossible to detect. I'd be surprised if they weren't already doing this.

\n

Anyway let's try to compare one month of programming 8 hours per day. I'm going to estimate 1 prompt per minute, for a total of 60 * 8 * 30 = 14400 prompts in a given month. Based on Zed's pricing page, that comes out anywhere from $576/month to $2,880/month to $90,000/month depending on which model you use and whether you enable burn mode/max mode.

\n

So on one hand we have $0 per day for a total of $0 per month, programming in total privacy and security, while on the other hand we have to gamble and pay rent, while also trusting OpenAI, Google, Microsoft, Amazon, or Meta - all companies which have already proven their untrustworthiness time and time again. Did you read their Terms of Service Agreement before you clicked "auto-accept all"? How about the email in your spam folder that says "Updated Terms of Service Agreement"?

\n

Don't be a sucker. Use your own computer.

\n

Thanks for reading my blog post.

\n", "date_modified": "2025-07-24T19:04:14+00:00", "date_published": "2025-07-24T19:04:14+00:00", "external_url": "https://andrewkelley.me/post/renting-is-for-suckers.html", "id": "urn:aggr:item:9f36f2433db18adbddc41c4e40234b63285a0362", "language": "en-US", "summary": "Renting is for Suckers A genie offers you a choice: 50% chance to gain 10 million USD 100% chance to gain 1 million USD Which do you pick? Your answer, of course, depends on how much capital you have. If you are struggling to pay rent,…", "tags": [ "programming" ], "title": "Renting is for Suckers", "url": "https://aggr.aymericbeaumet.com/items/andrewkelley-me/2025-07-24-renting-is-for-suckers/" }, { "content_html": "

Someone on IRC shared this link with me: An (almost) catastrophic OpenZFS bug and the humans that made it (and Rust is here too)

\n

They wanted to know, would Zig catch this?

\n

I went through the trouble of porting the code snippet to Zig, so I thought I'd go the next step and turn it into a small blog post.

\n

Original snippet, in C:

\n
/*\n * This code converts an asize into the largest psize that can safely be written\n * to an allocation of that size for this vdev.\n *\n * Note that this function will not take into account the effect of gang\n * headers, which also modify the ASIZE of the DVAs. It is purely a reverse of\n * the psize_to_asize function.\n */\nstatic uint64_t\nvdev_raidz_asize_to_psize(vdev_t *vd, uint64_t asize, uint64_t txg)\n{\n\tvdev_raidz_t *vdrz = vd->vdev_tsd;\n\tuint64_t psize;\n\tuint64_t ashift = vd->vdev_top->vdev_ashift;\n\tuint64_t cols = vdrz->vd_original_width;\n\tuint64_t nparity = vdrz->vd_nparity;\n\n\tcols = vdev_raidz_get_logical_width(vdrz, txg);\n\n\tASSERT0(asize % (1 << ashift));\n\n\tpsize = (asize >> ashift);\n\tpsize -= nparity * DIV_ROUND_UP(psize, cols);\n\tpsize <<= ashift;\n\n\treturn (asize);\n}\n
\n

The blog post author encourages us to try to spot the fail before the answer is revealed.

\n

I couldn't do it before getting bored, so I ported the code to Zig instead:

\n
const std = @import("std");\nconst divCeil = std.math.divCeil;\nconst assert = std.debug.assert;\nconst vdev_t = @import("the_rest_of_the_software.zig").vdev_t;\n\n/// This code converts an asize into the largest psize that can safely be written\n/// to an allocation of that size for this vdev.\n///\n/// Note that this function will not take into account the effect of gang\n/// headers, which also modify the ASIZE of the DVAs. It is purely a reverse of\n/// the psize_to_asize function.\nfn vdev_raidz_asize_to_psize(vd: *vdev_t, asize: u64, txg: u64) u64 {\n    const vdrz = vd.vdev_tsd;\n    const ashift = vd.vdev_top.vdev_ashift;\n    const cols = vdrz.vd_original_width;\n    const nparity = vdrz.vd_nparity;\n\n    const cols = vdrz.get_logical_width(txg);\n\n    assert(asize % (1 << ashift));\n\n    const asize_shifted = (asize >> ashift);\n    const parity_adjusted = asize_shifted - nparity * (divCeil(asize_shifted, cols) catch unreachable);\n    const psize = parity_adjusted << ashift;\n\n    return asize;\n}\n
\n

Let's start with the code formatting tool alone, zig fmt:

\n
andy@bark ~/tmp> zig fmt bug.zig --ast-check\nbug.zig:18:11: error: redeclaration of local constant 'cols'\n    const cols = vdrz.get_logical_width(txg);\n          ^~~~\nbug.zig:15:11: note: previous declaration here\n    const cols = vdrz.vd_original_width;\n          ^~~~\n
\n

Hmm, alright. That's definitely strange. The original blog post didn't notice that the initialization value of cols is dead code. That doesn't look like a logic error though. Let's fix it and try again:

\n
@@ -12,7 +12,6 @@\n fn vdev_raidz_asize_to_psize(vd: *vdev_t, asize: u64, txg: u64) u64 {\n     const vdrz = vd.vdev_tsd;\n     const ashift = vd.vdev_top.vdev_ashift;\n-    const cols = vdrz.vd_original_width;\n     const nparity = vdrz.vd_nparity;\n\n     const cols = vdrz.get_logical_width(txg);\n
\n
andy@bark ~/tmp> zig fmt bug.zig --ast-check\nbug.zig:23:11: error: unused local constant\n    const psize = parity_adjusted << ashift;\n          ^~~~~\n
\n

Bingo. We didn't even have to use the type checker.

\n

Thanks for reading my blog post.

\n", "date_modified": "2025-07-14T18:31:28+00:00", "date_published": "2025-07-14T18:31:28+00:00", "external_url": "https://andrewkelley.me/post/openzfs-bug-ported-zig.html", "id": "urn:aggr:item:5080c170368e636c3644cef0e75cdf5d8a6591f2", "language": "en-US", "summary": "OpenZFS Bug Ported to Zig Someone on IRC shared this link with me: An (almost) catastrophic OpenZFS bug and the humans that made it (and Rust is here too) They wanted to know, would Zig catch this? I went through the trouble of porting the…", "tags": [ "programming" ], "title": "OpenZFS Bug Ported to Zig", "url": "https://aggr.aymericbeaumet.com/items/andrewkelley-me/2025-07-14-openzfs-bug-ported-to-zig/" } ], "language": "en", "title": "Andrew Kelley", "version": "https://jsonfeed.org/version/1.1" }