It's fine but why is Js a good language for agents? I mean sure its faster than python but wouldn't something that compiles to native be much better?

This is an insanely good take I never thought of.

What the ? I am either too old, or stupid, or both, to understand this. I'd expect this bullshit from Consultants.

I'm sort of surprised to see that you used Claude Code so much. I had a vague idea that "Zig people" were generally "Software You Can Love" or "Handmade Software Movement" types, about small programs, exquisitely hand-written, etc, etc. And I know Bun started with an extreme attention to detail around performance.

I would have thought LLM-generated code would run a bit counter to both of those. I had sort of carved the world into "vibe coders" who care about the eventual product but don't care so much about the "craft" of code, and people who get joy out of the actual process of coding and designing beautiful abstractions and data structures and all that, which I didn't really think worked with LLM code.

But I guess not, and this definitely causes me to update my understanding of what LLM-generated code can look like (in my day to day, I mostly see what I would consider as not very good code when it comes from an LLM).

Would you say your usage of Claude Code was more "around the edges", doing things like writing tests and documentation and such? Or did it actually help in real, crunchy problems in the depths of low level Zig code?

I've never personally used Bun. I use node.js I guess. What makes Bun fundamentally better at AI than, say, bundling a node.js app that can run anywhere?

If the answer is performance, how does Bun achieve things quicker than Node?

Does this acquisition preclude implementing an s3 style integration for AWS bedrock? Also is IMDSv2 auth on the roadmap?

Any chance there will be some kind of updating mechanism for 'compiled' bun executables?

Is this acquihiring?

on Bun's website, the runtime section features HTTP, networking, storage -- all are very web-focused. any plans to start expanding into native ML support? (e.g. GPUs, RDMA-type networking, cluster management, NFS)

You said elsewhere that there were many suitors. What is the single most important thing about Anthropic that leads you to believe they will be dominant in the coming years?

How much of your day-to-day is spent contributing code to the Bun codebase and do you expect it to decrease as Anthropic assigns more people to work on Bun?

Hi Jarred,

I contributed to Bun one time for SQLite. I've a question about the licensing. Will each contributor continue to retain their copyright, or will a CLA be introduced?

Thanks

Congrats on the payday :)

Do you think Anthropic might request you implement private APIs?

Hi Jarred, thanks for all your work on Bun.

I know that one thing you guys are working on or are at least aware of is the size of single-file executables. From a technical perspective, is there a path forward on this?

I'm not familiar with Bun's internals, but in order to get the size down, it seems like you'd have to somehow split up/modularize Bun itself and potentially JavaScriptCore as well (not sure how big the latter is). That way only the things that are actually being used by the bundled code are included in the executable.

Is this even possible? Is the difficulty on the Bun/Zig side of things, or JSC, or something else? Seems like a very interesting (and very difficult) technical problem.

One more thing I hope doesn't change, is the fun Release videos :-) I really enjoy them. They're very apple-y, and for just a programming tool.

Yeah why are you not out on a boat somewhere enjoying this moment? Go have fun please.

Any thoughts on the claude "soul document" that was leaked this week?

> They didn't have to join, which means they got a solid valuation.

Did they? I see a $7MM seed round in 2022. Now to be clear that's a great seed round and it looks like they had plenty of traction. But it's unclear to me how they were going to monetize enough to justify their $7MM investment. If they continued with the consultancy model, they would need to pay back investors from contracts they negotiate with other companies, but this is a fraught way to get early cashflow going.

Though if I'm not mistaken, Confluent did the same thing?

    > They didn't have to join, which means they got a solid valuation.

I don't really know any details about this acquisition, and I assume it's the former, but acquihires are also done for other reasons than "it was the only way".

Anthropic is still a new company and so far they seem "friendly". That being said, I still feel this can go either way.

> I believe this a bit less.

They weren’t acquired and got paid just to build tooling as before and now completely ignoring monetization until the end of times.

Given the worries about LLM focused companies reaching profitability I have concerns that Bun's runway will be hijacked... I'd hate for them to go down with the ship when the bubble pops.

I think Deno's management have been somewhat distracted by their ongoing lawsuits with Oracle over the release of the Javascript trademark.

I started out with Deno and when I discovered Bun, I pivoted. Personally I don't need the NodeJS/NPM compatability. Wish there was a Bun-lite which was freed of the backward compatability.

This is why we can't have nice things

But how is another company that is also VC backed and losing money providing stability for Bun?

How long before we hear about “Our Amazing Journey”?

On the other hand, I would rather see someone like Bun have a successful exit where the founders seem to have started out with a passion project, got funding, built something out they were excited about and then exit than yet another AI company by non technical founders who were built with the sole purpose of getting funding and then exit.

I admit, it is a good acquisition announcement. I can’t remember the last acquisition announcement that was kept for more than 1-2 years. Leadership changes, priorities shift…

Ditto, and I got to know Bun via HN. It seemed intriguing, but also "why another JS runtime" etc.

If Bun embraces the sweet spot around edge computing, modern JS/TS and AI services, I think their future ahead looks bright.

Bun seems more alive than Deno, FWIW.

I had the same impression: bottom line up front, didn’t bury the lede, no weasel language.

One thing I like about this, despite it meaning Bun will be funded, is Anthropic is a registered public benefit corporation. While this doesn't mean Anthropic cant fuck over the users of Bun, it at least puts in some roadblocks. The path of least-resistance here should be to improve Bun for users, not to monetize it to the point where it's no longer valuable.

My team has been using it in prod for about a year now. There were some minor bugs in the runtime's implementation of buffers in 1.22 (?), but that was about the only issue we ran into.

The nice things:

1. It's fast.

2. The standard library is great. (This may be less of an advantage over Deno.)

3. There's a ton of momentum behind it.

4. It's closer to Node.js than Deno is, at least last I tried. There were a bunch of little Node <> Deno papercuts. For example, Deno wanted .ts extensions on all imports.

5. I don't have to think about JSR.

The warts:

1. The package manager has some issues that make it hard for us to use. I've forgotten why now, but this in particular bit us in the ass: https://github.com/oven-sh/bun/issues/6608. We use PNPM and are very happy with it, even if it's not as fast as Bun's package manager.

Overall, Deno felt to me like they were building a parallel ecosystem that I don't have a ton of conviction in, while Bun feels focused on meeting me where I am.

I haven't used Deno, but I do use Bun purely as a replacement for npm. It does the hard-linking thing that seems to be increasingly common for package managers these days (i.e. it populates your local node_modules with a bunch of hard links to its systemwide cache), which makes it vastly quicker and more disk-efficient than npm for most usage.

Even with a cold cache, `bun install` with a large-ish dependency graph is significantly faster than `npm install` in my experience.

I don't know if Deno does that, but some googling for "deno install performance vs npm install" doesn't turn up much, so I suspect not?

As a runtime, though, I have no opinion. I did test it against Node, but for my use case (build tooling for web projects) it didn't make a noticeable difference, so I decided to stick with Node.

Search for pointer exceptions or core dumps on Bun's GitHub issues and you'll see why people (should) use Deno over Bun, if only because Rust is a way more safe language than Zig.

Easily bundling and serving frontend code from your backend code is very appealing: https://bun.com/docs/bundler/fullstack

Despite the page title being "Fullstack dev server", it's also useful in production (Ctrl-F "Production Mode").

I tried several times to port Node projects to Deno. Each time compatibility had "improved" but I still didn't have a working build after a few days of effort.

I don't know how Deno is today. I switched to Bun and porting went a lot smoother.

Philosophically, I like that Bun sees Node compatibility as an obvious top priority. Deno sees it as a grudging necessity after losing the fight to do things differently.

> Bun seems to use a different runtime (JSC) which is less tested than V8, which makes me assume it might perform worse in real-world tasks (maybe not anymore?).

JSC is still the JS engine for WebKit-based browsers, especially Safari, and per Apple App Store regulations the only JS engine supposedly allowable in all of iOS.

It's more "mature" than V8 in terms of predating it. (V8 was not a fork of it and was started from scratch, but V8 was designed to replace it in the Blink fork from WebKit.)

It has different performance goals and performance characteristics, but "less tested" seems uncharitable and it is certainly used in plenty of "real-world tasks" daily in iOS and macOS.

I’ve been using Deno too. Although npm support has improved and it’s fine for me, I think Deno has more of a “rewrite the world” philosophy. For example, they created their own package registry [1] and their own web framework [2]. Bun seems much more focused on preexisting JavaScript projects.

[1] https://jsr.io/ [2] https://fresh.deno.dev/

Is JSC less tested? I thought it was used in Safari, which has some market share.

I used bun briefly to run the output of my compiler, because it was the only javascript runtime that did tail calls. But I eventually added a tail call transform to my compiler and switched to node, which runs 40% faster for my test case (the compiler building itself).

It has wayyyyy better nodejs compatibility (day 1 goal)

I had memory leaks in bun and not in deno or node for the same code. ymmv

It just works. Whatever JavaScript/TypeScript file or dependencies I throw at it, it will run it without needing to figure out CJS or ESM, tsconfig, etc.

I haven't had that experience with deno (or node)

Agreed, the language would be interesting during the 1990's, nowadays not so much.

The tools that the language offers to handle use after free is hardly any different from using Purify, Insure++ back in 2000.

I've found it to be at least twice as fast with practically no compat issues.

I always figured Bun was the "enterprise software" choice, where you'd want to use Bun tools and libraries for everything and not need to bring in much from the broader NPM library ecosystem.

Deno seems like the better replacement for Node, but it'd still be at risk of NPM supply chain attacks which seems to be the greater concern for companies these days.

> I'll admit I'm somewhat biased against Bun?

Why? Genuine question, sorry if it was said/implied in your original message and I missed it.

Stopped following Deno while they were rejecting the need for a package management solution. Used Bun instead.

Is it just me, but I don't find npm that slow? Sure it's not a speed demon, but I rarely need to do npm install anyways so it's not a bottleneck for me.

For deploy, usually running the attached terraform script takes more time.

So while a speed increase is welcome, but I don't feel it gives me such a boost.

> is there anything that Bun does better?

Telling prospective employees that if you're not ready to work 60-hour weeks, then what the fuck are you doing here? for one.

> Zig does force some safety with ReleaseSafe IIRC

which Bun doesn't use, choosing to go with `ReleaseFast` instead.

I've been using Bun since 2022 just to be trendy for recruitment (it worked, and still works despite it almost being 2026)

Bun is fast, and its worked as a drop in replacement for npm in large legacy projects too.

I only ever encountered one issue, which was pretty dumb, Amazon's CDK has hardcoded references to various package manager's lock files, and Bun wasn't one of them

https://github.com/aws/aws-cdk/issues/31753

This wasn't fixed till the end of 2024 and as you can see, only accidentally merged in but tolerated. It was promptly broken by a bun breaking change

https://github.com/aws/aws-cdk/issues/33464

but don't let Amazon's own incompetency be the confirmation bias you were looking for about using a different package manager in production

you can use SST to deploy cloud resources on AWS and any cloud, and that package works with bun

I think this wound up being close enough to true, it's just that it actually says less than what people assumed at the time.

It's basically the Jevons paradox for code. The price of lines of code (in human engineer-hours) has decreased a lot, so there is a bunch of code that is now economically justifiable which wouldn't have been written before. For example, I can prompt several ad-hoc benchmarking scripts in 1-2 minutes to troubleshoot an issue which might have taken 10-20 minutes each by myself, allowing me to investigate many performance angles. Not everything gets committed to source control.

Put another way, at least in my workflow and at my workplace, the volume of code has increased, and most of that increase comes from new code that would not have been written if not for AI, and a smaller portion is code that I would have written before AI but now let the AI write so I can focus on harder tasks. Of course, it's uneven penetration, AI helps more with tasks that are well-described in the training set (webapps, data science, Linux admin...) compared to e.g. issues arising from quirky internal architecture, Rust, etc.

Why didn't they just use AI to write their own Bun instead of wasting 8-9 figures on this company? Makes no sense.

Maybe he was correct in the extremely literal sense of AI producing more new lines of code than humans, because AI is no doubt very good at producing huge volumes of Stuff very quickly, but how much of that Stuff actually justifies its existence is another question entirely.

Why do people always stop this quote at the breath?

> .... and in 12 months, we might be in a world where the ai is writing essentially all of the code. But the programmer still needs to specify what are the conditions of what you're doing; What is the overall app you're trying to make; What is the overall design decision; How we collaborate with other code that has been written; How do we have some common sense with whether this is a secure design or an insecure design. So as long as there are these small pieces that a programmer has to do, then I think human productivity will actually be enhanced

(He then said it would continue improving, but this was not in the 12 month prediction.)

Source interview: https://www.youtube.com/live/esCSpbDPJik?si=kYt9oSD5bZxNE-Mn

I actually like claude code, but that was always a risky thing to say (actually I recall him saying their software is 90% AI produced) considering their cli tool is literally infested with bugs. (Or it least it was last time I used it heavily. Maybe they've improved it since.)

Do you have a source for the quote?

I'm curious what people think of quotes like these. Obviously it makes an explicit, falsifiable prediction. That prediction is false. There are so many reasons why someone could predict that it would be false. Is it just optimistic marketing speech, or do they really believe it themselves?

Why didn't they have the AI write a JS runtime instead of this acquisition?

Accurate for me. Accurate for basically every startup from the past 12 months. Prob not for legacy codebases, though.

AI writes about 90% of my code.

It’s enough Anthropic finds it profitable to run Claude Code on it.

> This acquisition makes no sense.

except this sense:

> Investors must be happy because Bun never had to find out how to become profitable.

If Anthropic wants to own code development in the future, owning the full platform (including the runtime) makes sense.

Programming languages all are a balance between performance/etc and making it easy for a human to interact with. This balance is going to shit as AI writes more code (and I assume Anthropic wants a future where humans might not even see the code, but rather an abstraction of it... after all, all code we look at is an abstraction on some level).

Claude Code running on Bun is an obvious justification, but Buns features (high performance runtime, fast starts, native TS) are also important for training and inference. For instance, in inference you develop a logical model in code that maps to a reasoning sequence, and then execute the code to validate and refine the model, then use this to inform further reasoning. Bun, which is highly integrated and highly focused on performance, is an ideal fit for this. Having Bun in house means that you can use the feedback from all of automation driven execution of Bun to drive improvements to its core.

It does actually.

Claude Code is a 1B+ cash machine and Anthropic directly uses Bun for it.

Acquiring Bun lowers the risk of the software being unmaintained as Bun made $0 and relied on VC money.

Makes sense, but this is just another day in San Francisco of a $0 revenue startup being bought out.

Looks like they are acquiring the team rather than the product

Does this acquisition mean Claude Code the CLI is more valuable than entiriety of Bun?

One option is that the current Bun shareholders didn't see a profitable future and didn't even care if they were made even and a return of the remaining cash was adequate.

Another option is that this was an equity deal where Bun shareholders believe there is still a large multiple worth up potential upside in the current Anthropic valuation.

Plus many other scenarios.

i don’t get it either - bun being the foundation of tons of AI tools is like a best possible outcome, what were they hoping for when they raised the money? Or is this just an admission of “hey, that was silly, we need to land this however we can”? Or do they share major investors and the therefore this is just a consolidation? (Edit: indeed, KP did indeed invest $100M in Anthropic this year. I’m also confused - article states Bun raised 26M but the KP seed round was 7, did they do the A too but unannounced? Notably, the seed was summer 2022 and chatgpt was Nov 30, so the world is different, did the hypothesis change?)

Free now isn't free forever. If something has inherent value then folks will be willing to pay for it.

The post mentions why - Bun eventually wanted to provide some sort of cloud-hosting saas product.

I mean if you're getting X number of users per day and you don't need to pay for bandwidth or anything, there's gotta be SOME way to monetize down the line.

If your userbase or the current CEO likes it or not.

Either for a modest return when it sells or as a tax write off when it fails.

It doesn't read like that to me at all. This reads to me like Anthropic realizing that they have $1bn in annual revenue from Claude Code that's dependent on Bun, and acquiring Bun is a great and comparatively cheap way to remove any risk from that dependency.

Nah, it reads like the normal logic behind the consulting model for open source monetization, except that Bun was able to make it work with just one customer. Good for them, though it comes with some risks, especially when structured as an acquisition.

esbuild is still a Go app today: https://github.com/evanw/esbuild

The first hints of what become Bun were when Jared experimented at porting that to Zig.

They switched to recommending this as the installation method back in July:

  curl -fsSL https://claude.ai/install.sh | bash

Don't they already have a ton of telemetry from Claude Code itself? I'd be shocked and expect an instant fork if Anthropic telemetry was added to Bun.

You’re reading a code of conduct for contributing to the zig project. I don’t think everything there is guidance for everything written in zig, eg ‘English is encouraged’ is something one might not want for a project written in zig by native French-speakers, and I don’t think that’s something zig would want to suggest to them. I read the AI part is much more motivated by the asymmetries of open source project contribution than any statement about the language itself. Fly-by AI contributions are bad because they make particularly poor use of maintainer time. Similar to the rule on proposing language changes, which can suck up lots of reading/thinking/discussion time. When you have people regularly working together (eg those people in anthropic working on bun) the incentives are different because there is a higher cost to wasting your colleague’s time.

> Bun and Zig are increasingly culturally apart

That's like saying GCC and NodeJS are culturally apart, as if that has significant bearing on either?

Nothing I found says anything about Zig folks being inherently against AI. It just looks like they don’t want to deal with “AI Slop” in contributions to their project, which is very understandable.

Ink (and modern alternatives) probably are the best TUI toolkit. If you want to write a UI that's genuinely good, you need e.g. HTML, or some way to express divs and flex box. There isn't really another way to build professional grade UIs; I love immediate mode UI for games, but the breadth of features handled by the browser UI ecosystem is astonishing. It is a genuinely hard problem.

And if you're expressing hierarchical UI, the best way to do it is HTML and CSS. It has the richest ecosystem, and it is one of the most mature technologies in existence. JS / TS are the native languages for those tools. Everything is informed by this.

Of course, there are other options. You could jam HTML and CSS into (as you mention) Rust, or C, or whatever. But then the ecosystem is extremely lacking, and you're reinventing the wheel. You could use something simpler, like QML or handrolled. But then you lose the aforementioned breadth of features and compatibilities with all the browser code ever written.

TypeScript is genuinely, for my money, the best option. The big problem is that the terminal backends aren't mature (as you said, scrollback, etc). But, given time and money, that'll get sorted out. It's much easier to fix the terminal stuff than to rewrite all of the browser.

I have to admit this was my first thought, too. I'm pretty obsessed with Claude Code, but the actual app is so incredibly poorly engineered for something that doesn't even do that much.

Rust, Go, whatever -- writing a good TUI isn't that hard of a problem. Buying an entire VC funded JS runtime company isn't how you solve it.

Boggles the mind.

you know Deno is VC backed right

A nice start would probably be for Claude Code to stop trying to use npm when it detects a bun lockfile and vice versa...

Then it would probably be back to Poetry. Or some other newcomer, or maybe a fork of uv.

Never used any of their tools.

Python is doing great, other than still doing baby steps into having a JIT in CPython.

Our entire business runs on Python without a drop of Astral in the mix. No one would even notice.

I don't want to even think about it. uv has been a revelation!

#1, uv is open-source and it could easily be forked and kept up to date.

#2, if you don't like uv, you can switch to something else.

uv probably has the least moat around it of anything. Truly a meritocracy: people use it because it's good, not because they're stuck with it.

Finally, an event capable of killing the Python demon!

Nothing gives you long term stability in tech. You have to constantly work at staying stable, and it isn't always up to anything the company is in control of, no matter what ownership they have.

With AI tooling, we are in the era where rapid iteration on product matters more than optimal runtime performance. Given that, implementing your AI tooling in a language that maximizes engineer productivity makes sense, and I believe GC does that.

Codex is written in Rust

It is open source (MIT license), Claude should have a pretty good start on it already.

Because they have a product that makes $1bn+ a year that depends on having a good, stable, cross-platform JS runtime.