Bun v1

92 points by johnny_reilly 1 year ago | 21 comments
  • Jarred 1 year ago
    I work on Bun. Bun v1 is not out yet - this blog post was not supposed to be public until it's ready
    • sprkv5 1 year ago
      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.
      • jaredklewis 1 year ago
        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.

        • 38 1 year ago
          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.
        • fithisux 1 year ago
          If I have bun on my computer, do I need node?
        • ushakov 1 year ago
          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
          • LordDragonfang 1 year ago
            >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

            • 38 1 year ago
              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.
              • dsissitka 1 year ago
                > 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.
              • nufflee 1 year ago
                > * 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.

                • ushakov 1 year ago
                  The catch is that Node APIs are supported by Node, Deno and Bun. But not vice-versa, which makes them vendor-specific
                  • franciscop 1 year ago
                    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?

                • nightpool 1 year ago
                  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.
                  • tmikaeld 1 year ago
                    For me, the most important missing part is the sandboxing.
                  • dang 1 year ago
                    Related ongoing thread:

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

                  • adam_arthur 1 year ago
                    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

                    • ushakov 1 year ago
                      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
                    • ddoolin 1 year ago
                      As of now, there is still no v1 build up on Github, although this was announced hours ago.
                      • erksa 1 year 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!

                      • fithisux 1 year ago
                        Let's give them some time.