Anthropic acquires Bun
(bun.com)1856 points by ryanvogel 17 hours ago
1856 points by ryanvogel 17 hours ago
Those aren't your customers. The people that want to build things with bun are. The problem with people who already know how to code is that they have opinions if they actually read the generated code. If you sell to people who don't (for whatever reason), you face less criticism.
I use Claude Code CLI daily - it's genuinely changed how I work. The $1B number sounds crazy but honestly tracks with how good the tool is. Curious how Bun integration will show up in practice beyond the native installer.
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?)
It's more honest than the Replicate answer but I think inevitably if you can't raise the next round and you get distracted by the shiny AI that this is the path taken by many teams. There is absolutely nothing wrong with that. There was an exuberant time when all the OSS things were getting funded, and now all AI things get funded. For many engineer founders, it's a better fit to go build deep technical stuff inside a bigger company. If I had that chance I would probably have taken it too. Good luck to the Bun team!
That's good news. I hope this will encourage the industry to use the Zig language (and its creators to release version 1.0).
Genuine question: why js?
Why not something like c#: native, fast, crossplatform, strongly-typed, great tooling, supports both scripting (ie single file-based) and compiled to a binary with no dependency whatsoever (nativeAOT), great errors and error stacks, list goes on.
All great for AI to recover during its iterations of generating something useful.
Genuinely perplexed.
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.
Ahahahahhahahahahhahahahaahaha. Please tell me this is tongue-in-cheek and just more subtle than I give HN credit for. Please.
Not all devs, not even most, but I certainly think this
So, everyone who can hack some JS is now a developer? The '100x' claim is obviously exaggerated. C# is certainly one of the most used programming languages there is.
You can run also C# code very quickly, but have the option (but not the need) to AOT compile it. I would say the only real edge JS has is the ability to run natively in the browser. It was built for that purpose, and in my opinion, that is where it should have stayed.
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.
Might also be a context window thing. Idk how much boilerplate C# has, but others like Java spam it.
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)
C# no longer requires .net installed or bundled inside exe.
Like I’ve said: NativeAOT
https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...
Go is the most portable compiled language out there and makes a lot of compromises with the interpreted lang world. But it's got its own issues.
>zero actual dependencies
on Linux only with CGO_ENABLED=0 and good luck using some non web related 3rd party module which can be used with CGO disabled.
Extrapolating and wildly guessing, we could end up with using all that mostly idle CPU/RAM (the non-VRAM) on the beefy GPUs doing inference on agentic loops where the AI runs small JS scripts in a sandbox (which Bun is the best at, with its faster startup times and lower RAM use, not to mention its extensive native bindings that Node.js/V8 do not have) essentially allowing multiple turns to happen before yielding to the API caller. It would also go well with Anthropic's advanced tool use that they recently announced. This would be a big competitive advantage in the age of agents.
I almost read this as anthropic will be using our idle CPU/GPU resources for their own training tasks ;)
This decision is honestly very confusing to me as a constant user of Claude Code (I have 3 of them open at the moment.)
So many of the issues with it seem to be because ... they wrote the damn thing in JavaScript?
Claude is pretty good at a constrained task with tests -- couldn't you just port it to a different language? With Claude?
And then just ... the huge claude.json which gets written on every message, like ... SQLite exists! Please, please use it! The scrollback! The Keyboard handling! Just write a simple Rust or Go or whatever CLI app with an actual database and reasonable TUI toolkit? Why double down and buy a whole JavaScript runtime?
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 like JS for this use case, and React on web, but really not fond of the Ink usage. Idk if it's Ink itself or the way it gets used, but somehow people are making CLIs that lag and waste terminal space now.
Ink seems to be the root cause of a major issue with the Claude Code CLI where it flickers horribly when it needs to repeatedly clear the screen and redraw.
I don't know why it's even necessary for this.
https://github.com/atxtechbro/test-ink-flickering
Issue on Claude Code GitHub:
The idea that you need or want HTML or CSS to write a TUI is missing the entire point of what made TUIs great in the first place. They were great precisely because they were clean, fast, simple, focused -- and didn’t require an entire web stack to draw colored boxes.
I'm not so sure about that. I've written some nontrivial TUIs in my time, the largest one being [1], and as the project got more complicated I did find myself often thinking "It sure would be nice if I could somehow just write this stuff with CSS instead of tiny state machines and control codes for coloration". There's no reason these languages couldn't compile down to a TUI as lean as hand-coloring everything yourself.
“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.
There's no reason to run agents on expensive AI platforms or on GPUs - when you can have the AI create an agent in JS and thus runs with very high performance and perfect repeatability on far less expensive CPUs.
At the very least there must be some part of the agent tasks that can be run in JS, such as REST APIs, fetching web results, parsing CSV into a table, etc.
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?
So many comments about reasoning here, yet none about the very obvious one, it's not stability of the infrastructure, it's future direction of a product like Claude Code. They need to know how to continue their optimisation machine to fit developers needs the best way possible (for good or for worse).
I guess we should wait for some opt-out telemetry some time soon. It'll be nothing too crazy at first, but we'll see how hungry they are for the data.
I don't get it. Why would Anthropic need to own a JS runtime?
Because they have a product that makes $1bn+ a year that depends on having a good, stable, cross-platform JS runtime.
but they are a company that burns billions every year in losses and this seems like a pretty random acquisition.
Bun is the product that depends on providing that good, stable, cross-platform JS runtime and they were already doing a good job. Why would Anthropic's acquisition of them make them better at what they were already doing?
It's Anthropic, not Microsoft. They already had a runway of 4 years, and honestly, that is preferable to hitching their wagon to a volatile startup like Antropic.
>but they are a company that burns billions every year in losses
No they don't.
> As discussed previously, OpenAI lost $5 billion and Anthropic $5.3 billion in 2024, with OpenAI expecting to lose upwards of $8 billion and Anthropic — somehow — only losing $3 billion in 2025. I have severe doubts that these numbers are realistic, with OpenAI burning at least $3 billion in cash on salaries this year alone, and Anthropic somehow burning two billion dollars less on revenue that has, if you believe its leaks, increased 500% since the beginning of the year.
https://www.wheresyoured.at/why-everybody-is-losing-money-on...
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.
Considering that 1) Bun is written in Zig, 2) Zig has a strict no-AI policy [1], and 3) Bun has joined Claude, it seems that Bun and Zig are increasingly culturally apart.
[1] https://ziglang.org/code-of-conduct/#strict-no-llm-no-ai-pol...
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?
Has CC always used Bun? When it tries it out many months ago it was an npm install not bun install in their instructions (although I did use bun install myself). Just odd that if they were using bun, why the installation wasn’t specifically a “bun install” (I suppose they were trying to keep it vanilla for the npm masses?)
Then it would probably be back to Poetry. Or some other newcomer, or maybe a fork of uv.
uv is very forkable - dual-licensed under Apache and MIT, high quality codebase, it's Rust rather than Python but the Python community has an increasing amount of Rust experience these days.
That's why I'm not personally too nervous about the strategic risk to the Python community of having such a significant piece of the ecosystem from a relatively young VC-backed company.
Honestly, given the constant rollercoaster of version management and building tools for Python the move to something else would be expected rather than surprising.
I’ve seems like a great tool, but I remember thinking the same about piping, too.
I also tried it and am now using it for new projects. But I was just fine with Poetry too. Yes, uv is faster and probably better code. But my use-cases didn't necessitate to re-create the venvs frequently, so the slowness of Poetry didn't matter that much to me, and I am not using the "one-off script" kind of approaches that uv enables (writing the dependencies in a comment in the script itself).
So, yeah, uv is nice, but for me didn't fundamentally change that much.
Our entire business runs on Python without a drop of Astral in the mix. No one would even notice.
Honestly, that is an understatement. `uv run` has transformed how I use Python since 99% of the time I don't need to setup or manage an environment and dependencies. A have tons of one-off Python scripts (with their dependencies in PEP 723 metadata at the top of the file) that just work with `uv run`.
I get how it might not be as useful in a production deployment where the system/container will be setup just for that Python service, but for less structured use-cases, `uv` is a silver bullet.
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.
Wondering to what degree this was done to support Anthropic’s web crawler. Would assume that having a whole JS runtime rather than just a HTTP client could be rather useful. Just hypothesising here, no clue what they use for their crawler.
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.
What matters: it's staying open source and MIT licensed. I sincerely hope it stays that way. Congrats to the Bun team on making a great tool and getting the recognition they deserve.
> Being part of Anthropic gives Bun: Long-term stability.
Let's see. I don't want to always be the downer but the AI industry is in a state of rapid flux with some very strong economic headwinds. I wouldn't confidently say that hitching your wagon to AI gives you long term stability. But as long as the rest of us keep the ability to fork an open source project I won't complain too much.
(for those who are disappointed: this is why you stick with Node. Deno and Bun are both VC funded projects, there's only one way that goes. The only question is timeline)
> Node has much more likelihood of long term stability than Bun
Given how many more dependencies you need to build/maintain a Node app, your Bun application has a better chance of long term stability.
With Node almost everything is third party (db driver, S3, router, etc) and the vast majority of NPM deps have dozens if not hundreds of deps.
This reads more like Anthropic wanted to hire Jarred and Jarred wants to work with AI rather than build a Saas product around bun. I doubt it has anything to do with what is best for bun the project. Considering bun always seemed to value performance more than all else, the only real way for them to continue pursuing that value would be to move into the actual js engine design. This seems like a good pivot for Jarred personally and likely a loss for bun.
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.
I haven't had any issue moving projects between node, bun, and deno for years. I don't agree that the risk of bun failing as a company affects anthropic at all. Bun has a permissible license that anthropic could fork from, anthropic likely knew that oven had a long runway and isn't in immediate danger, and switching to a new js cli tool is not the huge lift most people think it is in 2025. Why pay for something you are already getting for free and can expect to keep getting for free for at least four years, and buy for less if it fails later?
A dependency that forms the foundation of your build process, distribution mechanisms, and management of other dependencies is a materially different risk than a dependency that, say, colorizes terminal output.
I’m doubtful that alone motivated an acquisition, it was surely a confluence of factors, but Bun is definitely a significant dependency for Claude Code.
If they found themselves pushing PRs to bun that got ignored and they wanted to speed up priority on things they needed, if the acq was cheap enough, this is the way to do it.
I'm also curious if Anthropic was worried about the funding situation for Bun. The easiest way to allay any concerns about longevity is to just acquire them outright.
It's not easy to "just" fork a huge project like Bun. You'll need to commit several devs to it, and they'll have to have Zig and JSC experience, a hard combo to hire for. In many ways, this is an acquihire.
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.
Godspeed. Seems like a good pairing. Bun is sort of the only part of the JS ecosystem I like, and Code has become such an important tool for my work, that I think good things will come out of this match. Go Bundler as well.
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.
JS/TS has a fundamental advantage, because there is more open source JS/TS than any other language, so LLMs training on JS/TS have more to work with. Combine that with having the largest developer community, which means you have more people using LLMs to write JS/TS than any other language, and people use it more because it works better, then the advantage compounds as you retrain on usage data.
If "AI tooling" makes developers more productive regardless of language, then it's still more productive to use a more productive language. If JS is more productive than C++, then "N% more productive JS" is still more productive than "N% more productive C++", for all positive N.
Bun has completely changed my outlook on the JS ecosystem. Prior to Bun, there was little focus on performance. Now the entire space rallies around it.
Congrats to Jarred and the team!
> 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.
> Vibe-coded projects get bought by vibe-coded companies
this is so far from the truth. Bun, Zig, and uWebsockets are passion projects run by individuals with deep systems programming expertise. furthest thing from vibe coding imaginable.
> a decade of performance competition in the JS VM space
this was a rising tide that lifted all boats, including Node, but Node is built with much more of the system implemented in JS, so it is architecturally incapable of the kind of performance Bun/uWebsockets achieves.
> Bun, Zig, and uWebsockets are passion projects run by individuals with deep systems programming expertise. furthest thing from vibe coding imaginable.
Sure, I definitely will not throw projects like Zig into that bucket, and I don't actually think Bun is vibe-coded. At least that _used_ to be true, we'll see I guess...
Don't read a snarky comment so literally ;)
> Node is built with much more of the system implemented in JS, so it is architecturally incapable of the kind of performance Bun/uWebsockets achieves
That sounds like an implementation difference, not an architectural difference. If they wanted to, what would prevent Node or a third party from implementing parts of the stdlib in a faster language?
That's because it's not written in JS at all but a compiled systems language, no wonder it's gonna be fast.
Virtually all JavaScript engines are written in compiled languages. (Most runtimes for that matter nut just JS)
My mistake, I was thinking of the wider ecosystem not the runtime, ie formatters, bundles and linters like Biome, oxc, etc being written in Rust or other compiled languages. That's where I saw the biggest speedup, because developers of them decided to use a compiled language to write them in instead of JS via a JS runtime where you'll inherently be limited by even a JIT language.
Machine code yes (along with Spidermonkey, JSC and Nashorn), the timeframe around 2005-2010 saw the introduction of JIT'ed JS runtimes. Back then however JS was firmly single-threaded, it was only with the introduction of SharedArrayBuffer that JS really started to receive multithreading features (outside of SharedArrayBuffer and other shareable/sendable types, a runtime could opt to run stuff like WebWorkers/WebAudioWorkers in separate processes).
Early Node f.ex. had a multi-process setup built in, Node initially was about pushing the async-IO model together with a fast JS runtime.
Why Bun (and partially Deno) exists is because TypeScript helps so damn much once projects gets a tad larger, but usage with Node hot-reloading was kinda slow, multiple seconds from saving a file until your application reloads. Even mainline node nowadays has direct .ts file loading and type erasing to quicken the workflow.
> Prior to Bun, there was little focus on performance
v8 is one of the most advanced JIT runtimes in the world. A lot of people have spent a lot of time focusing on its performance.
I'm sure the Bun team will get Claude Code straightened out. Weird acquisition, but TBH Anthropic needed to fill this hole.
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.
So, we can anticipate that the new Anthropic browser will now have the interpreter Ken Thompson previewed for us 41-odd years ago?
on the post they try to reassure the following question "If I bet my work project or company's tech stack on Bun, will it still be around in five or ten years?" and the thing is that we don't know if Anthropic itself will be around 5 to ten years
My long-term bet on Node being "boring" and "stable" continues to pay major dividends. So glad I never invested any time and effort on this ecosystem…
Sounds like the goal is to bundle up Bun with Claude Code insanely tightly, to the point where it doesn't matter if you have nodejs installed locally, but also they can optimize key things for Claude Code's Bun runtime as needed. It's a brilliant acquisition, and bun stays open source, which allows it to continue to grow, to Anthropics benefit and everyone else's.
I just ln bun to npm, npx, and node. This has the added benefit of letting ts_ls and various other tools work without requiring me to have both node and bun installed locally.
Yeah Claude is very good, but it definitely needs to get "smarter" in some nuanced areas.
Congratulations to Jared. He and the team are Real Ziggers. Looking forward to a faster Claude Code!
Congrats Jarred and team! You have saved humanity many hours already, and I'm sure with Anthropic's backing, you will spare us many more. Farewell would-be headaches from Node & NPM tooling and waiting for builds and tests and package updates. Exciting times ahead!
Using bun on a side project reinvigorated my love of software development during a relatively dark time in my life, and part of me wonders if I would have taken the leap onto my current path if it weren't for the joy and feeling of speed that came from working with bun!
No strategic roadmap is ever going to tell you: "Build a $0-revenue JavaScript runtime and one day an AI company will acquire you"
Ha, Physics majors get the same talk about law school. It's just the selection bias of selecting for people willing to make hard pivots filtering out the under-achieving, go-with-the-flow types.
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
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.
Well, that was the playbook in the 1999-2001 dotcom days.
Which is probably why no one's going to recommend it these days
...but hey, things are different during a bubble.
Shouts out to the fellow who half-broke the news in this submission that was presumably killed because of the aggressive paywall: https://news.ycombinator.com/item?id=46123627
And apparently the submission's source for being the only org I can tell that anticipated this: https://www.theinformation.com/articles/anthropic-advanced-t...
This announcement made me check in on the arbitrary code execution bug I reported that the Bun Claude bot created a PR for about 3 weeks ago:
https://github.com/oven-sh/bun/pull/24578
So far, someone from the bun team has left a bunch of comments like
> Poor quality code
...and all the tests still seem to be failing. I looked through the code that the bot had generated and to me (who to be fair is not familiar with the bun codebase) it looks like total dogshit.
But hey, maybe it'll get there eventually. I don't envy "taylordotfish" and the other bot-herders working at Oven though, and I hope they get a nice payout as part of this sale.
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?
The OP directly says:
> that the Bun Claude bot created a PR for about 3 weeks ago
The PR with bad code that's also been ignored was made by the bot that Bun made, and brags about in their acquisition post.
> 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?
...Did you miss the part where Bun used Claude to generate that PR?:)
I misinterpreted that first comment too. To clarify:
1. User krig reports an issue against the Bun repo: https://github.com/oven-sh/bun/issues/24548
2. Bun's own automated "bunbot" filed a PR with a potential fix: https://github.com/oven-sh/bun/pull/24578
3. taylordotfish (not an employee of Bun as far as I can tell, but quite an active contributor to their repo) left a code review pointing out many flaws: https://github.com/oven-sh/bun/pull/24578#pullrequestreview-...
Bun is such a great runtime. If you haven't tried it, try it. It's got bells and whistles.
This will make sure Bun is around for many, many, years to come. Thanks Anthropic.
Why Bun?
Easy to setup and go. bun run <something.ts>
Bells and whistles. (SQL, Router, SPA, JSX, Bundling, Binaries, Streams, Sockets, S3)
Typescript Supported. (No need to tsc, bun can transpile for you)
Binary builds. (single executables for easy deployment)
Full Node.js Support. (The whole API)
Full NPM Support. (All the packages)
Native modules. (90% and getting better thanks to Zig's interop)
S3 File / SQL Builtin. (Blazingly Fast!)
You should try it. Yes, others do these things too, but we're talking about Bun.
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.
Not saying it’s 100%, there’s still the repl missing but all of node’s API is available in the sense that it’s ABI compatible (or will be very near term).
I’ve never understood the security utility of the Deno flags. What practical attack would they protect you from? Supply chain seems to be the idea, but how many npm packages do people use that neither:
* Get run by devs with filesystem permissions
* Get bundled into production
Maybe now Claude will not assume that I use npm, and actually start using bun?
Incredible news on so, so many levels!
(1) Bun is what technical startups should be. Consistently excellent decisions, hyper focused on user experience, and a truly excellent technical product.
(2) We live in a world where TUIs are causing billion dollar acquisitions. Think about that. Obviously, Bun itself is largely orthogonal to the TUIs. Just another use case. But also obviously, they wouldn't have been acquired like this without this use case.
(3) There's been questions of whether startups like Bun can exist. How will they make money? When will they have to sell out one of the three principles in (1) to do so? The answer seems to be that they don't; at least, not like we expected, and in my opinion not in a sinister way.
A sinister or corrupting sell out would be e.g. like Conan. What started as an excellent tool became a bloated, versioned mess as they were forced to implement features to support the corporate customers that sustained them.
This feels different. Of course, there will be some selling out. But largely the interests of Anthropic seem aligned with "build the best JS runtime", since Anthropic themselves must be laser focused on user experience with Claude Code. And just look at Opencode [^1] if you want to see what leaning all the way into Bun gets you. Single file binary distribution, absurdly fast, gorgeous. Their backend, OpenTUI [^2], is a large part of this, and was built in close correspondence with the Bun folks. It's not something that could exist without Bun, in my opinion.
(4) Anthropic could have certainly let Bun be a third party to which they contributed. They did not have to purchase them. But they did. There is a strange not-quite altruism in this; at worst, a casting off of the exploitation of open source we often see from the biggest companies. Things change; what seems almost altruistic now could be revealed to be sinister, or could morph into such. But for now, at least, it feels good and right.
[^1]: https://github.com/sst/opencode [^2]: https://github.com/sst/opentui
Hahaha congratulations. This is amazing. The most unlikely outcome for a devtools team. Fascinating stuff.
This is promising for Astral et al who I really like but worried about their sustainability. It does point to being as close to the user as possible mattering.
Is Claude Code the first CLI tool to have a $1BN ARR?
Man, I had never even put words to that problem but you are right that it is beyond annoying. It seems to me like it worsens the longer the Claude instance has run - I don't seem to see it early in the session.
ha I thought it was just a me thing and had have accepted my fate.
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:...
It doesn't make a lot of sense that they'll compare Microsoft 365 Copilot with Claude Code, though? Like it is a legit CLI tool but we should ignore it because it shares the name with something else?
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.
Associated Anthropic post: https://www.anthropic.com/news/anthropic-acquires-bun-as-cla...
Can anyone provide some color around this: "I started porting esbuild's JSX & TypeScript transpiler from Go to Zig"? Hypothetical benefits include monolanguage for development, better interoperability with C and C++, no garbage collection, and better performance. What turned out to be realized and relevant here? Please, no speculation or language flames or wars.
Interesting. Looking through a strategic lens, I feel like this is related to the $1,000 free credit for Claude Code Web (I used a few hundred). What the heck are they aiming for? CodeAct? (https://arxiv.org/abs/2402.01030)
Curious, how did he pay the bills when spending these years developing Bun?
Good luck, always worried about stuff like that because it happened so many times and the product got worse eventually. At the same time, ai understand how much effort went into building something like Bun and people need to fund their life's somehow, so there's that.
video covering it
In other news - Amp Code is a separate company now - https://ampcode.com/news/amp-inc
First major success story for Zig language? (Not trying to diminish Bun's team success)
Well this just created a lot of work for me. Everything’s turning to shit at an alarming rate.
Congrats...
> Long-term stability. a home and resources so people can safely bet their stack on Bun.
Isn't it the opposite? Now we've tied Bun to "AI" and if the AI bubble or hype or whatever bursts or dies down it'd impact Bun.
> We had over 4 years of runway to figure out monetization. We didn't have to join Anthropic.
There's honestly a higher chance of Bun sticking out that runway than the current AI hype still being around.
Nothing against Anthropic but with the circular financing, all the debt, OpenAI's spending and over-valuations "AI" is the riskier bet than Bun and hosting.
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.
How so? Presumably Jarred got a nice enough payout that if Anthropic failed, he would not need to work. At that point, he's more than welcome to take the fully MIT licensed Bun and fork it to start another company or just continue to work on it himself if he so chooses.
History?
I didn’t say it was definitely the end or definitely would end up worse, just that someone who’s followed tech news for a while is unlikely to take this as increasing the odds Bun survives mid-term. If the company was in trouble anyway, sure, maybe, but not if they still had fourish years in the bank.
“Acquired product thriving four years later” isn’t unheard of, but it’s not what you expect. The norm is the product’s dead or stagnant and dying by then.
> At that point, he's more than welcome to take the fully MIT licensed Bun and fork it to start another company or just continue to work on it himself if he so chooses.
Is there any historical precedent of someone doing that?
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
> I say don't muddy the water with the public panic over "will it won't it" bubble burst predictions.
It does matter. The public ultimately determines how much they get in funding if at all.
> The effective demand for Opus 4.5 is bottomless; the models will only get better.
The demand for the Internet is bottomless. Doesn't mean Dotcom didn't crash.
There are lots of scenarios this can play out, e.g. Anthropic fails to raise a certain round because money dried up. OpenAI buys Anthropic but decides they don't need Bun and closes out the project.
If claude code starts having ads for bun in the code it generates, I am never using it again.
To some degree have “opinionated views on tech stacks” is unavoidable in LLMs, but this seems like it moves us towards a horrible future.
Imagine if claude (or gemini) let you as a business pay to “prefer” certain tech in generated code?
Its google ads all over again.
The thing is, if they own bun, and they want people to use bun, how can they justify not preferencing it on the server side?
…and once one team does it… game on!
It just seems like a sucky future, that is now going to be unavoidable.
Not to be confused with Bunn [1], the coffee maker makers.
[1] www.bunn.com
It's the Anthropic careers page that you're likely looking for now:
Is it just me or does this page keep jumping back to the top when I try to scroll?
Why the hell is a CLI coding agent built in JavaScript?
It’s wild what happens when a generation of programmers doesn’t know anything except webdev. How far from grace we have fallen.
Ehhhh. In either case you have to define a neat clean plugin API. Whether it loads a DLL/SO or just some scripts isn’t that huge of a difference.
anthropic wont win, and will just get bought out by an ibm or oracle in the end...time to migrate from bun now
Look Bun is a great product but something hilarious about the company that is “going to replace all software developers with AI” BUYING software. You are building a product that is supposed to make software cost 0 right? Why wouldn’t you just “vibe” code yourself Bun?