Bun v0.2.0 | Hacker News Reader

Bun v0.2.0

github.com

133 pointschristophilus58 comments

Open articleView on HN

Deno introduced a new HTTP engine in 1.25 which apparently improved perf 3-4x.

https://deno.com/blog/v1.25#new-experimental-http-server-api

I guess this is not being used here?

Edit:

In fact in the HTTP benchmarks Deno seems to be much faster than Bun.

https://deno.land/benchmarks#http-server-throughput

That new HTTP server (Deno.serve) is being used

Bun’s http server is single-threaded, single-process right now. I think it’s really important to get single-threaded performance right before concurrency. Bun will eventually support builtin clustering/concurrency but it doesn’t yet

So Deno benchmark says deno is faster and bun says bun is faster?

Thats why I hate benchmark by package author/publisher.

If you want to see which one is faster (kind of pointless since both bun and deno/flash are not production ready) test your own application, and not an "hello world" or a specific workload that has been optimized to win a specific benchmark.

Deno is not production ready?

The new fast webserver (flash) is still --unstable, hence not production ready. It has a performance comparable to nodejs+uWebSockets.js and bun (that should be using under the hood a slighly modified version of uWebSockets).

edit: as a silly point of reference, an hello world that writes the same headers and the same body on a 2016 intel macbookpro is able to serve 125k rps in bun, 145k rps in deno/flash and 140k rps in nodejs+uws.

The version of that graph in the readme links to `bun/bench/react-hello-world` [0] which makes use of `react-dom/server` so it is a slightly more involved test than sending plain `hello world`

On a local 4 core VM, generating the load locally:

Deno.serve() appears to be particularly bad for me at this test until you crank up the concurrent connections (>500) it gets up to 2k rps but it also falls over after that load.

The `react-hello-world.node.js` server in node peaks at about 1.5k rps @ 32 connection

Bun running react-hello-world.jsx gets 8k rps with 32 connections. This uses a customised local copy of `react-dom/server` where [1] at least the `escapeHTML` function is switched for bun's native implementation, and this appears to be packaged (or will be?) with bun [2]. I'm not sure if anything else is different here as the bun packaged code is still minified. The `bench/snippets/react-dom-render.bun.js` [3] test comparing these only show the bun version of `react-dom/server` to be 1.5 - 2x faster on this VM so it appears there is something more to it. Maybe everything `react-dom/server` normally stresses is optimised in bun? or `escapeHTML` is very large on the flamegraph.

Running the react-hello-world.node.js server in bun results in about 1.9k rps @ 32 connection

Running react-hello-world.deno.jsx in bun doesn't work.

Futzing with react-hello-world.deno.jsx to load the cjs react builds will run in bun at about 1.9k rps

0: https://github.com/oven-sh/bun/tree/bun-v0.2.0/bench/react-h...

1: https://github.com/oven-sh/bun/blob/bun-v0.2.0/test/bun.js/r...

2: https://github.com/oven-sh/bun/blob/bun-v0.2.0/bench/react-h...

3: https://github.com/oven-sh/bun/blob/bun-v0.2.0/bench/snippet...

Attempt at a summary: Bun is a Node.js/Deno alternative that uses WebKit's JavaScript engine instead of V8. Bun is about 4X faster than those runtimes.

> Bun is about 4X faster than those runtimes.

Lies, damned lies, and benchmarks.

https://github.com/denosaurs/bench

I have no skin in the game, but to be fair Bun's chart was pretty clearly labeled "HTTP requests per second". I'm glad you posted this too — seems like a great resource!

That is what the benchmark linked to does test, http requests and with the new Deno.serve.

https://github.com/denosaurs/bench

and is written in Zig.

Happy to answer any questions about Bun

Do you have any stats or profiling info on the binary lockfile? JSON gets parsed so fast (GBs in a second?) that intuitively it doesn't seem to me like it would be a bottleneck, especially if you have the flexibility to change the representation. I know `package-lock.json` is especially verbose, but e.g., Elixir's `mix.lock` is pretty trim, and still human-readable.

If it really is a problem, then a binary lockfile might be worth it, but it's a pretty substantial hit to developer experience, I think. At least, I'm accustomed to checking the lockfile diff on PRs, and it's a shame to lose that.

Haven't experimented enough with text-based lockfile formats. It's worth trying.

To make serialization fast though, it would still need to do structure of arrays instead of an array of structures. Instead of each package being an object in the lockfile, arrays of package names, of version numbers, etc. it would need a tool to understand it

Just curious why Zig was chosen compared to the other languages out there for high performance computing like Go, Rust, Nim etc. Was it just because you were familiar with Zig or were there deeper reasons related to the programming language?

I have seen several others remark that when you really need to squeeze performance Zig does better.

Currently writing a small Zig project, I can totally see that. Although frankly I will probably stick to Go. Zig is a lot more work in my view as it os very low level. However that is also what helps you squeeze out performance.

With Zig you really get a fine grained control of memory management and it is a lot easier to push anything you can to be computed at compile time rather than runtime.

I’m very productive in Zig. I had trouble being productive in other languages while also writing performant code

Of the languages you mentioned, Go and Nim both have runtimes, for a product focused on performance above all else, that is just asking to leave performance on the table.

As for Rust and Zig, IMHO, programming in Zig is more fun, so if I was OP, I'd also have gone for Zig.

The nim runtime overhead is very small. In my tests it was very easy to out perform the latest Node and Java runtimes with shorter, and still type safe, code.

It is _really_ small, especially if you're using the ARC.

I have some criticism for the language itself around personal preferences, such as "concepts need to be finished ASAP", "don't depend on libc" (Zig is doing a much better job here) and some syntax pet-peeves.

Nim needs to be more popular IMO. Well, the same goes for D too. Sigh.

I would have used Nim for just about everything, had there been:

1. Support for cyclic imports 2. Official WASM support. I know nlvm exists. But those are two separate runtimes to be managed for long time.

I believe cyclic imports are coming. And Nim does supports wasm...you can target it with `--cpu:wasm32`. You most likely want to pair that with emscripten as in https://github.com/treeform/nim_emscripten_tutorial

Yeah. checked out wasm part. But man. I am not going to go into Nim without cyclic imports.

I was writing a compiler I remember where I hit the 5k LOC mark in Nim. And then the errors and stuff. It was a terrible experience putting all the types into one file, the functions into others etc etc. The DevExp is bad that way.

Other than that, I don't see much issues with Nim to be fair. Its quite a good language that ticks all boxes

I want to use D for a new company idea I have. The library situation just isn't there though, which is always the problem.

Its interoperability with C and C++ is top notch, if you're willing to work with libraries in those languages.

That's what I've been hearing.

Some problems are - vibe.d does not look nearly as performant or supported as, say, Drogon, which is what I was seriously considering using (I love the idea of using C++ with modern move semantics and coroutines to make async code easy).

I know and love Java and Node a lot - just want to try not using a VM for a bit :)

New to Bun. Bun is about ~4x faster than Node.

How much of this is due to Zig, vs using Webkit instead of v8?

Heya, love the project and was very excited when I first tried it for the speed and simplicity. Glad you got funded!

Please take a look at #1169. This stopped me, and the issue got a couple agreements. Also asked around on Discord to no avail. I see you have #156, which seems to indicate you're able to bundle, just not optimally for prod. But it's not clear to me how to generate a bundle.js for a main entrypoint.

Maybe just a doc issue? Running ./node_modules.bun gets a loadable module, but unclear where to go from there and it's not drop-in compatible with my esbuild process.

Heard back from Jared on their Discord.. indeed, it's not bundling yet.

https://github.com/oven-sh/bun/issues/1169

Is there any plans for simplifying the build process (currently it is a 1700 soc big makefile) so that it is easier to package in different formats/platforms?

Have you experienced any pain points from using zig? I've heard a lot of good things about the language and am curious about it's down sides.

Zig is great. The editor tooling could use some more work but I think after their new stage2 compiler is more ready, it sounds like they’ll invest more into that.

When is "child_process" implementation expected to be released?

next week

Are there any plans for releasing a native Windows executable?

Yes, though timeline not clear right now. We (https://oven.sh) are hiring engineers and this is one of the first large projects

Any plans on a Bun competitor to Deno's edge functions?

I wouldn’t phrase it as a competitor but Bun will ship hosting & deployment

https://oven.sh

It appears to be in the works: https://oven.sh

What do you think just-js does well, and doesn’t do well?

I don’t really have opinions about just-js. I enjoyed their blog post about optimizing Postgres though

How does this compare to Vite?

Any plan to support musl ?

There have been musl builds of Bun before but there were a couple subtle bugs regarding thread spawning. I’m also not sure about posix_spawn implementation - would need to read up on that

As a 'drop in' replacement for Node, bun has a long way to go, there's many gaps and incompatibilities.

If need to change my existing code, I might as well switch over to a much more mature runtime like Deno

Didn't bun/oven recently get into hot water for explicitly recruiting for employees willing to work unpaid overtime and invest founder-level passion into the project without anywhere near comparable compensation/ownership and then making a big stink when former employees of similar bootstrapped tech startups called them out for it?

I was pretty excited when I saw the initial release but that entire ordeal torpedoed my interest. If you're a startup and looking for someone to dedicate their life to you, you're looking for a co-founder, not a salaried employee. We've seen what happens to infrastructure startups with zealous employees with npm Inc, we don't need a repeat of that.

EDIT: I was trying to find the original tweets by the company but it looks like there are only quote-retweets talking about it left as the originals have been deleted.

Yeah, completely killed my interest in the project. That “you work yourself into poor health so we get rich” attitude is toxic and has killed too many otherwise promising projects because it’s unsustainable.

Well, I am not huge fan of the hustle culture either but its technically not "unpaid overtime" if the expectations around how much time commitment is expected is made known upfront along with the salary.

It could have been much worse if these expectations were found out after joining.

This is what I have been saying. Amazon makes people work 8-12 hours a day here in India and its not even talked about.

And this is not actually known before joining. At least bun says that outright.

Some people actually don't mind working hard unlike others if things are interesting. Not everyone is the same. There is certainly more fun working on bun out in the open than solving some random bug in Netflix, Amazon without even being noticed. And with forewarned warning.

Bun is amazing. Super early with some quirks but I use it whenever I can. So much nicer than the alternatives even with the early buggy bits.

Can Bun be built with musl instead of glibc. How many third party libaries do we need to install to compile Bun from scratch.

I get this error:

    ./build.zig:254:17: error: no member named 'isAARCH64' in enum 'std.target.Arch'
            if (arch.isAARCH64()) {
                    ^
    /usr/lib/zig/std/special/build_runner.zig:170:24: note: referenced here
            .ErrorUnion => try root.build(builder),
                           ^
    make: *** [Makefile:1010: dev-obj] Error 1

You will need the version of Zig used by Bun. It’s a few months old, just before LLVM 13 -> 14 migration

https://github.com/oven-sh/zig

It can be built, but you will also need to compile JSC from bun’s WebKit repo https://GitHub.com/oven-sh/WebKit

why should it? glibc is better in almost any measure over musl

Except being able to statically link.

Still breaks on most common libraries. No child_process implementation yet.

Which libraries break and why? (child-process?)

child_process is coming soon: https://twitter.com/jarredsumner/status/1579898972650381312

Reply on news.ycombinator.com