We need to talk about the Bun Rust rewrite

Stop me if you heard this one before.

Buns being ported from Zigg to Rust with

Claude. Well, it was. And there's a blog

post now. And I think it's fair to say

that this blog post is the end of Zigg

and the respect the community has. You

might be thinking that's cuz this blog

post tears Zigg apart and talks about

how terrible it is. That is not what

we're talking about at all. In fact,

this blog post does a great service both

in sharing the details of how Jared did

this port, but also being super kind to

Zigg and the Zig Foundation.

So, why is this the death of Zigg? You

should ask Andrew Kelly because the blog

post that's going to kill Zigg wasn't

written by Jared or the Bun community.

It was written by Andrew Kelly, the

creator of Zigg itself. He crashed out

so hard at Jared over him making this

move that I ended up crashing out, too.

I am refilming this intro for the third

time because the first time I filmed it,

I hadn't read the article yet. And the

second time I filmed it, I don't think I

accentuated how absurd things were

properly. This whole thing is stupid and

it is absurd just how stupid it is. And

as such, I had to split this video into

two parts. Part one is the smart part

where we go over how Jared did this

insane million plus line port in just a

week because he used the hell out of

Claude and AI tools to make this happen.

And I do genuinely believe there's a lot

we can learn from this. The other half

is me going through Andrew Kelly's post

and being the angriest I think I've ever

been in a video because it is you want

to see what it looks like to kill your

own language, it's this blog post.

Personally, I think the first half is

the better half of this video. But if

you just want to skip to the crash out,

I understand. But I would politely

request that you wait for a quick word

from today's sponsor. I'm going to be

real with y'all. If you're working on

something that other companies have

built before, there's a very good chance

you can vibe code it. Once the code is

in the training data, it's able to be

reproduced a lot, which is why something

as trivial as O should be really easy to

vibe code, right? Well, it is, but it's

hard to get right. And importantly, it

is changing really fast now, more so

than ever. If you want to replicate a

basic Google signin button that every

site uses, cool, fine. But what happens

when you need to onboard enterprises?

What happens when their agents want to

be able to sign up themselves? At that

point, I certainly hope you're using

work OS because these guys understand

what businesses really need. Not just

the libraries, which obviously they have

all of the frameworks, SDKs, and things

that you would expect, but more

importantly, what a business expects you

to have ready for them when you go to

negotiate a contract or trying to sign

up their teams. Or if their agents are

trying to sign up for your service, you

need a way for them to do that, too. And

computer use is great and all, but

filling out forms and dealing with

captures is far from the best use of

GPT56, especially in a world where

agents want to sign up to lots of

different things at the same time, and

you don't want to be rate limited. If

you set up an OMD for your service, then

agents can register on the behalf of

their users, which is a pattern I think

is going to catch on huge in the not too

distant future. And I'm not the only one

who feels this way. Cloudflare,

Firecraw, and more have already

partnered with Work OS to make this

standard real. Make sure your OTH is

user ready, enterprise ready, and agent

ready at soyv.link/workos.

Let's read what Jared has to say. I'm

actually pretty excited about this. I've

only seen parts of the article so far.

So, let's dig in. He opens with the

disclosure that he's now part of

anthropic, yada yada. Bunst started as a

line for port of ESU's JavaScript and

Typicer transpiler from Go to Zigg. He

wrote his first line of Zigg in April of

2021. He bet on Zig after seeing the

single page Zigg language reference on

HackerNews and getting really excited

about the low-level control and care for

performance. From the start, Bun's scope

was massive. There's going to be a JS,

TS, and CSS transpiler, minifier, and

bundler, npm compatible package manager

just like testr runner, node and

typescript compatible module

resolutions, proper HTTP1 and websocket

clients, as well as a Node.js full API

implementation for things like FSN, Net,

TLS, and dozens of other built-in

modules. The initial version of Bun was

written by Jared in one year in a

cramped Oakland apartment pre-LM in

Zigg. Fun fact about this, I had Jared

come over to my current apartment when I

first moved here so we could hang out.

And he was surprised by how close it was

to the bun office. And we had a

conversation about that and he realized,

oh, I didn't realize I could just like

live closer to the office. This seems

really nice. I should probably stop

living in my cramped Oakland apartment

after raising a bunch of money. and I

yelled at him about it and convinced him

to move here where he lives in a much

nicer spot. Back in like 2023, I want to

say he stayed in that apartment way

longer than he should have. Silly aside,

but like I have known this kid for a

while. He just kind of sits and does the

thing until somebody taps him on the

shoulder and says, "Hey, this other

thing next to it also matters." And his

apartment is one of the silliest

examples. Back to the article. The

default outcome for ambitiously scoped

projects like Bun is joining the

graveyard of dead side projects on a

GitHub profile page. Don't call me out

like that. Zigg made bun possible. I

would never have been able to build this

much in one year if it wasn't for Zigg.

Nowadays, the Bun CLI gets over 22

million monthly downloads. Popular tools

like Claude Code and Open Code bet on

Bun as their runtime. Open Code is

moving to Node for what it's worth.

Verscell, Railway, Digital Ocean, and

more all have firstparty support for

Bun. Bun Scope's also been a challenge

for stability. Here's a small sample of

bugs that they had to fix in the most

recent release. A bunch of weird

crashes, memory leaks, and out of

bounds. We could have kept fixing these

kinds of bugs one-off in perpetuity, but

we owe it to our users counting on us to

do better than that and systematically

preventing these kinds of bugs from

recurring. So, what did they start

doing? They patched the Zig compiler to

add address sanitizer support. They ran

their test suite with an address

sanitizer checks on every commit. They

shipped the Zig safety checked release

safe builds on Windows. They fuzz buns

runtime APIs 24/7 using fuzzy, which is

a JS engine fuzzer used by the V8 and JS

core teams. and they have a whole bunch

of endto-end memory leak tests. Most

projects don't go this far. He says it's

more than most do and I totally agree.

So why don't you just be really smart

and not make mistakes? Our bug fix list

felt bad and I was tired of going to

sleep worrying about crashes in bun. I

don't blame Zigg for that. Other users

of Zig don't have the bugs that he has

in mixing GC with manually managed

memory is an uncommon enough thing for

software to need that no language really

designs for it. We wouldn't have gotten

this far if not for Zigg and I'll always

be grateful. Until very recently,

programming language choice was a

one-way decision for a project like Bun.

Notice all of the nice things he's

saying about Zigg. Remember that for the

next thing we read, JS is a garbage

collected language, and a modern JS

engine like JSC or V8 have strict rules

around exception handling and the

garbage collector. Zigg like C doesn't

memory manage for you. And this is a

trade-off that for many projects is a

great reason to use Zigg. Z does not

have constructors and destructors and

most cleanup is expected to be written

out explicitly at each call site with a

deferrun correctly handling the

lifetimes of garbage collected values

and manually managed values has been a

major source of stability issues most

often small memory leaks and

occasionally crashes. Every memory

allocation has to be meticulously

reviewed. Where do these bytes get

freed? How do we ensure it only gets

freed once? Do we check for JS

exceptions properly? Is the garbage

collected pointer visible to the

conservative stack scanner? Is this

garbage collected memory or manually

managed memory? Versibility issues.

Knowing as early as possible is best.

Buzzing happens after code is merged. CI

happens when code is pushed. Runtime

safety checks in address sanitizers

happen when code is run, hopefully in

development before you get to CI. One

common way to reduce this class of

issues is to ensure cleanup code is

always run exactly once for the code

that needs it. Zigg's designed to be a

simple language with no hidden control

flows. So it prefers explicit defer

keyword to run code at the end of a

scope over C++'s implicit destructor or

Russ implicit drop for zig code. When

exactly should we be running this

cleanup though? If we're passing the

same pointer to many different

functions, how do we know when it's no

longer accessible and can be cleaned up?

How does it work when some functions

need to continue to reference the memory

after the functions called? Our current

approach is a mix of lifetimes,

reference counting, and paying really

close attention. This is a a scary one.

Many projects opt to answer these

questions through style guides. Tiger

Beetle's Tiger Style is an example in

Zigg and Google's 31,000word C++ style

guide is another. The challenge with

style guides is enforcement. How do you

make sure that the style guide is

followed? Historically, code reviews

were the answer with best effort

enforcements via llinters and static

analyzers. Having a rigid style guide

with clear ownership expectations

explicitly spelled out the type system

was a real option for Bun. Since Zig had

no operator overloading, we would likely

end up with a lot of code looking like

this. Just a ton of types all over the

place. Normally with Zigg, you write

much simpler, more elegant code, and you

don't have to manually dreference and

defer all over the place. And a lot of

why people like Zigg is this crazy

flexibility and simplicity they get out

of it that goes away if you have to

triple check every single thing you do.

About 20% of their code is written in

C++. So why not consider that? Things

like the JavaScript core which is the

engine that powers both Safari and Bun.

U Web Sockets and Usockets are both

phenomenal libraries which they use for

HTTP and the websocket server. IshPac

and isquick which are built on top of

C++ as well. Boring SSL, Google's open

SSL fork and SQLite. C++ instead of ZIG

would be a reasonable choice for bun. We

would get constructors and destructors.

We could delete lots of external C

wrapper code, but we would still be

reliant on style guides and forced

through code review. And even with ASIN,

memory corruption and memory leaks would

still happen. So why Rust? And I will

tell you as a friend of Jared, Rust is

far from his favorite language. He made

this as the right choice, not his

preferred choice. A lot of the bugs he

was talking about before are from use

after free, double freeze, and forget to

freeze in error paths. In safe rust,

these are compiler errors and they are

guarded with cleanups and drop. Compiler

errors are better feedback loops than

style guides. I absolutely agree. And

now that we have agents writing our

code, getting that feedback early

through a compiler is really useful.

Historically, rewrites are a terrible

idea. Yes, everything he is saying is so

agreeable here, I'm amazed anyone could

be mad as they read this article.

Excluding comments, bun is 500,000 lines

of Zigg. A rewrite in another language

would take a small team of engineers a

full year. It would mean freezing bug

fixes, security fixes, or feature

development for that time. The least

risky approach to getting something

shippable would be a mechanical port

from Zigg to Rust with a minimal number

of behavioral changes using the exact

same test suite we already use for

testing Bun. Fortunately, Bun's test

suite's already written in Typescript,

which means it doesn't depend on the

runtime's programming language. A year

of no userfacing impact is not a

realistic option they could consider.

So, enforcement through code style to

fix stability issues was their best bet,

and it was their plan when they added

the Rust inspired smart pointers to

Bun's codebase. But honestly, Jared

didn't want to do it. Homegrown smart

pointers offer worse ergonomics than

Rust and have none of the guarantees.

What if instead he spent a week testing

if Anthropic's new model could rewrite

bun in Rust? He didn't expect it to

work. A few days in, a high percentage

of the test suite started passing and he

saw how much the new Rust code matched

up with the original Zig codebase. His

opinion went from this is worth trying

to I'm going to merge this. I watched

this happen real time. I was in a group

chat with him. I did not think he would

bite the bullet and he did. Claude,

rewrite bun and rust. There's a lot of

ways to do a terrible job of this. For

example, prompting Claude to just

rewrite it. Don't make mistakes.

Definitely not what I did with

Typescript Go and Rust video probably

out by the time you're seeing this. and

then praying it would work is not what

he did. Think about how a person would

do this. The first big question is

incremental rewrite or everything at

once. Since he's already done ports like

this, like ES build from Go to Zigg, he

knew that everything all at once was

better. An incremental rewrite adds

temporary code that you hope gets

deleted eventually. It'll be painful in

the short and medium term and probably

never get deleted if I'm being real. The

second big question is how how do we

keep bun and rust the same bun as before

with the same architecture performance

and feature set while also getting the

language features of rust like the

borrow checker. How do we ensure the

team can still maintain it after the

rewrite? Their plan was to do the

rewrite that makes it look like they

transpiled the zig code to rust. They

can gradually refactor it to reduce

unsafe usage and look more like

idiomatic rust after the 1.4 release

ships. There's only two big questions

left. Loops that write and review code.

A lot of day-to-day engineering work as

software engineers can be oversimplified

into a loop. You task and while there is

stuff on the to-do list, you get a

result from calling the task. Then you

wait for feedback. promise.all review

result review result. Then you apply the

feedback to the result. Then you do it

again and again and again forever. A

task has some context associated with it

like a Jira ticket, a GitHub issue, etc.

The result is the code you wrote to fix

it. Code reviewers review the changes to

check for regressions and correctness

and then you address the feedback. He

rewrote bun and rust using about 50

dynamic workflows in cloud code. All run

continuously over the course of 11 days.

Each dynamic workflow was a loop like

this. A workflow for generating a

porting guide mapping zig patterns and

types to rust patterns and types.

Mechanically porting everyzig file to a

rs file matching the porting.mmd and

lifetimes.tsv files. Fixing every crates

compile errors. Get subcomands like bun

test and bun build to work. Get every

test and bun's entire suite to pass. And

several large refactors and cleanup

passes. These are the things that make

the dynamic workflows in cloud code so

powerful. If you haven't seen my video

called the good things about cloud code,

watch it cuz I go in depth on workflows

and how cool they are there. For most of

those 11 days, as well as afterwards, he

monitored the workflows, manually

reading the outputs to check for issues

and bugs and prompting Claude to edit

the loop to fix things. How do you

review a PR with 1 million lines added?

How do you start to build the confidence

needed to responsibly merge large

quantities of LLM authored code? You do

it with a language independent test

suite with a million assertions,

adversarial code review, and then when

something goes wrong, you fix the

process that generates the code instead

of just handfixing the code itself. They

did a bunch of adversarial review as

well, always splitting the context

windows because you don't want to have

the knowledge of how it was built in

your brain. You just want to check it.

This is another one of the things that

dynamic workflows do well is you can cut

off that context window and set up

something else with a different one to

go explore by itself. Super powerful

tactic. So you'd have one implement and

then two or more adversarial reviewers

per implement. The reviewer's only job

was to find bugs and reasons why the

code doesn't work. The implement doesn't

review. The reviewer doesn't implement.

Yep, I do this a lot, too. The one thing

he doesn't have which makes it even more

impressive that this worked is I get

much better reviews when I have

different reviewers using different

language models and families of models

from different labs. So having one

reviewer on codeex and one on claude

meaningfully increases the quality of

the responses. You had to do something

big and expensive. It saves a lot of

time and money to derisk it first. And

then he discusses how he prepped. He

started by talking for 3 hours with

Claude about how to map the patterns

from the Zig code base closely to Rust.

Claude serialized the discussion into

the porting MD document which somehow

ended up on hacker news. After fighting

GitHub for 15 minutes, I found the

document, the ZGS porting guide. It has

the ground rules for how it wants to

structure the files, not inventing crate

layouts. Instead, use the ones that they

already set up. Don't use all of these

different packages because bun owns his

event loop ancest calls. No async, yada

yada, and the map to all the different

crates, all the allocators, all this

type of like how to map things. If

anybody saw this port and assumed it was

just like a blind go port, make no

mistakes, I would implore they read this

and see how much time and thought Jared

put into doing this port. I know I

hadn't done that before making my first

video and now I feel a little bad about

it because this is a great document with

a lot of useful context on how hard he

worked to do this right. He did a bunch

of adversarial reviews on these guide

files and as he says also manually read

over them. I love this be called out but

it's important. They did a trial run

before asking Claude to translate all

1448.zig files to RS files. He started

with just three. For each of the three

files, one implement wrote the new Rust

file. Two reviewed the changes and made

sure the behavior in the file matched

and then it followed the porting MD and

lifetimes MD files. And then one fixer

applied the suggestions. He wanted to

make sure he did this right. So he

started with just a handful of files. I

believe three he said here. And he

noticed that all of the claude instances

were stepping on each other. And if you

put each Claude in a separate work tree,

he would run out of disk space because

Bun's git repo is too big. So instead,

he asked Claude to edit the workflow and

instruct Claude to never run git stash

or get reset or any git command that

doesn't commit a specific file at once.

No cargo either, no slow commands at

all. Jar and I had a long talk about

this bit. I think the future is your

tool calls executing on another machine

so they don't step on each other. He

thinks you need to prompt around it and

he prompted around it here. I think this

idea of agents stepping on each other is

going to be one of the next arcs we go

through in the like agentic coding

world. How do we solve this problem? And

I would guess the different labs will

solve it entirely differently. And now

after all of that and breaking up the

workflows more, it finally started to

really write the code. At peak, Claude

was writing 1300 lines of code per

minute. Get on this level, Gary Tan.

You're not even close. Is this the first

real 100x engineer? It's insane, but it

worked.

11 days and 652 commits. Notice the egos

assistant timing. He forgot to increase

the default IOPS on the EC2 instance

that this was running on. So one slow GP

command was all it took to freeze disc

reads and writes for minutes. Yep, I've

even had that problem. And then he

treated the compiler errors as a work

cue. Another very interesting strategy.

When crate by crate, the trickiest class

was the cyclical dependencies because it

just Rust does not like that type of

thing. Also, Rust compiles really

slowly. So instead of having just one

crate or package like he did with Zig,

he wanted to split the code base into a

100 separate crates so the Rust code

could compile faster, but it needed to

avoid cyclical dependencies while

minimizing changes compared to the Zig

code. His PR to do this immediately

before starting the Rust rewrite was

insufficient. Instead of starting over,

he wrote another workflow to classify

where the code with cyclical

dependencies should go and write it all

down. Then another workflow to actually

do that work. This is the loop

engineering [ __ ] It sounds insane,

but when you find the problems and they

are at this scale, setting up a system

to allow the agents to prevent it or fix

it is a new type of engineering. And

it's cool to see it in practice and

written up as well as this is. There is

no piece of like media out there that

does this good of a job of explaining

something this chaotic and new. And it's

a weird artifact. Like I bet this blog

post will be referenced in five years

for very interesting reasons as the

start of this shift. It's super cool and

I get why he took so much time to

rewrite it.

Rewrite is not the right word. Writing

this blog post. I'm sure he didn't

rewrite this a bunch. And I know he

didn't have Claude write a lot of it.

This is a great Claudism here, too. I've

had Claude write longass comments

justifying things that it thinks are

okay. And he told it specifically, if

you need a paragraph long comment to

justify why the workound's okay, the

code is wrong. Fix the code. I like this

a lot. I'm going to steal this.

Specifically, he had to do this cuz

Claude was interpreting let's get all

the CR to compile as stub out the

functions with compilation errors.

Claude also started adding suspiciously

long explanatory comments to document

workarounds. So he added that rule

specifically for that. And then the

smoke tests models love saying smoke

tests. Once cargo check passed, getting

it to compile and run was next. It had

linker errors and then it panicked

immediately on start. So then you had to

get it to run the bun test like helper.

Once that worked, they could start

actually running the tests. He had a new

loop for that. It kept going. A lot of

the tests had memory leaks which is

crazy because Rust but again line for

line it's using a lot of uh unsafe not

going to have the benefits immediately.

He also noticed that the tests were

exhausting the maximum number of TCP

sockets on the machine. Tests were

reading and writing gigabytes of stuff

to disk and tests were spawning 10,000

plus processes. I had this problem too

with a big port I was working I hinted

at it earlier. I was working on porting

Go to Rust inspired by what he did here

and I had the processes spin up and fail

and memory leak and crash the machine so

many times that I had to build a lot

around that too. As he said, he needed

something stronger than please. So we

used systemd run with croups to limit

memory and CPU usage and isolate PIDs by

their namespace. The machine ran out of

disk space and crashed several times

regardless. Yep. And then they got the

test suite passing in CI. 2 days after

the first run, the failing list was down

from 972 test files to 23. A day and a

half after that, Linux went fully green,

and for the first time, it felt like

this Rust rewrite was actually going to

work. That is insane. Just crazy. The

rest of the time leading up to merging,

it was straightforward. A workflow that

looped on fixing CI test failures for

each platform until there were no more

test failures. Several workflows for

Windows related cleanup to ddup code, to

reduce unsafe usage, and to generally

clean up some stuff. Then he merged it.

Once 100% of the test suite passed in CI

on all platforms and he manually

verified the tests were actually running

and not being skipped. He ran a bunch of

commands locally to test things. Then he

pressed merge. Merging into main isn't a

versioned release. This is another big

thing that I've been emphasizing. Maine

shouldn't be prod anymore because

merging is too useful to have it also be

deploy. I have an action that you can

manually trigger in my projects that

will take what's on main and move it to

a prod branch and then trigger a deploy

manually rather than having main

autodeploy because then I can more

freely merge to main if things break on

staging or when I manually build the

package revert change etc. So the merge

to main wasn't a release it was

confidence to start really making sure

this could happen. This ended up being

over 6,500 commits and 1.78 million

lines written or rewritten. As I hinted

at at the start, this was an insane

number of tokens premerge. 5.9 billion

uncashed inputs, 690 million inputs, and

72 billion cached input reads, which

would have been 165,000 if you paid API

price. Crazy to have this number public.

And I know it seems insane because it

is, but there's a few things we need to

recall. First, if this was done by

humans, it would have been three

engineers over a year. And that year

isn't just, oh, you lost three engineers

for that time. It's all other

development has to kind of be paused or

mirrored, which makes it either more

expensive or unrealistic. Instead, it

happened in just a few days. So if you

assume all three engines made 200k a

year and it would have taken three

years, this is still cheaper because

it's 165k in a week of edge time instead

of 200k * 3 in a year of time. But

there's two other layers I want to dig

into here because the first and arguably

most important is that this just

wouldn't have happened. If this would

have taken a year, they wouldn't do it

because there's too much other [ __ ] to

do. as a shortterm experiment, it is

absolutely worth it just to to know if

it can happen and then if it does to go

further with it. So this isn't like 600k

versus 165. This is it didn't happen

versus 165k. But the other layer I want

to call out is that this is $165,000

right now. This is the most expensive

it'll ever be. This level of

intelligence is already accessible via

cheaper models because 56 soul just

dropped and it's way cheaper. And over

time, Anthropic and other labs will

release models that are this smart or

smarter for this price or lower. So, the

prices are going to keep getting better.

And when you factor in the margins that

Anthropic already spikes into their

product, between 50 and 80% from recent

rumors, this number is really not that

big in practice. So, yeah, 165K, big

scary number to have on the front. It's

going to get cheaper from here. It

wouldn't have existed otherwise. and it

was subsidized to all hell by the fact

that it was anthropic and this yeah this

just wouldn't have happened otherwise.

So people who think this number means

this that AI engineering is doomed or

whatever be [ __ ] realistic. The idea

that you can spend under 200k to port a

project as big and important as bun to

an entirely different language is a

thing that wouldn't have even been

fathomable 6 months ago. It is

unbelievable how fast the stuff is

moving. The most wrong I've ever been is

when I said we hit a ceiling. We are

blasting through any ceilings I thought

were there faster than I could have

imagined. And we're already getting dumb

comments. How can we say prices get

better? If anything like this continues,

it will get more expensive. No. Again,

use your brain. When new models come

out, they are either the same price or

more expensive because they are smarter.

At any given intelligence level, at any

given capability level, the price drops

constantly. So again, could a smarter

model come out that would be more

expensive for this? Perhaps, but you

don't need a smarter model. Fable 5 was

able to do it at this price. So as new

models come out that are just as smart

and cheaper, you can still do this for a

cheaper price. Will there be a new

smarter model you want to use for bigger

things? Perhaps. Will that model be more

expensive? Probably. But again, that

doesn't mean that what we're doing today

gets more expensive later. If you have a

task you can do today with an LLM and

then the same task with the same output

quality next year, on average that gets

five times cheaper year-over-year. So

yeah, I I've seen so much dumb

commentary around this number that it's

almost enough for me to crash out on

just that. But the dumb things that the

Zigg guy said are stupider. So we're

going to go there right after. I like

how he describes all of this as well. So

I'll read a bit more of what he said. If

he had three engineers working on this

for a year, they wouldn't have been able

to improve node compatibility, fix bugs,

fix security issues, or implement new

features, they never would have been

able to sacrifice that. The realistic

alternative was to do nothing and just

keep fixing bugs at the top of this post

forever. This is the bleeding edge of

what's possible today. Jared used a

pre-release version of Claude Fable 5, a

mythos class model. He also used Cloud

Code's new dynamic workflows, which

would keep 64 Clouds running for 11

days. He would have had to handwrite his

own harness to pull this off otherwise.

[ __ ] didn't have to. This is why it's

one of the things I've been so positive

about quad code for. It's a really cool

thing. Since merging the Rustport,

they've done 11 rounds of security

review with the Claude Code Security,

which is the white labeled whitelisted

special Claude code that can do security

stuff, probably using Methos. They've

had a 24/7 coverage guided fuzzing on

every parser in bun. Only 4% of the code

is sitting inside of unsafe blocks. I

called them out for the unsafe thing

before, but the important piece is that

78% of the blocks are literally just one

line, usually a pointer that came from

C++ or a call into a C library. The

number should go down over time as they

refactor from a faithful Zigg port over

to idiomatic Rust, but they're going to

have to keep using the C and C++

libraries like JSC. So, there will

always have to be unsafes, unlike pure

Rust apps. The rewrite only introduced

19 regressions, which is crazy. He says

he doesn't say only here, but I will.

And most of the regressions came from

code that's syntactically identical in

both languages but semantically

different. He has some cool examples

here. Link in the description if you

want to see all of these syntax things.

But we're a vibe coding channel now. We

don't read syntax. Joking, but I want to

get into the other fun details here.

Specifically, the improvements. He fixed

128 bugs that are still reproducible in

the latest non Rust version back in

1314, which is the last Zigg one. They

reduced memory usage meaningfully

because of the cleaned up uh memory

utilization. They fixed every

instrumentable memory leak, which is

kind of crazy. In bun 1314, this build

process would slowly leak. So when you

ran up to 2,000 builds, it would have

almost 7 gigs of memory leaked. And now

it it leaks a little bit, but way way

less aggressively. It would only have

600 megs, a tenth as much RAM being

used. The binary is a bit smaller, too,

which is cool. Now it's 20% smaller on

Linux and Windows as a result of other

changes they made. It's two to 5% faster

which is pretty cool and it's already

been launched in production by plenty of

things including cloud code. Prisma

using it with Prisma compute and I

believe those are the only two examples

they have here but more coming very

soon. The team says it feels similar to

the zig codebase. They show syntax

examples so it hasn't been that bad for

them. Awesome. With one engineer using

fable and closely monitoring cloud code

we went from a start to 100% of the test

suite passing on all platforms in 11

days. One engineer can do a lot more

today than they could a year ago. I

absolutely agree. This is an awesome

write out up. Shout out to Jared. I am

sure nobody has anything stupid or rude

to say about this. How could you

possibly be dumb about something this

well written? This is going to be fun. I

have heard mixed things about Andrew

Kelly and I don't like calling out

individuals. When you call out my

friends, I'm going to read what you have

to say and if I have to do it publicly,

I will. So, here are Andrew Kelly's

thoughts on the bun rust rewrite.

remember creator of Zigg, he has

opinions. Let's see what he has to say.

Bun was almost inarguably the biggest

Zigg project and also a pretty heavy

contributor to Zigg both financially and

code-wise. And they've had a bit of a

rift. I personally know Jared put a lot

of work into trying to form a proper

Zigg community in SF and even like

hosting events and things. So, let's

read what he has to say. I'm already

getting mad just skimming. When Jared

joined the Zig community about 5 years

ago, I described him as someone who had

strong beginner energy. Referring to

Jared Sumar, one of the best engineers

I've ever known, as a beginner or having

beginner energy in your first sentence

sets up for quite a read, Andrew,

excited for you to call me a JavaScript

soy boy that has no idea what he's doing

after I give my thoughts. Back to the

article. 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. This is

such a pathetic attempt to look nice as

you belittle. We'll see where this goes.

You know, I would think that the

low-level engineering guy would want to

talk about the engineering and not this.

He's trying to make Jared sound like he

just learned how to code, not like a

very experienced engineer that we all

look up to. As Jared focuses efforts on

Bun, he began to attract attention. JS

being the most popular programming

language in the world, there are a lot

of potential eyeballs on a promising new

tool chain. The 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. You guys have any good

examples of popular things that are

crowdfunded? Because I have a few.

Here's E18E, a very beloved thing in the

JavaScript ecosystem. It's the ecosystem

performance group. These guys look

through all of the packages we use and

find dead or undermaintained

dependencies in our tool chain. They are

so goddamn important and I have poured

quite a bit of money into supporting

them because again they need to be

successful. They need to do well. For

reference, they have raised a total of

$20,000.

$20,000

total from sponsorships, crowdfunding,

and individuals donating, including

individuals like the Chrome team

donating 10 grand and myself donating

five. And this is one of the most

important things in the JS ecosystem. 20

grand. I'm sure that's enough to fund

the SF standards. [ __ ] delusional.

Absolutely delusional. This is somebody

who doesn't understand how little money

there is in donating to open source

[ __ ] And now we get to where this

starts being very dirty. Having

graduated from the Teal 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. I wonder if

somebody has a bone to pick. I can say

pretty confidently that everyone who is

currently betting on Zigg should

reconsider because the guy who makes

your language might crash the [ __ ] out

at you for no good reason. From the

beginning, Jared was appreciative

towards the Zigg project. He credited

Zigg on the Bun website for the

project's performance achievements. He

sent monthly donations to the Zig

software foundation that amounted to 60

grand per year. Remember that thing I

said about donations just a minute ago?

The total budget for E18E, by the way,

link in the description. You should

donate to these guys. They're really

important. Was a third of how much Bun

was donating just to Zigg. So, the Zigg

Foundation was getting three times more

money than one of the most important

JavaScript foundations I can think of

because he raised VC money to use for

things like hiring engineers and

donating to the language foundation.

According to our friend Andrew, he

didn't have to do either of those

things, but he chose to, and it was

pretty cool of him. Even in his blog

post that's being referenced here about

the rewrite, he expresses what is

perceived to be sincere gratitude

towards the Zigg project. It is sincere.

However, once Bun became a VC backed

startup, he started racing towards the

finish line. This is so obvious that you

do not know Jared at all or you're

willfully trying to misrepresent him

that it's crazy. Jared's whole thing

from day zero, from when I first met

him, was pushing to 11, going way harder

and way further than any human should,

contributing on GitHub so much that the

one day he didn't have any commits was

suspicious, got called out by Dax, and

turned out to be the day he was

discussing the acquisition. This is a

person who doesn't know how to not race.

He's either not moving, which means he's

asleep, or he is going to like

unbelievable speeds to get wherever he

is trying to. Trying to accuse him of

doing this cuz he's VCbacked instead of

him just being like this means you don't

know jack [ __ ] [ __ ] about Jared and

you better shut your goddamn mouth. Now,

instead of working on free and open-

source projects, learning and growing

with the community, Jared was running a

business. No, this is just how he does

things. Remember earlier when you said

that he moves fast and tries a lot of

different stuff, jumping head first into

problems? Seems like you know this trait

of his and instead of acknowledging this

trait of his, you're trying to

dishonestly represent him as other

because he was successful and raised

money. You're mad at him for doing what

it took to be successful in the space

because he will do whatever it takes to

make his [ __ ] happen because that's how

Jared is. It was at the point where he

suddenly became a manager that the

beginner energy started to hit

differently. It's one thing to choose a

poor work life balance, a different

thing entirely to demand it of others.

This is him [ __ ] on the Jared post

where he said that like working at Bun

isn't going to be a nice 40hour work

week with long vacations that he was

grinding and he wanted others that would

grind with him. And here I'll say a few

things. First and foremost, as much as I

love Jared, he isn't a great manager. I

talked to a lot of his team and we would

have to find ways to convince Jared of

important things that varied wildly in

our implementation methods. I have had

videos I put out about Bun that weren't

really because I wanted to do a video on

Bun. They were attempts to help the team

leverage important points against Jared

so the business would be more successful

and Bun would be more likely to win.

Sometimes you have to engineer a person

like Jared into the right box to do the

right thing. And that's just how it is.

I know I am this way too. I know my team

has a weekly meeting where they all talk

without me on how they can sigh up me

into doing the things I'm supposed to

do. That's just reality. Another part of

this reality is that Jared is really

hard to work with if you take a lot of

breaks. You could take a weekend off and

when you come back the project's been

rewritten in Rust. Like that's just how

he is. And if you're not trying to work

at that level, you shouldn't. And rather

than pretend or build a workplace he

doesn't want to work in, he just said

upfront what it's like. And if you think

this is a unique to bun thing that a

team formed by a person who works 80 to

90 hours a week wants people who work at

least 50 hours a week. If you think that

is crazy, there are much crazier things

I would have to show you in the city,

including but not limited to someone

coming for a oneweek trial, staying at

the office, and then not being allowed

to leave at risk of losing their dream

job for 6 months to a year living in the

office on an air mattress. I had other

examples, but honestly, I think I'm just

going to leave it at that because I

don't want to get in too much trouble.

And the amount of these types of things

I know of is insane. Jared was one of

the better people to work for. His

employees all love him, even when they

are frustrated with him and his

admittedly narrowfocused lockin mindset.

But the godamn guy was transparent about

this, and I don't think it's fair to

fault him for it. You even quoted him

here, and I don't think this quote's

that bad, especially in retrospect.

oven, which is the company that makes

bun, is going to be a grind, especially

the first nine months or so. If work

life balance means a lot of time spent

not working, this probably isn't a good

fit. Entirely realistic. Fun fact,

people talk to each other. You're right

about that, Andrew. And some of those

people have an audience like I do. And

now they're all going to talk about you

and how much of a [ __ ] you are. He

talked to those who interviewed for a

job at Oven. He talked to people who

worked there. Those people talked to

each other. Everybody talked to

everybody. The grape vine was large and

healthy and full of juicy grapes. And

all of those grapes contained the juice

of the same message. Jared was a stinky

manager. Poor communication, unrealistic

expectations, low empathy, no

experience. Just a total shitow from an

employment perspective. If you think

that is a total shitow, you have never

had a manager, much less a bad one.

Jared was far from a great manager. I

have said as much. I have told him as

much. I have said as much here. But you

don't join Jared's team expecting a

great manager. You join Jared's team

expecting a highly motivated, incredibly

talented person that is next to you as

you do crazy [ __ ] and get pushed harder

and harder. It's also worth noting very

few people left Oven at any point other

than the acquisition, which inherently

came with like a slight trim. That is

how it is. All the people who didn't

make it over with that got really really

generous severance. Consequently,

although Zigg community members were

eager to find work coding in Zigg on the

clock, most of the talent pool steered

clear of Oven and Bun. Huh. I wonder if

that's because Jared is a really bad

manager, as you say. Or perhaps the

people who you think of as the Zigg

community are the people that you

haven't scared off who are all [ __ ]

like yourself. Sorry for getting so

heated about this, but this is the worst

thing I've read in a long ass time.

Apparently, a rift between Zigg and

Jared started to widen. His singular

focus on productivity and his startup's

exit strategy was increasingly at odds

with his long-term vision for the Zigg

project. He wasn't looking for an exit

strategy, [ __ ] He was trying to

make Bun production ready. I'm sorry

that not everybody is making their

language to toy around and write [ __ ]

posts online for. And some people made

the mistake of trying to use your

language for the real [ __ ] world.

Lesson learned. If anyone's building

anything real, they probably shouldn't

use Zigg because if you ever want your

thing to be used in businesses by real

people, you're just trying to find an

exit strategy. Jesus [ __ ] Christ. I

remember he kept nagging me to drop my

other priorities and work on a language

server protocol implementation and a VS

Code integration while I had bigger

plans. What were your bigger plans that

are more important than your language

working and providing feedback? Are you

joking? This dude's never worked before.

Yep. I cannot imagine this guy's ever

had a real job. This is the most

embarrassing thing I've ever seen.

Notice how he hasn't said a single

technical thing yet. Not one.

Apparently, we're finally about to.

After all of that, we're going to start

talking about code quality. The Zigg

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. We became

increasingly horrified at the

programming practices we saw in the bun

code bases. Hacks on top of hacks. Abuse

of assertions. This is an article he

linked from another dev about how

asserts are bad. This is one of those

like personal back and forth. I know

some really smart engineers that think

asserts are awesome. We should use them

for everything. If I recall, Primagen

leans that direction. He really likes

asserts than other engineers who

absolutely hate them. But if you're

citing that as abuse when it's clearly a

difference in opinion, [ __ ] yourself.

Most of all, recklessly speeding past

feature after feature with very little

time taken for reflection and

elimination of bugs and technical debt.

Jared was already writing slop well

before he had access to LLMs.

Cheers, Jared. Makes the two of us. 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. We made futile attempts to

guide them towards better programming

practices. There were a few exceptional

heroes who did their very best at a

dysfunctional company. You know who you

are, but you can't stop a rising tide.

By this time, we all felt at the Zig

Foundation that Bun was a net liability,

and this was before Robo Bun became the

number one contributor. Robo Bun is the

bot that Jared made using Claude. This

is just a hate piece. Along with the

discomfort of the publicly presumed

poster child for Zig's programming

language, actually being the prime

example of how not to write Zigg code,

at some point they would sell out. Let's

be honest, the vague sell some cloud

something business plan was a farce from

the get-go. No, it wasn't. they just

needed to figure out how to do it. We

would receive some negative publicity by

proxy and we'd stop getting that regular

donation. So when the anthropic

acquisition finally happened, we at the

Zigg Foundation breathed the sigh of

relief. When the donation silently

stopped, our bank account was ready for

it. Probably because you somehow conned

[ __ ] Mitchell to donating $400,000 to

your [ __ ] foundation. I hope he

reconsiders in the future. The rewriting

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 and bun being written in Zigg

caused not only a surge of driveby slop

contributions, but also an influx of

tasteless AI enthusiasts into the Zigg

communities who had to be informed that

its antisocial to paste LLM outputs into

forum posts. For a moment, I feared

Zigg's identity would become known

colloquially as a programming language

associated with AI. This is a guy that

hates having users. He wants to run

around in circles with nobody touching

his [ __ ] and gets mad at you for using

them. This is the end of the [ __ ]

language. I've never seen anything like

this in my life. When Jared 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. 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. Seems like

you're a little salty, [ __ ] The

blog post is expertly written. It's

almost like the marketing department of

a trillion dollar company has a lot of

money writing on it. No, Jared is just a

slow writer and he put a lot of time

into writing it. He has some bones to

pick. What a surprise. The the king of

picking bones has a bone to pick. It'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 slight of hand

misdirects the reader away from the main

way bugs are eliminated by dedicating

engineering resources to it. Yeah, I'm

sure for you going from three unpaid

volunteers to four is not a big deal.

But for a realworld project, which I'm

sure you're not super familiar with,

things are a little different, Andrew.

You're going to be belittling I will

too. You sound like somebody who's never

worked on a team for longer than a week

because they can't stand working with

you. And when you get [ __ ] fired, the

response you have is, "Well, they just

didn't see my genius." [ __ ] insane. I

hate that you and I are both on the same

side with the Codeberg things. I love

Codeberg, and I really hope they don't

get stuck dealing with your [ __ ] Quite

simply, Tiger Beetle put in the time to

find and eliminate bugs. They made an

effort to maintain a healthy

relationship with the Zig Foundation,

and Bun did neither of those things. Are

we talking about the same blog post?

talking about the same bun, the one that

donated a bunch of money to you that

glazed the [ __ ] out of you at the top of

the article and also showed all the bugs

they are currently fixing. Jared has

personally fixed more bugs in any given

year than you have in your goddamn life.

The argument for shipping all the

million lines of unreed 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

codebase? Okay, I have a lesson for you,

Andrew. It is lesson time. We get to

learn together. There are many types of

bugs. I know this is crazy to you

because you only think of two bugs. You

think of bugs in software and your

users, which to you are also insects.

But to the rest of the world, there's

lots of different ways software can

break. Sometimes it breaks in a way that

is verifiable via a test. Other times it

breaks in ways that are harder to

verify, like in a longunning process,

the memory leaks, which you wouldn't

understand because you're not using your

code to do anything [ __ ] real at all.

Meanwhile, we have real production

servers running Bun for months at a time

that actually get hurt by these memory

leaks. You seem to think if a team only

hires extraordinary engineers, which you

claim you have a monopoly of with your

community, insane problem for you, but

for the rest of the world, I guess we

just can't hire these great of

engineers. Hm. Wouldn't it be cool if

there were tools that could catch some

of these other types of bugs? like a I

don't know maybe a compiler with a

server protocol that would communicate

to the person or the tool you're writing

the code with that maybe there's a bug

here or crazy just just hear me out.

What if there was a way to check what

memory was being used and what was using

it? Like when a function borrows the

memory and puts it somewhere else and

does something. What if we could check

that? You know, like a a borrow checker.

I know that tests are great, but maybe

there are some things that a traditional

unit test can't quite find. Oh, what's

that on my screen? A language empowering

everyone to build reliable and efficient

software. Oh, it has a type system and

an ownership model that guarantees

memory safety and thread safety. The

problems that you can't really unit test

for, as you seem to think you can, you

[ __ ] imbecile. How am I, the

JavaScript soy boy, more qualified than

you at very basic testing practices for

low-level languages? I know why. Because

I'm not here to complain about somebody

I'm mad about. I'm here trying to

educate my audience on software

development. You [ __ ] imbecile. You

child. Do you see how many people just

dropped bangers in my chat as I went on

this rant? Cuz you're so [ __ ] God. I I

knew this was going to be bad. I did not

expect he was going to say that the unit

tests in bun verifying behavior are

enough to handle any memory errors. Are

you [ __ ] kidding? I don't know if I

can finish this. I'm so pissed off. What

happened to the test suite being

sufficient to catch everything? It's not

sufficient to catch bugs in the Zig

code, but it is to catch bugs in a

million lines of unreed slop. This is

the most damning thing I've ever seen a

language author write. This is him

outright admitting he cannot fathom how

Rust has guarantees that Zigg doesn't.

He genuinely believes that unit tests

are all it takes to prevent memory

leaks. And that's why Zig's a terrible

language because it's creator doesn't

understand [ __ ] memory, which is

unbelievable. I love this. He claims

that the performance improvements are

due to LTO, which Zigg supports, and it

was enabled before by default, but they

turned it off because of LLVM bugs. All

of which also affect Rust. We probably

tried to tell you to try enabling it and

you didn't listen. I love the probably

tried [ __ ] The post implies you

were diligently fuzzing the Zig code.

While during our calls, the bun team

told us that they were not fuzzing

anything. Didn't you just say the calls

stopped? Pretty sure you did. Pretty

sure you said that you guys stopped

talking and that you drifted so you

wouldn't know this. The bun post

outlines a bunch of engineering work

done to reduce binary size to better

make the case that bun is better in

Rust. No, it doesn't. It calls out these

small benefits, the fact they saw more

and they went and took them. It wasn't

used to justify this. If I was to reach

like this for your article, I could say

that this is an attempt to get Jared

killed in the street. Obviously, you're

not calling for that. But when you make

absolutely insane generalizations and

then a bunch of reaches on top, you can

say stupid [ __ ] You've done a lot of

that here. 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

engineering work that you should have

done in the Zigg codebase since the

beginning. This is like the whole

article is full of absurd speculative

reaches. This sentence is just [ __ ]

stupid. Obviously, this is not the case.

You can check the commit history to see

this is not the case. This is just a

desperate attempt to pretend Jared is

acting in bad faith when he has been

beyond transparent about all of this.

Apparently, Andrew was mad at him for

using comp time so much and even made a

time report thing to try and get him to

stop. Andrew noticed that Jared

neglected to mention compilation speed.

No, he didn't. He specifically talked

about how bad the compile times were and

how he had to break up the project

differently in order to make it work

reliably at all. The Zig compiler is

about 600,000 lines of code, roughly the

same size as Bun before the rewrite, and

he's clocking 16 seconds to build from

scratch with a clean cache. Yeah,

awesome. You do understand that Jared's

an engineer, right? that he can look at

these things and make a decision. Do you

understand how crazy it is that he

traded the super fast compile times from

Zigg for the god awful ones for Rust as

well as having to rearchitect the

project to have hundreds of crates

instead of just one which he preferred.

You should take this as a lesson,

Andrew. This [ __ ] Jared was so

frustrated with his experience working

in Zigg that he ate all of these real

costs that you're discussing because

again, let's be real here, your language

sucked so hard that the benefits didn't

matter to him enough. He wanted those

things. That's why he picked your

language. That's why he complimented

Zigg so much at the start of his post.

But because you're still acting like no

one uses your goddamn language, he

couldn't stick with it. So, he had to

switch to a language that has these

horrible compilation times. And he

admitted it. He's not hiding any of

this. You need to learn from this. Like,

if like like let's be real here. If I

had a kid and I would offer to drive

them to school and they said, "No, fine.

I'll walk and the school's 20 miles

away." That doesn't mean the kid is

stupid. Okay? Might. But it also

probably means I screwed up some amount

that my kid doesn't want to get in the

car with me and will instead go through

that insane amount of pain because they

would rather deal with that than get in

my [ __ ] car. That is what you're

doing here. You are mad at the kid for

not wanting to be near you because you

[ __ ] suck. Oh, the kid's so stupid

for walking to school. No, you're a

shitty parent. What did we learn here

today? The main issue here was the

relationship breakdown. as he's outlined

above. Nothing to do with programming

language features. Of course, I don't

expect the blog post to admit that.

Really, it was well played. I'll read

his last words here, but I'm going to go

on one last tangent cuz remember, I'm a

friend of Jared's. We've talked about a

lot of different things, including his

choice of languages. He genuinely loves

Zigg. He loves it so much that he worked

his [ __ ] ass off to try and bridge

this relationship to try and help the

Zig community form a real presence in SF

and be pleasant to work with. He only

brought up these issues once or twice

with me ever. He's brought up a lot of

other things a lot more often. I'm

pretty sure I've talked about bunnies

with Jared more than I've talked about

the Zigg Foundation. But in the little

bit we talked, the tone I got from him

was slight disappointment. Like he

genuinely felt sad that the Zigg

Foundation was being unnecessarily

hostile. And he didn't even bring it up.

Like I had to bring it up and he was

like, "Yeah, I don't know what's up

there. It sucks cuz I love the language

and I love them and we donate, but

they're just like hostile towards us and

I don't get it." That was his take on

the whole thing over the last three plus

years I've talked about it with him. I

have heard more about this relationship

through this article than I've heard

from Jared over three years. Jared was

very kind and political about this,

which is crazy because you think he's

this terrible manager that's super

inconsiderate. You are projecting all of

your own bad behavior in this article in

the most absurd way. And we're about to

point out the absurd level as we wrap it

up. You only thank him for the

donations, not for any of the other

things he did or the absurd levels of

effort he put in and the promotion he

gave Zigg. I learned about this language

through Jared's work and now I will

never touch it thanks to your work. But

part two is where I want you to just and

Andrew, I know this has been spicy. I

know you're watching the whole thing

because you're a narcissistic prick, but

I need you to just reset everything I've

said so far and lock in for a second

with me because there's a sentence we

have to look at together. I actually

don't have any personal criticisms of

Jared. I know you hate LLMs, but we're

going to do a thing. I don't want you to

think that this is a biased model. So,

I'm specifically asking ChatGpt, which

in seconds calls out that the article

contains numerous personal criticisms of

Jared, even though many arise in a

professional context, including but not

limited to calling him inexperienced and

prone to mediocre outcomes, groomed into

uncritically adopting Silicon Valley

ideology, saying that he has poor

communication, unrealistic expectations,

low empathy, no experience. He kept

nagging you. He's writing slop. And he's

singularly focused on productivity,

wealth, and exit strategies. Literally,

all of these things are personal

attacks, including calling him a stinky

manager. And just to address some bias,

we will ask our friend Fable 5. Yes,

pretty clearly. The disclaimer at the

end sits awkwardly against much of what

precedes it. The most direct example,

the article relays that based on

accounts from interviewees and

employees, Jared was a stinky manager.

The sheer volume of personal criticisms

of Jared in this article is genuinely

hilarious. You're [ __ ] hallucinating,

man. He has different tastes than me. He

wants different things out of life than

me. But I think he's actually happy and

successful exactly where he is. Unlike

you, you seem incredibly unhappy and

petty and pissed off. He figured out how

to accomplish all the stuff in life that

he wants. He gets to live out

productivity fantasy fever dreams. He's

probably already super wealthy. He has

minor tech celebrity status.

I think he did well for himself and I

don't wish him any ill will. I added

this paragraph in an update to the blog

post because it seems like people are

having a hard time believing me when I

say it's not personal and that I

actually accept Jared for who he is and

actually perceive him as successful by

his own standards and in fact am

genuinely happy for him. It's the truth

though. I accept people who are wildly

different than me. You're going to have

to accept that all of your users are too

and they're all going to stop using your

goddamn language. I don't hold it

against people that have different

tastes than me. And I don't even hate my

opponents in the world of business. You

of course you don't. You don't have a

[ __ ] business. If anything, we have

something in common. We're both playing

the same game, albeit on opposite teams.

What teams? What? What do you mean

you're playing on opposite teams? What

game? What the [ __ ] are you saying? His

team is shipping. Your team is [ __ ]

posting. His team is building useful

software. Your team is complaining of

people who build useful software. What

the [ __ ] do you mean opposite teams? I'm

happy our business interests are no

longer intertwined. As soon as the

internet stops arguing in public about

whether the rewrite was good or bad for

Bun based on the language choice, I

believe that concludes our interactions.

God, what are you linking here? He's

literally linking the sex robot skit

from whitest kids. You know, this guy's

a literal teenager. He is actually

operating as though he's 14 [ __ ]

years old. I've never seen anything like

this in my adult life. I'm I'm not even

kidding. Best part is it's not even a

target blank. It pulls you off his

website. Hey there, Theo from the future

here. Since this blog post was

published, it's been edited multiple

times, and it got edited again since I

filmed. And while this edit does soften

a few things, it also opens in like the

worst possible way, and I just I need to

crash out a bit more. Okay, this is the

change. First off, he changed the title

of that last section from uh what do we

learn here today to moving on. Notice

that I have this blog post open twice

cuz this is from last stream. This is

from today's recording. So it's the same

link but two different pieces of

content. He used to say that this was a

relationship breakdown as he outlined

above. He changed it to my main issue

here has nothing to do with the language

features of Zigg versus Rust and

everything to do with the diverging

value system of the two projects in

relationship breakdown that followed.

Zooming out I want to make one thing

clear and here is where it falls apart.

While I resent Jared for making Bun into

an embarrassment for Zigg, and I blame

him partially for some of the slop we've

been dealing with, you know that he

didn't have the words partially and some

until he had someone else give feedback

on it. And it was previously I blame him

for the slop we've been dealing with.

And he added those words to make it feel

less absurd. And he stands by the

criticism of his leadership. He also

empathizes with Jared. 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. yada yada yada.

Same thing that he mostly had there.

Then he says, "The blog has been

characterized as a personal attack

against Jared when he 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. Yeah, no

[ __ ] I've updated this conclusion

section after self-reflection and

chatting with friends. Feel free to go

look at the original text in the

website's public source repo. The other

critical mistake I made with this post

was failing to consider the rather

obvious and important point that this

might affect Zigg users who knew next to

none of these facts and have only the

surface level understanding that an

exzig user is getting trashed by the

language creator. Such people might

reasonably worry that this 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 the other ZSF

folks have outstanding relations with

essentially everyone who openly uses

Zigg and talks about it publicly. And

this incident is the one exception. the

the biggest one is the exception. Plenty

of people have decided to move away from

Zigg was zero fuss. I hope you give me

some grace considering a trillion dollar

company fired the first shot. No, you

were saying earlier that they were doing

this before. Also, the blog post wasn't

a shot. I agree that a shot was fired

here and that shot killed Zigg, but the

shot was fired by your gun in your hand

in your own direction. All of the issue

here is yours. 100% of it. And to the I

don't think I will do this again. People

seem to be worry about that. I just want

to highlight another blog post of his

quick. This one's titled I am not a

JavaScript developer. You would imagine

that this blog post is him crashing out

because he was mischaracterized in some

reporting or something somewhere, right?

Do you want to guess what this blog post

is about before you read the page? It's

this. Back in 2013,

GitHub had a feature where the languages

you used would be put under your bio on

GitHub. And since he had one project

that had some JavaScript in it, it put

JavaScript under his username on GitHub.

And this caused him to crash out so

hard, he wrote a page and a half about

it on his blog because he hates the idea

of being categorized as a JavaScript

developer so much with just one word as

a label on his GitHub. If that's enough

to get this guy to crash out, I do not

trust him in saying that this is a

one-time thing at all. One more quick

joke and then we'll go back to my

original crash out. I I just love Ellie

and thought this was hilarious. I'm

going to make a programming language

slop lang. And if any of my users dare

to write nice code, manage their

employees well, or bootstrap, I'll write

a blog about what a shitty person they

are. Just I thought this one was funny.

Anyways, back to what Theo 3 days ago

was saying. Holy [ __ ] I got nothing.

I'm angry. I hope you are, too. I would

do the normal outro, but I don't feel

like switching the camera. Peace nerds,

I guess. What the [ __ ]