Zig's creator can't stop himself transcript

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 [ __ ]