Jarred · HackerLangs

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

Jarred

vor 20 Tagendiscuss

> new codebase doesn’t have any

Claude Code & Prisma use it as of last week.

Jarred

vor 20 Tagendiscuss

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.

Jarred

letzten Monatdiscuss

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.

Jarred

vor 2 Monatendiscuss

> the Rust, Anthropic-focused rewrite

Nope. That's 100% me.

Jarred

vor 2 Monatendiscuss

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

Jarred

vor 2 Monatendiscuss

almost

Jarred

vor 2 Monatendiscuss

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

Jarred

vor 2 Monatendiscuss

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

Jarred

vor 2 Monatendiscuss

> it's basically solving the ,,tests not pass'' problem by changing the tests themselves.

False.

0 test files were deleted. 0 pre-existing tests were skipped, todo’d, or had assertions removed. 5 new tests were added in test.skip/test.todo state to track known not-yet-fixed bugs in the port that lacked test coverage before.

The merge changed 28 test files in total.

+1,312 lines

−141 lines

Most of that +1,312 is new tests.

The depth-of-recursion tests for TOML/JSONC parsers went from 25_000 -> 200_000 because Rust’s smaller stack frames (LLVM lifetime annotations let the optimizer reuse stack slots) mean 25k levels no longer reaches the 18 MB stack on Windows.

Jarred

vor 2 Monatendiscuss

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.

Jarred

vor 2 Monatendiscuss

Bun’s patched Zig is on Zig 0.15.1

Jarred

vor 2 Monatendiscuss

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.

Jarred

vor 2 Monatendiscuss

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.

Jarred

vor 2 Monatendiscuss

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

Jarred

vor 3 Monatendiscuss

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

Jarred

vor 3 Monatendiscuss

> turns out for me, bun is not production ready

What issue did you run into?

Jarred

vor 3 Monatendiscuss

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.

Jarred

vor 5 Monatendiscuss

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

Jarred

vor 7 Monatendiscuss

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