Jarred

If you don't bundle certificates, users will report that your builtin https client doesn't work in production (usually in docker)

I haven’t downloaded the tarball to verify, but it looks like it was reverted prior to the GitHub release:

https://github.com/colinhacks/zod/commit/10dda3a3a4bc76ed0bf...

It spawns ephemeral EC2/Azure instances, which is a lot cheaper than the GitHub actions runners we used before that.

We shard to a lot of machines for tests and I’d be worried about running out if we used dedicated servers.

BuildKite is fine but I wouldn’t be that surprised if we move off of BuildKite to a custom thing at some point. Months ago, we switched from CMake to a handrolled typescript build system and it made our builds faster and simpler.

CI has always been expensive for Bun including before the acquisition. We build for [macOS, Linux, FreeBSD, Android, Windows] x [ARM64, x64] and then run tests on multiple Linux distros with multiple shards, multiple macOS versions and Windows for each architecture.

We recently started cross-compiling all the builds on Linux arm64 and that made it a little faster (I wrote a CLI tool to download the correct macOS headers for cross-compilation). We also have a daily cron job that asks claude to make the slowest tests faster while adding more assertions.

Claude Code is a large codebase and uses tons of Node’s features either directly or indirectly through dependencies. fetch(), node:http, node:tls, node:os, node:net, node:fs, AbortSignal, node:child_process, node:tty, node:process, node:http2, etc.

Does it print a bun.report link and can you paste it? I will investigate.

Bun’s Rust rewrite shipped in Claude Code over a month ago and barely anyone noticed. Claude Code is widely used. The Rust rewrite is going well overall.

In the Bun v1.4 video, I promised a certain number of newly passing Node.js tests were added to force us to improve compatibility, and that number is not true yet. The release is delayed until it is true. The PRs to make it true are up but not merged yet. Most likely next Tuesday we’ll do the release of 1.4.

Grouped and arena allocations work really well in Zig. For awhile, we tried to use this pattern almost everywhere in Bun but it gets really tricky when there’s some GC-managed memory and you want to free things incrementally to reduce RSS. Also, using arenas for arrays that grow wastes memory a lot since it keeps every previous version around (mimalloc arenas are slightly better for this)

Grouped allocations works especially well in parsers & ASTs where the lifetime is very bounded. Since the Rust rewrite, we still use arenas for Bun’s parsers and the bundler but not a ton elsewhere.

I have learned so much reading Andrew’s code and as I said in the original post: Bun would never have happened without Zig.

> The post claims they were fuzzing their Zig code, while during our calls the whole Bun team told us that they were not fuzzing anything. This appears to be an outright fabrication.

Fuzzilli integration: https://github.com/oven-sh/bun/pull/24826

Merged PRs fixing issues Fuzzilli found in Bun’s Zig code:

- https://github.com/oven-sh/bun/pull/28926

- https://github.com/oven-sh/bun/pull/28934

- https://github.com/oven-sh/bun/pull/29255

- https://github.com/oven-sh/bun/pull/29210

- https://github.com/oven-sh/bun/pull/29199

Searching “Fuzzilli” shows more PRs: https://github.com/search?q=repo%3Aoven-sh%2Fbun+is%3Apr+Fuz...

> new codebase doesn’t have any

No longer accurate. As of last week, Claude Code (an incredibly popular CLI tool) runs on Bun’s Rust rewrite.

I’m the author of this PR.

This PR is an implementation of the design from https://webkit.org/blog/7846/concurrent-javascript-it-can-wo.... I think it would be really cool if JavaScript had true shared object multi-threading without compromises (SharedArrayBuffer, postMessage are not that). If we had both threads and structs, it’s likely the TypeScript compiler would never have needed to be rewritten in Go.

The title should be changed to clarify that it’s a PR to Bun’s JavaScriptCore fork and not the upstream WebKit.

This PR is scarier to merge than Bun’s Rust rewrite PR. There are a good number of benchmarks/stress tests, unit tests, and also TSAN runs and security scanner runs, but this is a more complex change than the Rust rewrite (yes, really). I’m also worried about syncing with upstream - today the “fork” is mostly a bunch of patches, but with this PR, changes to the JIT need to be reviewed for behavior when multiple threads are in use. Our best bet for this to move forward is figuring out a way for some constrained version to be upstreamed into WebKit proper, if that makes sense and if they’re interested.

And yes, the PR description is entirely Claude.

Dynamic workflows, in my experience, make Claude more effective at complex long-running tasks. They help precisely with getting Claude to do the task correctly.

It feels more like a bespoke build system for the specific task/project than prompting a freeform chat.

> the Rust, Anthropic-focused rewrite

Nope. That's 100% me.

`PathString` worked the exact same way in our Zig code, with less visibility from the compiler & type system. And yes, it will be refactored heavily (or deleted overall) in the next week or so.

almost

> mostly a JavaScript interpreter wrapper

Not accurate. Bun is a batteries-included JavaScript & CSS transpiler (parser), minifier, bundler, npm-like package manager, Jest-like test runner, as well as runtime APIs like a builtin Postgres, MySQL and Redis client. This is naturally a ton of code.

That was me - not CI marking as slop. It kept around 60 .zig files around that should’ve been moved to .rs files.

Still writing the blog post about this. Will share more details.

For where this is coming from, skim the bugfixes in the Bun v1.3.14 and earlier release notes. Rust won’t catch all of these - leaks from holding references too long and anything that re-enters across the JS boundary are still on us. But a large % of that list is use-after-free, double-free, and forgot-to-free-on-error-path, which become compile errors or automatic cleanup.

Bun’s patched Zig is on Zig 0.15.1

cargo check reported over 16,000 compiler errors when I wrote that message. It could not print a version number or run JavaScript. I didn’t expect it to work this quickly and I also didn’t expect the performance to be as competitive. There’ll be a blog post with more details.

I work on Bun and this is my branch

This whole thread is an overreaction. 302 comments about code that does not work. We haven’t committed to rewriting. There’s a very high chance all this code gets thrown out completely.

I’m curious to see what a working version of this looks, what it feels like, how it performs and if/how hard it’d be to get it to pass Bun’s test suite and be maintainable. I’d like to be able to compare a viable Rust version and a Zig version side by side.

I work on Bun, and this post is confusing to me. Me personally and the Bun team continues to dogfood & make Bun better everyday. Our development pace has only gotten faster. Bun's stability has improved significantly since joining Anthropic.

Here are some things shipping in the next version of Bun:

- 17 MB smaller Windows x64 binaries [0]

- 8 MB smaller Linux binaries [1]

- `--no-orphans` CLI flag to recursively kill any lingering processes spawned [3]

- SSL context caching for client TCP & unix sockets, which significantly reduces memory usage for database clients like Mongoose/MongoDB [4]

- Experimental HTTP/3 & HTTP/2 client in fetch [5]

- Experimental HTTP/3 support in Bun.serve() [6]

- Bun.Image, a builtin image processing library [7]

(Along with several reliability improvements to node:fs, Worker, BroadcastChannel, and MessagePort)

The Anthropic acquisition also means Bun no longer needs to become a revenue-generating business. We are very incentivized to make Bun better because Claude Code depends on it, and so many software engineers depend on Claude Code to help get their work done.

[0]: https://github.com/oven-sh/bun/pull/30219

[1]: https://github.com/oven-sh/bun/pull/30098

[2]: https://github.com/oven-sh/WebKit/pull/211

[3]: https://github.com/oven-sh/bun/pull/29930

[4]: https://github.com/oven-sh/bun/pull/29932

[5]: https://github.com/oven-sh/bun/pull/29863

[6]: https://github.com/oven-sh/bun/pull/30032

From Amol, who is the Head of Growth:

> For clarity, we're running a small test on ~2% of new prosumer signups. Existing Pro and Max subscribers aren't affected.

https://x.com/TheAmolAvasare/status/2046724659039932830

> turns out for me, bun is not production ready

What issue did you run into?

I spent some time investigating this, and the issue is not accurate - Claude Code itself does not have code that spawns `git reset --hard origin/main`

Most likely, the developer ran `/loop 10m <prompt>` or asked claude to create a cron task that runs every 10 minutes and refreshes & resets git.

You can find a comparison with `bun build` on Bun's homepage. It hasn't been updated in a little while, but I haven't heard that the relative difference between Bun and Rolldown has changed much in the time since (both have gotten faster).

In text form:

Bundling 10,000 React components (Linux x64, Hetzner)

  Bundler                    Version                  Time
  ─────────────────────────────────────────────────────────
  Bun                        v1.3.0               269.1 ms
  Rolldown                   v1.0.0-beta.42       494.9 ms
  esbuild                    v0.25.10             571.9 ms
  Farm                       v1.0.5             1,608.0 ms
  Rspack                     v1.5.8             2,137.0 ms

I have a PR that’s been sitting for awhile that exposes the extra options from the renameat2 and renameatx_np syscalls which is a good way to implement self-updaters that work even when multiple processes are updating the same path on disk at the same time. These syscalls are supported on Linux & macOS but I don’t think there’s an equivalent on Windows. We use these syscalls internally for `bun install` to make adding packages into the global install cache work when multiple `bun install` processes are running simultaneously

No high-level self updater api is planned right now, but yes for at least the low level parts needed to make a good one

The reference docs are auto generated from node’s TypeScript types. node:vm is better than using the same global object to run untrusted code, but it’s not really a sandbox

Probably not. When we add new APIs in Bun, we generally base the interface off of popular existing packages. The bar is very high for a runtime to include libraries because the expectation is to support those APIs ~forever. And I can’t think of popular existing JS libraries for these things.

I work on Bun.

Happy to answer any questions