Bun v1 | Hacker News Reader

Bun v1

bun.sh

92 pointsjohnny_reilly21 comments

I work on Bun. Bun v1 is not out yet - this blog post was not supposed to be public until it's ready

If the performance improvements are that extensive, it would be interesting to see how close JavaScript + bun would get us to Go or Java. It would be a game changer if that gap can be closed.

IME the average, unoptimized node.js server application already scales (performs) a lot better than the average Java server application just because node.js uses non-blocking by default io and an event loop architecture that works well for most applications.

Of course I imagine if the code is written with performance in mind, Java code can beat out node.js, but my experience is that out in the wild, most Java code is not particularly performant.

Just learn Go. Honestly it's pretty simple to pick up, especially now with the slices package. I can't imagine using a loosely typed language anymore, even with an IDE to baby me.

If I have bun on my computer, do I need node?

Things that people often seem to forget about when talking about Bun:

  * Written Zig, an unstable programming language
  * Segfaults and crashes are common
  * Doesn’t work on windows (edit: fixed in v1)
  * The web-server is based on uWS, a third-party dependency maintained by one person
  * Vendor-specific APIs like Bun.serve, Bun.file, etc. You can call Node APIs in Bun, but you cannot call Bun APIs in Node
  * Tries to be everything at once: a bundler, a compiler, a package manager, a runtime, a testing framework, etc. 
  * A VC-baked effort. If the funds run dry there is no Bun anymore

Pretty harsh take. The windows issue is a deal breaker true, but zig is a great language. One of the few languages that I would consider state of the art, favoring innovation instead of being a C copycat.

> For the first time, a native Bun build for Windows is available! Previously Windows users needed to use Windows Subsystem for Linux to use Bun. Not anymore.

In what sense are the Bun.* APIs "proprietary"? They're open source, no? If you want to port them to another language, it would be completely possible to.

>You can call JS in Bun, but you cannot call Bun APIs in JS

This is confusingly worded, and I didn't understand what you were trying to say before I watched the video announcement.

"Bun" is a runtime, "JS" is a language that's implemented by multiple runtimes (including Bun, npm, and browsers). It makes no sense to say "you can't call the Bun APIs in JS" because calling them in JS is the only way to do it in the first place.

What you seem to mean is "you can't call Bun APIs from other runtimes" which is... kind of obvious? And also kind of an empty complaint, since Bun is primarily an npm replacement, and npm does the same thing[1]

[1] https://nodejs.org/api/fs.html

> * Vendor-locked-in with proprietary APIs like Bun.serve, Bun.file, etc.

What does this mean? Every JS runtime (node, deno, bun etc.) has its own set of APIs and they are generally not cross-compatible. The code for all the Bun APIs is open source so I'm not sure what makes them proprietary.

> You can call JS in Bun, but you cannot call Bun APIs in JS

Bad use of terminology. JS is the language, JavaScript/ECMAScript, and every JS runtime (node, bun, deno etc.) is using it. So you definitely can call Bun APIs in JS.

The catch is that Node APIs are supported by Node, Deno and Bun. But not vice-versa, which makes them vendor-specific

That's not a big problem, e.g. if you are using a Bun API for speed or some other specific reason, you can always do:

    if (typeof Bun === "undefined") {
      // Node.js code
    } else {
      // Bun code
    }

If you are writing a lot of Bun-specific code, yeah that will only work on Bun ofc. But I like that now I can add some small snippets of bun-optimized code in my libraries.

Otherwise, normally you'd use ESM APIs > Node.js APIs > Bun APIs, like if you are hashing something, right?

For me, the most important missing part is the sandboxing.

Related ongoing thread:

Bun 1.0 announcement [video] - https://news.ycombinator.com/item?id=37422106 - Sept 2023 (56 comments)

The video: https://www.youtube.com/watch?v=BsnCpESUEqM

Very professional! Also answers my question - Bun works with Remix Run.

Although they stopped throwing the bun around halfway through only for it to appear again at the end :)

I've been very excited for Bun.

And while the premise is still great, the enthusiasm has waned a bit in recent months. A lot of the decision making process seems a bit arbitrary and off the cuff, at least as presented on Twitter. Could be a mischaracterization as I haven't followed the Github threads closely.

I also question the use of Zig for a project that's intended to replace node and be production ready. It may be fun to work with and something fresh/new, but taking something very unproven and in heavy development is not a way to inspire confidence among your potential adopters.

I hate the Rust meme as much as anybody else, but I really question why you wouldn't use it here. The author of Bun posts about tracking down memory leaks on the regular... which shouldn't even be a problem space a modern runtime deals with.

All that being said... I will definitely use Bun for CI/builds/local projects... much more hesitant to use it for a production/live service at this point

I have a similar opinion. Bun might "support" all the possible Node APIs, but they don't say anything about stability and correctness of the underlying implementation. So you might think it's time to switch until a library in your project uses a node module, that breaks your code in Bun

As of now, there is still no v1 build up on Github, although this was announced hours ago.

homebrew installs version 0.8.1.

`bun upgrade` Congrats! You're already on the latest version of bun (which is v0.8.1)

Hopefully it's quick to follow, and some just jumped on the publish post a bit early!

Let's give them some time.

Reply on news.ycombinator.com