Yea, they just posted this a few days ago:

https://www.anthropic.com/engineering/advanced-tool-use

They discussed how running generated code is better for context management in many cases. The AI can generate code to retrieve, process, and filter the data it needs rather than doing it in-context, thus reducing context needs. Furthermore, if you can run the code right next to the server where the data is, it's all that much faster.

I see Bun like a Skynet: if it can run anywhere, the AI can run anywhere.

Yea - if you want a paranoidly-sandboxed, instant-start, high-concurrency environment, not just on beefy servers but on resource-constrained/client devices as well, you need experts in V8 integration shenanigans.

Cloudflare Workers had Kenton Varda, who had been looking at lightweight serverless architecture at Sandstorm years ago. Anthropic needs this too, for all the reasons above. Makes all the sense in the world.

Isn't what you're describing just a set of APIs with native bindings that the LLM can call?

I'm not sure I understand why it's necessary to even couple this to a runtime, let alone own the runtime?

Can't you just do it as a library and train/instruct the LLM to prefer using that library?

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?

>Claude will be able to leverage these capabilities to extend its reach across the cloud and add more value in enterprise use cases

100%. even more robust if paired with an overlay network which provides identity based s3 access (rather than ip address/network based). else server may not have access to s3/cloud resource, at least for many enterprises with s3 behind vpn/direct connect.

ditto for cases when want agent/client side to hit s3 directly, bypassing the server, and agent/client may not have permitted IP in FW ACL, or be on vpn/wan.

Could also be a way to expand the customer for Claude Code from coding assistant to vibe coding, a la Replit creating a hosted app. CC working more closely with Bun could make all that happen much faster:

> Our default answer was always some version of "we'll eventually build a cloud hosting product.", vertically integrated with Bun’s runtime & bundler.

That's a really cool use case and seems super helpful. working cloud native is a chore sometimes. having to fiddle with internal apis, acl/permissions issues.

This is an insanely good take I never thought of.

The writeup makes it sound like an acquihire, especially the "what changes" part.

ChatGPT is feeling the pressure of Gemini [0]. So it's a bit strange for Anthropic to be focusing hard on its javascript game. Perhaps they see that as part of their advantage right now.

[0] https://timesofindia.indiatimes.com/technology/tech-news/goo...

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

As a commandline end user who prefers to retreive data from the www as text-only, I see deno and bun as potential replacements (for me, not necessarily for anyone else) for the so-called "modern" browser in those rare cases where I need to interpret Javascript^1

At present the browser monstrosity is used to (automatically, indiscriminantly) download into memory and run Javascripts from around the web. At least with a commandline web-capable JS runtime monstrosity the user could in theory exercise more control over what scripts are downloaded and if and when to run them. Perhaps more user control over permissions to access system resources as well (cf. corporate control)

1. One can already see an approach something like this being used in the case of

https://github.com/yt-dlp/yt-dlp/wiki/EJS

where a commandline JS runtime is used without the need for any graphics layer (advertising display layer)

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

This isn't really true. It's more about who wanted them to join. Maybe it was Anthropic who really wanted to take over Bun/hire Jarred, or it was Jarred who got sick of Bun and wanted to work on AI.

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'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?

Hi Jarred. Congratulations on the acquisition! Did (or will) your investors make any profit on what they put into Bun?

Are you at liberty to divulge how much Anthropic paid for Bun?

Is this acquihiring?

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?

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)

Congrats on the payday :)

Do you think Anthropic might request you implement private APIs?

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

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

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

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.

"work on Bun." LOL.

Congratulations.

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

This is why we can't have nice things

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.

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.

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 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…

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.

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

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 really want to like Deno and will likely try it again, but last time I did it was just a bit of a pain anytime I wanted to use something built for npm (which is most packages out there), whereas bun didn't have that problem.

There's certainly an argument to be made that, like any good tool, you have to learn Deno and can't fall back on just reusing node knowledge, and I'd absolutely agree with that, but in that case I wanted to learn the package, not the package manager.

Edit: Also it has a nice standard library, not a huge win because that stuff is also doable in Deno, but again, its just a bit less painless

Looking at Bun's website (the comparison table under "What's different about Bun?") and what people have said here, the only significant benefit of Bun over Node.js seems to be that it's more batteries-included - a bigger standard library, more tools, some convenience features like compiling JSX and stripping TypeScript types on-the-fly, etc.

It's not clear to me why that requires creating a whole new runtime, or why they made the decisions they did, like choosing JSC instead of V8, or using a pre-1.0 language like Zig.

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 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/

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

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 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'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.

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.

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

> bought influence over Zig as a reaction

Elaborate? I believe Zig's donors don't get any influence and decision making power.

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.

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.

Given the horrible stability of Windows this year, it seems like Microsoft went all in on that

Why do people always stop this quote at the breath? The rest of it says that he still thinks they need tech employees.

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

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).

   "the full platform"

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.

Looks like they are acquiring the team rather than the product

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.

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

Agents already do this exact thing, except that the go-to language for Claude to write one-off scripts in is usually Python.

Am I missing something - I thought that GPUs are for training the weights

Being able to create an agent in any language to run on any hardware has always been possible hasn't it?

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?)

If I was to pick a language, I'd pick the one all developers agree is the best.

Same reason AIs also use Python and DBMSes offer JS or Py UDFs easily, interpreted languages take no build time and are more portable. JS is also very popular.

Sadly, this will be the trend with things moving forward. JS is perceived as a good language and LLMs are meant to make them even easier to write. It is not about the mertis of a language. It's about which languages LLMs are "good" at.

AI are good at JS because basically there is a ton of JS code available publicly without usage restriction: the JS code published to be executed in your browser. Most of JS code attached to web pages has no explicit license, but the implicit license is that anyone can download it and run it. Same for HTML and CSS. So using that public code to train models is a no brainer.

Because js became an everything language that everyone can write and its the only language you ever need.

I dislike it also..

You could make a better argument for Go (compiles to native for multiple targets, zero actual dependencies (no need for a platform or virtual machine on the target)

> Prior to Bun, there was little focus on performance.

This is just completely insane. We went through more than a decade of performance competition in the JS VM space, and the _only_ justification that Google had for creating V8 was performance.

> The V8 engine was first introduced by Google in 2008, coinciding with the launch of the Google Chrome web browser. At the time, web applications were becoming increasingly complex, and there was a growing need for a faster, more efficient JavaScript engine. Google recognized this need and set out to create an engine that could significantly improve JavaScript performance.

I guess this is the time we live in. Vibe-coded projects get bought by vibe-coded companies and are congratulated in vibe-coded comments.

That's because it's not written in JS at all but a compiled systems language, no wonder it's gonna be fast.

One important original point of node was that v8 made JS very fast by compiling to machine code, plus it’s had multithreading built in for a decade.

That is the most absurd thing I've heard in 20 years. Chrome literally was launched on performance, for JS and beyond.

The reality is that the insane "JS ecosystem" will rally around whatever is the latest hotness.

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

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

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.

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.

“Port it to a different language” a language that’s more out of distribution? Bad devex. Store data as an unreadable binary file? Bad devex.

Stay in distribution and in the wave as much as possible.

Good devex is all you need. Claude code team iterates and ships fast, and these decisions make total sense when you realize that dev velocity is the point.

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.

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.

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.

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.

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

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

That install script gives you a single binary which is created using Bun.

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

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.

Never used any of their tools.

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

Finally, an event capable of killing the Python demon!

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.

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

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

I'm wondering if Bun would be a good embedded runtime for Claude to think in. If it does sandboxing, or if they can add sandboxing, then they can standardize on a language and runtime for Claude Code and Claude Desktop and bake it into training like they do with other agentic things like tool calls. It'd be too risky to do unless they owned the runtime.

Why would Sun then Oracle own Java? Why would Microsoft own .net? Why would Apple own swift?

IOW look where the puck is going.

you know Deno is VC backed right

I bet CC will become a binary with bun included and it'll use it's internal JS engine to run most scripts.

Oddly I saw it try to use bun the other day, and was confused because everything in the project is in node.

I always tell it to use Bun and it works? Am I misunderstanding?

That is the way, when one is long time around, there are these alternatives coming and going, while the reference platforms keep going.

So you pushed a PR that breaks a bunch of tests, added a 5 layer nested if branch block that mixes concerns all over the place, then ignored the reviewer for three weeks, and you’re surprised they didn’t approve it?

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

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

It reminds me of hearing that music majors often do well in medical school. Want to go to medical school? Just major in music, duh.

Lots of strategists will tell you something like: "Build something that's useful and then there will be money".

That's 100% what happened to Bun. It's useful (like really useful) and now they're getting rewarded

Honestly that's probably the best play. Monetizing dev tools directly is a nightmare.

i really think this is part of the pitch deck for bun's funding. that a bigger company would acquire it for the technology. the only reason an AI company or any company for that matter would acquire it would be to:

1. acquire talent.

2. control the future roadmap of bun.

i think it's really 1.

I had the same thought when openai acquired rockset.

Well, that was the playbook in the 1999-2001 dotcom days.

Its not 100% nodejs compatible. I see enough non-green dots in their own official report https://bun.com/docs/runtime/nodejs-compat

And even in packages with full support you can find many github issues that bun behaves directly which leads to some bugs.

> This will make sure Bun is around for many, many, years to come.

Well, until the bubble bursts and Anthropic fizzles out or gets acquired themselves.

Does it have permission flags yet like deno has?

It'll be around until they realize it makes 0$, and costs them millions per year in salaries/stock. then it will quietly die

The point of this deal is that they do not need to change the license. Nobody will ever pay for Bun and now they don't have to force it.

I don't know for sure, but it's definitely the first tool of that value to have a persistent strobing (scroll position) bug so bad that passersby ask me if I'm okay when they see it.

This graph from the SemiAnalysis blog suggests that GitHub Copilot reached it earlier this year: https://substackcdn.com/image/fetch/$s_!BGEe!,f_auto,q_auto:...

Terraform gets to $600mm if you squint really hard make up stuff. Kubectl though. Whatever you want to say about kubernetes complexity, it does get a bunch of money run through it. We could also look at aws-cli, gcloud and az, and if we assign cloud budgets that get run through there, I'm sure it's in the hundreds of millions. Then there's git. Across the whole ecosystem, there's probably a cool couple billion floating through there. gh is probably much smaller. Other tools like docker and ansible come to mind, though those are not quite as popular. Cc only hits $1B ARR if you squint really hard in the first place, so I think in this handwavy realm, I'd say aws-cli comes first, then kubectl, then git, with maybe docket and terraform in the mix as well. Nonetheless, Claude is a really awesome cli tool that I use most days, I find.

Bun was VC funded.

I'd say Ghostty is a pretty big success story as well.

Look, if a terminal emulator can raise $67 million by riding the AI hypewave then a Javscript runtime can do the same. Nobody ever said that AI investments and acquisitions have to make any sense.

Yeah that’s the main part that puzzled me, super happy for the team that they got a successful exit, but I wouldn’t really consider Anthropic’s situation to be stable…

Yeah, no reader of tech news will take an acquisition of a company with four years of runway as anything but decreasing the odds their product will still be around (and useful to the same audience…) in four years. Even without being tied to a company with lots of exposure to a probable bubble.

I say don't muddy the water with the public panic over "will it won't it" bubble burst predictions.

The effective demand for Opus 4.5 is bottomless; the models will only get better.

People will always want a code model as good as we have now, let alone better.

Bun securing default status in the best coding model is a win-win-win

It's the Anthropic careers page that you're likely looking for now:

https://www.anthropic.com/jobs?team=4050633008

Maybe the engineers are Claude agents.

The big advantage of a language like JavaScript of Python for a CLI tool of this nature is that they naturally support adding extensions or plugins.

That's quite a bit harder if your tool is built using a compiled language like Go.

Why not?