Bun Blog

Apparently Claude Code being built on Bun was considered a good enough reason? But it looks more strategic for Bun since they’re VC-backed and get a good exit:

> Claude Code ships as a Bun executable to millions of users. If Bun breaks, Claude Code breaks. Anthropic has direct incentive to keep Bun excellent.

…

> Bun's single-file executables turned out to be perfect for distributing CLI tools. You can compile any JavaScript project into a self-contained binary—runs anywhere, even if the user doesn't have Bun or Node installed. Works with native addons. Fast startup. Easy to distribute.

> Claude Code, FactoryAI, OpenCode, and others are all built with Bun.

…

> Over the last several months, the GitHub username with the most merged PRs in Bun's repo is now a Claude Code bot. We have it set up in our internal Discord and we mostly use it to help fix bugs. It opens PRs with tests that fail in the earlier system-installed version of Bun before the fix and pass in the fixed debug build of Bun. It responds to review comments. It does the whole thing.

> This feels approximately a few months ahead of where things are going. Certainly not years.

…

> We've been prioritizing issues from the Claude Code team for several months now. I have so many ideas all the time and it's really fun. Many of these ideas also help other AI coding products.

…

> Instead of putting our users & community through "Bun, the VC-backed startups tries to figure out monetization" – thanks to Anthropic,…

Hah! Do you have a running search giving you alerts when lmdb is mentioned or something?

> How is doxygen a disaster?

I've just never read any good, user friendly documentation ever produced by doxygen. Even when I used it myself. It always comes out looking like a pig's breakfast.

Like, take the lmdb docs. And I'm sorry for picking on it. But its a good example, because you've clearly put effort into using doxygen to document lmdb. I think the lmdb docs are about the best that doxygen generated documentation gets.

Looking at this page: http://www.lmdb.tech/doc/group__mdb.html

There's a bunch of concepts here:

- Environment (mdb_env)

- Database and database (dbi)

- Transaction

- Cursor

- Record

- Key

But none of those concepts are defined or explained. They're simply referenced without explanation in a big jumble of function names and descriptions, leaving me to figure out how they're supposed to work together. Maybe if those data types were defined up the top of the page? No. Doxygen tries to put some data structures at the top of the page - but for some reason the only documented types are MDB_val, MDB_stat and MDB_envinfo. All terrible places to start reading if you want to understand how to use lmdb.

Good documentation would lead with some front matter like:

- What does the library do

- How does the library sees the world. Here, explain the above concepts and how they relate. (Eg an environment represents a set of files on disk. Each environment contains a…

> I don't believe the LLM port makes the full transition any easier than doing things the old fashioned way: a dual lang code base like Linux

...

how so?

let's say Linus opens a branch, rust-temp, and in 2 weeks pushes ~15 million lines of code deleting most of the old C code. and then it gets merged in a few weeks. and then there's still a few months of the "merge window" and RC process. and each day folks report bugs, and automatic fuzzers make sure that both versions "behave the same".

I was pretty skeptical (still am), but what the Bun team did is pretty great so far.

https://bun.com/blog/bun-in-rust details the process, we see the results (Node.js compat [0], more than 3 thousand of issues fixed since since 1.3 [1], more than 900 issues fixed in ~24 hours [2], and it's live/in-prod [3])

> 50 dynamic workflows in Claude Code run continuously over the course of 11 days.

so let's say 500 workflows could do something similar for the kernel. the reported cost is 165K USD, so let's say this would cost 1.65M USD, plus CI costs [4] (which is ~200K/year for bun, so let's say it's 2M USD for the kernel)

How much the world is spending on kernel bug bounties and various security programs each year?

The bar is not perfect. The bar is something better.

[0] https://xcancel.com/bunjavascript/status/2087436767054213517#m

[1] https://xcancel.com/bunjavascript/status/2082298681223680002#m

[2] https://xcancel.com/bunjavascript/status/2080882189663907859#m

[3]…

Hi! I'm a maintainer of Elysia, the framework you claim to have outperformed.

First of all, I admire you for taking the hard way of learning to build your own stuff, especially at your age.

However, I have a concern to believe that the benchmark result is a false positive, and inaccurate.

From my experience working and maintaining the Bun HTTP framework for 3 years since the first release of Bun 0.1.0. Bun.serve is extremely fast that autocannon (the benchmark tool you're using) cannot keep up with the performance, causing the report to be skewed from hitting the limit of the benchmark tool instead of an actual framework.

This is mentioned in Bun documentation. https://bun.com/docs/project/benchmarking#benchmarking-tools

- For load testing, you must use an HTTP benchmarking tool that is at least as fast as Bun.serve(), or your results will be skewed. Some popular Node.js-based benchmarking tools like autocannon are not fast enough.

It would be nice if you could update the benchmark with the tools that can report is faster than autocannon for the most accurate result.

Other than that, I'd say great job!

Bun has been nothing but amazing wins for me, and I really like what it enabled me to do. Two examples:

- I have a couple of projects that handle images. I was including Sharp, but since these are side projects in a small VM, often a redeploy that recompiled Sharp just crashed the full VM (out of memory). Bun includes Bun.Image[1] natively, which is built around Sharp's API, so swapping Sharp out was very easy, and now deploys are a breeze (and swapping it in would be just as easy).

- Bun's JSX support is a godsend. I've replaced almost all my side projects that were backend rendered from Pug, Handlebars, and other various templates I used to have to just pure JSX. Heck, this made it trivial to make a side projects where the Favicon was a dynamic SVG [2]

[1] https://bun.com/docs/runtime/image

[2] https://stocksreader.com/portfolio?%5Egspc=10&amzn=10&msft=12&tsla=8&v=15&ko=20&spcx=10&aapl=10&period=1M

You should give the article[0] a read.

"A large percentage of bugs from that list are use-after-free, double-free, and "forgot to free" in an error path. In safe Rust, these are compiler errors and RAII-like automatic cleanup with Drop. Compiler errors are a better feedback loop than a style guide."

"At the time of writing, about 4% of Bun's Rust code sits inside an unsafe block (~13,000 unsafe keywords across ~27,000 lines / ~780,000 lines), and 78% of those blocks are a single line — a pointer that came from C++, or one call into a C library. I expect this number to go down over time as we refactor from a faithful Zig port (which had no greppable unsafe keyword) to idiomatic Rust, but we are going to continue using C & C++ libraries like JavaScriptCore so it will always have more unsafe than pure Rust projects."

[0] https://bun.com/blog/bun-in-rust