Associated Anthropic post: <a href="https:&#x2F;&#x2F;www.anthropic.com&#x2F;news&#x2F;anthropic-acquires-bun-as-claude-code-reaches-usd1b-milestone" rel="nofollow">https:&#x2F;&#x2F;www.anthropic.com&#x2F;news&#x2F;anthropic-acquires-bun-as-cla...</a>

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&#x27;t seem to see it early in the session.

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

&quot;GitHub Copilot&quot; encompasses so many different products now that it&#x27;s hard to see it as a CLI tool.

This graph from the SemiAnalysis blog suggests that GitHub Copilot reached it earlier this year: <a href="https:&#x2F;&#x2F;substackcdn.com&#x2F;image&#x2F;fetch&#x2F;$s_!BGEe!,f_auto,q_auto:good,fl_progressive:steep&#x2F;https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F118c4f46-97ed-4343-9e24-f90eae892038_1638x849.png" rel="nofollow">https:&#x2F;&#x2F;substackcdn.com&#x2F;image&#x2F;fetch&#x2F;$s_!BGEe!,f_auto,q_auto:...</a>

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&#x27;m sure it&#x27;s in the hundreds of millions. Then there&#x27;s git. Across the whole ecosystem, there&#x27;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&#x27;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.

Is Claude Code the first CLI tool to have a $1BN ARR?

Doesn’t sound crazy at all? My Max subscription costs me more than all the other netflix&#x2F;spotify etc combined, but I pay it happily, and spotify would go before Claude does.

I use Claude Code CLI daily - it&#x27;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.

&gt; I say don&#x27;t muddy the water with the public panic over &quot;will it won&#x27;t it&quot; bubble burst predictions.It does matter. The public ultimately determines how much they get in funding if at all.&gt; The effective demand for Opus 4.5 is bottomless; the models will only get better.The demand for the Internet is bottomless. Doesn&#x27;t mean Dotcom didn&#x27;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&#x27;t need Bun and closes out the project.

Opus 4.5 is not living in vacuum. It’s the most expensive of models for coders and there is Gemini 3 pro - with many discounts and deepseek 3.2 that is 50x cheaper and not much behind.

I say don&#x27;t muddy the water with the public panic over &quot;will it won&#x27;t it&quot; 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

How so? Presumably Jarred got a nice enough payout that if Anthropic failed, he would not need to work. At that point, he&#x27;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.

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.

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…

Congrats...&gt; Long-term stability. a home and resources so people can safely bet their stack on Bun.Isn&#x27;t it the opposite? Now we&#x27;ve tied Bun to &quot;AI&quot; and if the AI bubble or hype or whatever bursts or dies down it&#x27;d impact Bun.&gt; We had over 4 years of runway to figure out monetization. We didn&#x27;t have to join Anthropic.There&#x27;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&#x27;s spending and over-valuations &quot;AI&quot; is the riskier bet than Bun and hosting.

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.

The Bun team works hard, glad to see it pay off.

Oh no ... unfortunately this likely means a Bun.AI API in my JS runtime.

&gt; Nothing gives you long term stability in tech.Sure. But everything is relative. For instance, Node has much more likelihood of long term stability than Bun, given its ownership.

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

What matters: it&#x27;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.&gt; Being part of Anthropic gives Bun: Long-term stability.Let&#x27;s see. I don&#x27;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&#x27;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&#x27;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&#x27;s only one way that goes. The only question is timeline)

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.

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.

If you froze uv today it’ll take years for anything to get to a state where the switch would be worth it.

uv is very forkable - dual-licensed under Apache and MIT, high quality codebase, it&#x27;s Rust rather than Python but the Python community has an increasing amount of Rust experience these days.That&#x27;s why I&#x27;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.

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

you should try uv, really impressive tool

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

Finally, an event capable of killing the Python demon!

I don&#x27;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&#x27;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&#x27;s good, not because they&#x27;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.

Hope nobody buys Astral or Python is f*cked.

Congrats. This is the first time I remember reading a genuine, authentic story about a sale. Much preferred over “this is about continuing the mission until my earn-out is complete.”

No, they&#x27;re clearly acquiring the technology. They&#x27;re betting Claude Code on Bun, they have an invested interest in the health of Bun.

Looks like they are acquiring the team rather than the product

<pre><code> &quot;the full platform&quot;
</code></pre>
there are more languages than ts though?Acquisition of Apple Swift division incoming?

They will own it, and then what? Will Claude Code end every response with &quot;by the way, did you know that you can switch to bun for 21.37x faster builds?&quot;

Even outside of code development, Anthropic seems to be very strongly leaning into code interpreter over native tool calling for advancing agentic LLM abilities (e.g. their &quot;skills&quot; approach). Given that those necessitate a runtime of sorts, owning&#x2F;having access to a runtime like Bun that could e.g. allow them to very seamlessly integrate that functionality into their products better, this acquisition doesn&#x27;t seem like the worst idea.

It doesn&#x27;t make sense, and you definitely didn&#x27;t say why it&#x27;d make sense... but enough people are happy enough to see the Bun team reach an exit (especially one that doesn&#x27;t kill Bun) that I think the narrative that it makes sense will win out.I see it as two hairy things canceling out: the accelerating trend of the JS ecosystem being hostage to VCs and Rauch is nonsensical, but this time a nonsensical acquisition is closing the loop as neatly as possible.(actually this reminds me of Harry giving Dobby a sock: on so many levels!)

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&#x2F;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).

It certainly generated more revenue, so this is not surprising?

Claude Code has an annual run rate of $1bn. Bun currently has an annual run rate of $0.

No, just that people who borrowed bun 7 million dollars want some of it back...

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

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.

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.

I don&#x27;t really see how Bun fits as an acquisition for an AI company. This seems more like &quot;we have tons of capital and we want to buy something great&quot; than &quot;Bun is essential to our core business model&quot;.

Let&#x27;s not forget about TigerBeetle either. They weren&#x27;t bought (as far as I&#x27;m aware), but they seem to have some pretty good backing from customers.

I&#x27;d say Ghostty is a pretty big success story as well.

First major success story for Zig language? (Not trying to diminish Bun&#x27;s team success)

Makes sense, I had idea how else the investors would have made money on a javascript bundler&#x2F;jsc frontend

This somewhat answers the question of &quot;how on earth is a JS runtime company going to profit?&quot;

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

One option is that the current Bun shareholders didn&#x27;t see a profitable future and didn&#x27;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.

Curious about the deal value&#x2F;price — any clues whether it was just to make existing investors even (so say up to $30M) or are we talking some multiple? But if it&#x27;s a multiple, even 2x sounds a bit crazy.

Reminds me of Atlassian buying an AI browser.

I’m curious to what the acquisition price was. Bun said they’ve raised $26 million so I’m assuming the price tag has to be a lot higher than that for investors to agree to an acquisition.

You&#x27;re describing Node.js which has existed for the last 15 years

I&#x27;m still confused. Why not just pour a ton of resources into it since it&#x27;s open source. I guess dev mindshare? It is a great product

That doesn’t require or benefit from acquiring Bun. Node continues to exist and serve fine.

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&#x27;s acquisition of them make them better at what they were already doing?

Ok but node is even more stable and mature - compare node api parity in bun and also issue of bun vs node

Because they have a product that makes $1bn+ a year that depends on having a good, stable, cross-platform JS 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.

I&#x27;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&#x27;d be too risky to do unless they owned the runtime.

I don&#x27;t get it. Why would Anthropic need to own a JS runtime?

As far as I know, modern Node compat in Deno is also quite great - I just import packages via &#x27;npm:package&#x27; and they work, even install scripts work. Although I remember that in the past Deno&#x27;s Node compat was worse, yes.

Pretty sure one of the Deno day 1 goals was to correct mistakes made during the early days of Node.js.

It has wayyyyy better nodejs compatibility (day 1 goal)

pnpm does all that on top of node. Also disables postinstall scripts by default, making the recent security incidents we&#x27;ve seen a non-issue.

Deno does all that. Hell, yarn does too, or pnpm as the sibling mentioned.

IIRC bun zig code base has a lot of fine optimization too. I think the lead did a conference explaining his work. Or maybe i&#x27;m confused.

Deno does that. It also refrains from keeping a local node_modules at all until&#x2F;unless you explicitly ask it to for whatever compatibility reason. There are plugins to things like esbuild to use the Deno resolver and not need a node_modules at all (if you aren&#x27;t also using the Deno-provided bundler for whatever reason such as it disappeared for a couple versions and is still marked &quot;experimental&quot;).

I decided to stick with Node in general. I don&#x27;t see any compelling reason to change it.Faster install and less disk space due to hardlink? Not really all that important to me. Npm comes with a cache too, and I have the disk space. I don&#x27;t need it to be faster.With the old-school setup I can easily manually edit something in node_modules to quickly test a change.No more node_modules? It was a cool idea when yarn 2 initially implemented it, but at the end of the day I prefer things to just work rather than debug what is and isn&#x27;t broken by the new resolver. At the time my DevOps team also wasn&#x27;t too excited about me proposing to put the dependencies into git for the zero-install.

I haven&#x27;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&#x27;t know if Deno does that, but some googling for &quot;deno install performance vs npm install&quot; doesn&#x27;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&#x27;t make a noticeable difference, so I decided to stick with Node.

Twice as fast at executing JavaScript? There&#x27;s absolutely zero chance this is true. A JavaScript engine that&#x27;s twice as fast as V8 in general doesn&#x27;t exist. There may be 5 or 10 percent difference, but nothing really meaningful.

I&#x27;ve found it to be at least twice as fast with practically no compat issues.

Easily bundling and serving frontend code from your backend code is very appealing: <a href="https:&#x2F;&#x2F;bun.com&#x2F;docs&#x2F;bundler&#x2F;fullstack" rel="nofollow">https:&#x2F;&#x2F;bun.com&#x2F;docs&#x2F;bundler&#x2F;fullstack</a>Despite the page title being &quot;Fullstack dev server&quot;, it&#x27;s also useful in production (Ctrl-F &quot;Production Mode&quot;).

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

If you want to download open source libraries to be used in your Bun project then they will come from npm, at least by default. [1].So it seems odd to say that Bun is less dependent on the npm library ecosystem.[1] It’s possible to use jsr.io instead: <a href="https:&#x2F;&#x2F;jsr.io&#x2F;docs&#x2F;using-packages" rel="nofollow">https:&#x2F;&#x2F;jsr.io&#x2F;docs&#x2F;using-packages</a>

I always figured Bun was the &quot;enterprise software&quot; choice, where you&#x27;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&#x27;d still be at risk of NPM supply chain attacks which seems to be the greater concern for companies these days.

Good question, hard to say, but I think it&#x27;s mainly because of Zig. At its core Zig is marketed as a competitor to C, not C++&#x2F;Rust&#x2F;etc, which makes me think it&#x27;s harder to write working code that won&#x27;t leak or crash than in other languages. Zig embraces manual memory management as well.

I mean, they said they looked at the source code and thought it was gross, so there’s a justification for their concern, at least.

&gt; I&#x27;ll admit I&#x27;m somewhat biased against Bun?Why? Genuine question, sorry if it was said&#x2F;implied in your original message and I missed it.

This is a non sequitur. Both Rust and Zig and any other language has the ability to end in an exception state. Whether it be kernel exception, pointer exception, or Rust&#x27;s panic! - these things exist.The reason why you see so many GitHub issues about it is because that&#x27;s where the development is. Deno is great. Bun is great. These two things can both be great and we don&#x27;t have to choose sides. Deno has it&#x27;s use case. Bun has it&#x27;s. Deno want&#x27;s to be secure and require permissions. Bun just wants to make clean, simple, projects. This fight between Rust vs The World is getting old. Rust isn&#x27;t any &quot;safer&quot; when Deno can panic too.

I haven&#x27;t verified this, but I would be willing to bet that most of Bun&#x27;s issues here have more to do with interfacing with JavaScriptCore through the C FFI than Zig itself. this is as much a problem in Rust as it is in Zig. in fact, it has been argued that writing unsafe Zig is safer than writing unsafe Rust: <a href="https:&#x2F;&#x2F;zackoverflow.dev&#x2F;writing&#x2F;unsafe-rust-vs-zig&#x2F;" rel="nofollow">https:&#x2F;&#x2F;zackoverflow.dev&#x2F;writing&#x2F;unsafe-rust-vs-zig&#x2F;</a>

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

It&#x27;s interesting that people have directly opposite opinions on whether Deno or Bun are meant to be used with the existing ecosystem - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=46125049">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=46125049</a>

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] <a href="https:&#x2F;&#x2F;jsr.io&#x2F;" rel="nofollow">https:&#x2F;&#x2F;jsr.io&#x2F;</a>
[2] <a href="https:&#x2F;&#x2F;fresh.deno.dev&#x2F;" rel="nofollow">https:&#x2F;&#x2F;fresh.deno.dev&#x2F;</a>

Same. I had a little library I wrote to wrap indexedDB and deno wouldn&#x27;t even compile it because it referenced those browser apis. I&#x27;m sure it&#x27;s a simple flag or config file property, or x, or y, or z, but the simple fact is, bun didn&#x27;t fail to compile.Between that and the discord, I have gotten the distinct impression that deno is for &quot;server javascript&quot; first, rather than just &quot;javascript&quot; first. Which is understandable, but not very catering to me, a frontend-first dev.

It just works. Whatever JavaScript&#x2F;TypeScript file or dependencies I throw at it, it will run it without needing to figure out CJS or ESM, tsconfig, etc.I haven&#x27;t had that experience with deno (or node)

I find comments like this fascinating, because you&#x27;re implicitly evaluating a counterfactual where Bun was built with Rust (or some other &quot;interesting&quot; language). Maybe Bun would be better if it were built in Rust. But maybe it would have been slower (either at runtime or development speed) and not gotten far enough along to be acquired by one of the hottest companies in the world. There&#x27;s no way to know. Why did Anthropic choose Bun instead of Deno, if Deno is written in a better language?

Agreed, the language would be interesting during the 1990&#x27;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.

Isn’t because packages are one of the problems deno tried to fix?

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

Which makes sense given that a big impetus for Deno&#x27;s existence was the creator of Node&#x2F;Deno (Ryan Dahl) wanting to correct things he viewed as design mistakes in Node.

I tried several times to port Node projects to Deno. Each time compatibility had &quot;improved&quot; but I still didn&#x27;t have a working build after a few days of effort.I don&#x27;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.

&gt; is there anything that Bun does better?Telling prospective employees that if you&#x27;re not ready to work 60-hour weeks, then what the fuck are you doing here? for one.&gt; Zig does force some safety with ReleaseSafe IIRCwhich Bun doesn&#x27;t use, choosing to go with `ReleaseFast` instead.

I&#x27;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&#x27;s CDK has hardcoded references to various package manager&#x27;s lock files, and Bun wasn&#x27;t one of them<a href="https:&#x2F;&#x2F;github.com&#x2F;aws&#x2F;aws-cdk&#x2F;issues&#x2F;31753" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;aws&#x2F;aws-cdk&#x2F;issues&#x2F;31753</a>This wasn&#x27;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<a href="https:&#x2F;&#x2F;github.com&#x2F;aws&#x2F;aws-cdk&#x2F;issues&#x2F;33464" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;aws&#x2F;aws-cdk&#x2F;issues&#x2F;33464</a>but don&#x27;t let Amazon&#x27;s own incompetency be the confirmation bias you were looking for about using a different package manager in productionyou can use SST to deploy cloud resources on AWS and any cloud, and that package works with bun

&gt; 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&#x27;s more &quot;mature&quot; 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 &quot;less tested&quot; seems uncharitable and it is certainly used in plenty of &quot;real-world tasks&quot; daily in iOS and macOS.

The speed shows up for large projects. Especially if you end up with multiple node_modules directories in your dev sandbox.

Is it just me, but I don&#x27;t find npm that slow? Sure it&#x27;s not a speed demon, but I rarely need to do npm install anyways so it&#x27;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&#x27;t feel it gives me such a boost.

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

My team has been using it in prod for about a year now. There were some minor bugs in the runtime&#x27;s implementation of buffers in 1.22 (?), but that was about the only issue we ran into.The nice things:1. It&#x27;s fast.2. The standard library is great. (This may be less of an advantage over Deno.)3. There&#x27;s a ton of momentum behind it.4. It&#x27;s closer to Node.js than Deno is, at least last I tried. There were a bunch of little Node &lt;&gt; Deno papercuts. For example, Deno wanted .ts extensions on all imports.5. I don&#x27;t have to think about JSR.The warts:1. The package manager has some issues that make it hard for us to use. I&#x27;ve forgotten why now, but this in particular bit us in the ass: <a href="https:&#x2F;&#x2F;github.com&#x2F;oven-sh&#x2F;bun&#x2F;issues&#x2F;6608" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;oven-sh&#x2F;bun&#x2F;issues&#x2F;6608</a>. We use PNPM and are very happy with it, even if it&#x27;s not as fast as Bun&#x27;s package manager.Overall, Deno felt to me like they were building a parallel ecosystem that I don&#x27;t have a ton of conviction in, while Bun feels focused on meeting me where I am.

Looking at Bun&#x27;s website (the comparison table under &quot;What&#x27;s different about Bun?&quot;) and what people have said here, the only significant benefit of Bun over Node.js seems to be that it&#x27;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&#x27;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.

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&#x27;t have that problem.There&#x27;s certainly an argument to be made that, like any good tool, you have to learn Deno and can&#x27;t fall back on just reusing node knowledge, and I&#x27;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

At this stage I don&#x27;t think either is better over the other. Deno has inexplicable high memory usage issues in Linux containers. Bun more or less suffers from the same with an added dose of segfaults.1. <a href="https:&#x2F;&#x2F;github.com&#x2F;denoland&#x2F;deno&#x2F;issues?q=is%3Aissue%20state%3Aopen%20docker%20memory" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;denoland&#x2F;deno&#x2F;issues?q=is%3Aissue%20state...</a>
2. <a href="https:&#x2F;&#x2F;github.com&#x2F;oven-sh&#x2F;bun&#x2F;issues?q=is%3Aissue%20state%3Aopen%20docker%20memory" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;oven-sh&#x2F;bun&#x2F;issues?q=is%3Aissue%20state%3...</a>Node.js is a no-brainer for anyone shipping a TS&#x2F;JS backend. I&#x27;d rather deal with poor DX and slightly worse performance than risk fighting runtime related issues on deployment.Linux needs to be a first class citizen for any runtime&#x2F;langauge toolchain.

Crash. According to my experience trying it many times oves the past years.It feels like a very unfocused project, every few months they introduce a new feature that is to replace an entire class of tools, while the original promise of &quot;drop in Node replacement&quot; was never fulfilled (or at least, that was the vibe for the past years when I was still paying attention).We&#x27;ll see how this works out but speed + lack of scope never works out well in the long term.

As someone who have been using Deno for the last few years, is there anything that Bun does better? 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?). The last time I checked Bun&#x27;s source code, it was... quite messy and spaghetti-like, plus Zig doesn&#x27;t really offer many safety features, so it&#x27;s not that hard to write incorrect code. Zig does force some safety with ReleaseSafe IIRC, but it&#x27;s still not the same as even modern C++, let alone Rust.I&#x27;ll admit I&#x27;m somewhat biased against Bun, but I&#x27;m honestly interested in knowing why people prefer Bun over Deno.

Machine code yes (along with Spidermonkey, JSC and Nashorn), the timeframe around 2005-2010 saw the introduction of JIT&#x27;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&#x2F;sendable types, a runtime could opt to run stuff like WebWorkers&#x2F;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.

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&#x27;ve heard in 20 years. Chrome literally was launched on performance, for JS and beyond.The reality is that the insane &quot;JS ecosystem&quot; will rally around whatever is the latest hotness.

Virtually all JavaScript engines are written in compiled languages. (Most runtimes for that matter nut just JS)

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

&gt; Vibe-coded projects get bought by vibe-coded companiesthis 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.&gt; a decade of performance competition in the JS VM spacethis 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&#x2F;uWebsockets achieves.

This missed the mark - Bun optimized systems whose predecessors were often implemented as JS libraries with a high number of syscalls. V8 is super fast for web usecases but your typical webpack &#x2F; react compiler as implemented in JS had tons of unnecessary bottlenecks.

&gt; 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.&gt; 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.

&gt; Prior to Bun, there was little focus on performancev8 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.

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!

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.

Anthropic may be losing money, but a company with $7bn revenue run rate (<a href="https:&#x2F;&#x2F;www.anthropic.com&#x2F;news&#x2F;statement-dario-amodei-american-ai-leadership" rel="nofollow">https:&#x2F;&#x2F;www.anthropic.com&#x2F;news&#x2F;statement-dario-amodei-americ...</a>) is a whole lot healthier than a company with a revenue of 0.

Often it happens that VCs buy out companies from funds belonging to a fresh because the selling fund wants to show performance to their investors until &quot;the big one&quot;, or move cash one from wealthy pocket to another one.&quot;You buy me this, next time I save you on that&quot;, etc...&quot;Raised $19 million Series A led by Khosla Ventures + $7 million&quot;&quot;Today, Bun makes $0 in revenue.&quot;Everything is almost public domain (MIT) and can be forked without paying a single dollar.Questionable to claim that the technology is the real reason this was bought.

&gt; But how is another company that is also VC backed and losing money providing stability for Bun?Reminds me of when Tron, the crypto company, bought BitTorrent.

The real risk is not that Anthropic will run out of money, but that they will change their strategy to something that isn&#x27;t Bun-based, and supporting Bun won&#x27;t make sense for them any more.

I misread Amazon, implying that Amazon might buy Anthropic, and I think that&#x27;s what will end up happening.

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 &quot;why another JS runtime&quot; etc.If Bun embraces the sweet spot around edge computing, modern JS&#x2F;TS and AI services, I think their future ahead looks bright.Bun seems more alive than Deno, FWIW.

&gt; Anthropic is a registered public benefit corporationDoes that mean anything at all?OpenAI is a public benefit corporation.

One thing I like about this, despite it meaning Bun will be funded, is Anthropic is a registered public benefit corporation. While this doesn&#x27;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&#x27;s no longer valuable.

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…

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

I’ll be honest, while I have my doubts about the match of interests and cohesion between an AI company and a JS runtime company I have to say this is the single best acquisition announcement blog post I’ve seen in 20 years or so.Very direct, very plain and detailed. They cover all the bases about the why, the how, and what to expect. I really appreciate it.Best of luck to the team and hopefully the new home will support them well.

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.

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&#x27;t know why it&#x27;s even necessary for this.<a href="https:&#x2F;&#x2F;github.com&#x2F;atxtechbro&#x2F;test-ink-flickering" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;atxtechbro&#x2F;test-ink-flickering</a>Issue on Claude Code GitHub:<a href="https:&#x2F;&#x2F;github.com&#x2F;anthropics&#x2F;claude-code&#x2F;issues&#x2F;769" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;anthropics&#x2F;claude-code&#x2F;issues&#x2F;769</a>

I like JS for this use case, and React on web, but really not fond of the Ink usage. Idk if it&#x27;s Ink itself or the way it gets used, but somehow people are making CLIs that lag and waste terminal space now.

Ink (and modern alternatives) probably are the best TUI toolkit. If you want to write a UI that&#x27;s genuinely good, you need e.g. HTML, or some way to express divs and flex box. There isn&#x27;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&#x27;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 &#x2F; 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&#x27;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&#x27;t mature (as you said, scrollback, etc). But, given time and money, that&#x27;ll get sorted out. It&#x27;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&#x27;m pretty obsessed with Claude Code, but the actual app is so incredibly poorly engineered for something that doesn&#x27;t even do that much.Rust, Go, whatever -- writing a good TUI isn&#x27;t that hard of a problem. Buying an entire VC funded JS runtime company isn&#x27;t how you solve it.

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

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&#x27;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?

It&#x27;s more honest than the Replicate answer but I think inevitably if you can&#x27;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&#x27;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!

Well this just created a lot of work for me. Everything’s turning to shit at an alarming rate.

&gt;If most new code is going to be written, tested, and deployed by AI agentsThat perspective following “in two-three years” makes me shudder, honestly.

This is my fear. It&#x27;s one thing to lose a major sponsor. It&#x27;s another to get cut due to a focus on profitability later down the line.

At least Anthropic itself has the stated goal of creating ethical AI that benefits humanity. That’s more than can be said for any other AI companies. Time will tell though. Google‘s motto used to be “don’t be evil” and now it’s basically the opposite.

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

Maybe they were though. Maybe Anthropic just wanted to bring a key piece of the stack in-house.

Good for them, could be bad for actual users.

&gt; 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.

Can&#x27;t edit my comment anymore but Bun posted a pretty detailed explanation of their motivation here: <a href="https:&#x2F;&#x2F;bun.com&#x2F;blog&#x2F;bun-joins-anthropic" rel="nofollow">https:&#x2F;&#x2F;bun.com&#x2F;blog&#x2F;bun-joins-anthropic</a>Sounds like &quot;monetizing Bun is a distraction, so we&#x27;re letting a deep-pocketed buyer finance Bun moving forward&quot;.

<pre><code> &gt; They didn&#x27;t have to join, which means they got a solid valuation.
</code></pre>
This isn&#x27;t really true. It&#x27;s more about who wanted them to join. Maybe it was Anthropic who really wanted to take over Bun&#x2F;hire Jarred, or it was Jarred who got sick of Bun and wanted to work on AI.I don&#x27;t really know any details about this acquisition, and I assume it&#x27;s the former, but acquihires are also done for other reasons than &quot;it was the only way&quot;.

They had a second round that was $19m in late 2023. I don&#x27;t doubt for a second that they had a long runway given the small team.

Good thing they got acquired by a company that also has a snowballs chance in hell of ever paying back their investment

&gt; They didn&#x27;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&#x27;s a great seed round and it looks like they had plenty of traction. But it&#x27;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&#x27;m not mistaken, Confluent did the same thing?

Yep. Remember when &quot;Open&quot;AI took a bunch of grant money and then turned for-profit?And kept their fraudulent name.

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

&gt; Yeah, now they are part of Anthropic, who haven&#x27;t figured out monetization themselves.Anthropic are on track to reach $9BN in annualised revenue by the end of the year, and the six-month-old Claude Code already accounts for $1BN of that.

How is their Web app any different than any other AI? I feel like it’s on par with all of them. It works great for me. Although I mostly use Claude code.

Yeah, now they are part of Anthropic, who haven&#x27;t figured out monetization themselves. Shikes!I&#x27;m a user of Bun and an Anthropic customer. Claude Code is great and it&#x27;s definitely where their models shine. Outside of that Anthropic sucks,their apps and web are complete crap, borderline unusable and the models are just meh. I get it, CC&#x27;s head got probably a powerplay here given his department is towing the company and his secret sauce, according to marketing from Oven, was Bun. In fact VSCode&#x27;s claude backend is distributed in bun-compiled binary exe, and the guy is featured on the front page of the Bun website since at least a week or so. So they bought the kid the toy he asked for.Anthropic needs urgently, instead, to acquire a good team behind a good chatbot and make something minimally decent. Then make their models work for everything else as well as they do with code.

apart from the unfortunate typo, this is accurate.like when a political leader says they have full faith in one of their ministers, you know said minister will be gone by next week.

&quot;We were maybe gonna fuck ya, buy now we promise we wont&quot;

&gt; At the time of writing, Bun&#x27;s monthly downloads grew 25% last month (October, 2025), passing 7.2 million monthly downloads. We had over 4 years of runway to figure out monetization. We didn&#x27;t have to join Anthropic.I believe this completely. They didn&#x27;t have to join, which means they got a solid valuation.&gt; Instead of putting our users &amp; community through &quot;Bun, the VC-backed startups tries to figure out monetization&quot; – thanks to Anthropic, we can skip that chapter entirely and focus on building the best JavaScript tooling.I believe this a bit less. It&#x27;ll be nice to not have some weird monetization shoved into bun, but their focus will likely shift a bit.

they acquihired the team and derisked their investment in building claude code on top of bun. makes sense to me.moreover, now they can make investments in order to make it an an even more efficient and secure runtime for model workspaces.

What a trip. Love both, so all good I guess.

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

&gt; This acquisition makes no sense.except this sense:&gt; Investors must be happy because Bun never had to find out how to become profitable.

Hard to say it makes no sense when you don&#x27;t know how much they were acquired for. I would guess it is a trivial amount relative to Anthropic&#x27;s war chest.

This acquisition makes no sense.Investors must be happy because Bun never had to find out how to become profitable.

Because I avoid all major AI players with everything I got as all of them are thieves.

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&#x27;s somehow, so there&#x27;s that.

If Bun ends up at either IBM or Oracle, then it&#x27;s a pretty safe platform, it could stay around for 50 years.

anthropic wont win, and will just get bought out by an ibm or oracle in the end...time to migrate from bun now

JS&#x2F;TS has a fundamental advantage, because there is more open source JS&#x2F;TS than any other language, so LLMs training on JS&#x2F;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&#x2F;TS than any other language, and people use it more because it works better, then the advantage compounds as you retrain on usage data.

One would expect that &quot;AI tooling&quot; is there for rapid iteration and one can use it with performant languages. We already had &quot;rapid iteration&quot; with GC languages.

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.

Wouldn’t it make more sense to write the same functionality using a more performant, no-gc language? Aren’t competitors praised for their CLIs being faster for that reason?

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

It seems the default is node (despite the project docs saying to use bun and all example script documentation using bun). It will use bun if told, but there’s definitely nothing saying to use node and it uses that anyway.

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

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

I use bun in a project but Claude Code always uses node to run throwaway scripts. Maybe they can persuade it to use bun as part of this acquisition?

quite the uncharitable take.On the opposite spectrum it&#x27;s just that Claude and Bun are great technologies that joined forces.

it boils down to - we didn&#x27;t have full conviction that over the long run we will prove superior to node.js, however a.i company burning a lot of cash, has invested in us by basing their toolchain on us - so they have no option to acquire-hire us.

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&#x27;t have been acquired like this without this use case.(3) There&#x27;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&#x27;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 &quot;build the best JS runtime&quot;, 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&#x27;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]: <a href="https:&#x2F;&#x2F;github.com&#x2F;sst&#x2F;opencode" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;sst&#x2F;opencode</a>
[^2]: <a href="https:&#x2F;&#x2F;github.com&#x2F;sst&#x2F;opentui" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;sst&#x2F;opentui</a>

Is it just me or does this page keep jumping back to the top when I try to scroll?

It&#x27;s the Anthropic careers page that you&#x27;re likely looking for now:<a href="https:&#x2F;&#x2F;www.anthropic.com&#x2F;jobs?team=4050633008" rel="nofollow">https:&#x2F;&#x2F;www.anthropic.com&#x2F;jobs?team=4050633008</a>

Classic - brand new blog post:&gt; We’re hiring engineers.Careers page:&gt; Sorry, no job openings at the moment.

&gt; bought influence over Zig as a reactionElaborate? I believe Zig&#x27;s donors don&#x27;t get any influence and decision making power.

That would require them to hire&#x2F;buy Zig team. Which is not the case.

Jarred just tweeted a few days ago about how little influence over zig he has, funnily enough.<a href="https:&#x2F;&#x2F;x.com&#x2F;jarredsumner&#x2F;status&#x2F;1994950394955665486?s=20" rel="nofollow">https:&#x2F;&#x2F;x.com&#x2F;jarredsumner&#x2F;status&#x2F;1994950394955665486?s=20</a>

My first thought went to how openai used Rust to build their CLI tool and Anthropic&#x27;s CEO bought influence over Zig as a reaction.

Congrats Jarred and team! You have saved humanity many hours already, and I&#x27;m sure with Anthropic&#x27;s backing, you will spare us many more. Farewell would-be headaches from Node &amp; 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&#x27;t for the joy and feeling of speed that came from working with bun!

Yeah Claude is very good, but it definitely needs to get &quot;smarter&quot; in some nuanced areas.

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.

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

Sounds like the goal is to bundle up Bun with Claude Code insanely tightly, to the point where it doesn&#x27;t matter if you have nodejs installed locally, but also they can optimize key things for Claude Code&#x27;s Bun runtime as needed. It&#x27;s a brilliant acquisition, and bun stays open source, which allows it to continue to grow, to Anthropics benefit and everyone else&#x27;s.

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&#x27;ve improved it since.)

Probably about 95% of mine now. Much better than I could for the most part.

What languages and frameworks? What is the domain space you&#x27;re operating in? I use Cursor to help with some tasks, but mainly only use the autocomplete. It&#x27;s great; no complaints. I just don&#x27;t ever see being able to turn over anywhere close to 90% with the stuff we work on.

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.

Quote from the CEO of Anthropic in March 2025: 
&quot;I think we&#x27;ll be there in three to six months where AI is writing 90% of the code and then in 12 months we may be in a world where AI is writing essentially all of the code&quot;

Anthropic acquires Bun