Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • I'm just patiently waiting for Bun to lose momentum and for Node to pick up the best ideas from Bun. Takes a couple of years usually, but saves me two migrations.
  • Amazing job to the team! We already tried it out and got -50% CPU and -60% Mem usage! https://scrydon.com/insights/2026/08/21/bun-1-4-at-scrydon/
  • Same team. Best part was how boring it was! Numbers are staging, equal windows, two RCs rather than one isolated variable - but every Bun service dropped in resource use!
  • Hate to comment more on the drama, but it's only after watching Andrew Kelley's talk at Software Should Work [1] that I realized how philosophically different he is from Jarred and the broader SF AI/VC sphere. Here he is in a conference talking about agency, enshittification, and learning to deprogram from a deeply religious background and then using that experience of internal questioning to define his relationship with computers.

    And somehow, the programming language he made (that currently bans AI contributions outright) ended up being instrumental for a tool that's in the center of the whole craze, and doing Tony Hawk 900 aerial spins with agentic AI software rewrites under a frontier lab. I'm not commenting on the effectiveness of the rewrite, but it seems fascinating that for a moment Zig found itself at the intersection of two very different camps that the software world seems to be divided into. It seems in retrospect like a bomb waiting to go off even if they didn't jump ship to Rust!

    [1] https://www.youtube.com/watch?v=zLZwpH5lCD4

  • A text version, for anyone else who dislikes video:

    https://andrewkelley.me/post/dont-take-black-pill.html

  • For me, notably absent from the release changelog and accompanying YouTube video they were excited to trumpet in the blog back in July, and the claim (still) this took 11 days. It's August 20th.
  • Weird there's no information about that here.

    But if they went down in cpu usage and memory usage, removed a memory leak, and are MORE compliant with nodejs... it sounds like a MASSIVE success?

  • Yes, I'm fine with the AI rewrite, just don't claim it was done in 11 days when it actually took ~50.
  • I like how the "over 10 MB smaller" is dubbed, sure the video was recorded some time ago and that number changed.

    https://youtu.be/i38DgEuaJwM?si=6oKAysKoRDPCihsL&t=176

  • > Bun is not 100% compatible with Node.js yet. In practice, much of the existing JavaScript ecosystem just works.

    I don't care about 100% compatibility. NodeJS is a standard but dead to me.

    I rather have faster feedback loop and less development/build/test time than worrying about Node.JS compatibility.

    Bun is the answer for my flow.

    ---

    Bun might as well promote itself as the total replacement of Node.JS, and I will still hop in.

  • Yeah, I'm more interested in them covering the majority of people's needs and use cases than I guess having a hundred percent compatibility with libraries I'll never use.

    I'd much rather it be a focus that I could run bun in serverless, sandbox, wasm, or workerd-like environments for agentic workflows where bun is the runtime to power additional functionality for AI agents.

    I assume this is why Anthropic purchased them beyond just a PR stunt and where the project is going.

  • Announcing that the SSR memory leak is gone as part of a product launch is wild.
    by mpeg
  • If it was one memory leak, it would be meh in the fix list, but the fact they've announced that they've eliminated all memory leaks because of Rust in about eleven days that's what's wild to me.

    We are living in a new world when it comes in how software is prompted into existence.

  • I recently pivoted to Rust for the backend development, after getting tired of the nodejs ecosystem fragmentation and how fragile things feel. Bun seems very interesting since it allows you to do so many things without pulling in 3rd party libraries and bundlers? Is anybody using it instead of nodejs? how's the experience so far? I might have to give it a try.

    Yes, I know there's probably better options than Rust for building APIs, but I wanted to learn it, so why not?

  • I always use Rust. You've made the right choice.
  • I use it heavily for personal use and find it works very well and lets me ship small applications quickly. I still use rust and other languages too as appropriate.
  • I'm using it, though I'm leery of how the project is run. It's been great, to be honest. I have been able to build very low-dependency projects quite quickly. Bun's documentation is decent, and its underlying features are performant.
  • The most appealing thing of Go to me is the good batteries including tooling. I don't use it much outside of little personal projects where I really don't want to deal with dependencies and want a small binary.
  • This was an incredible demo for Claude. The runtime hosted Claude Code for months and I never saw the slightest issue. Wholly machine ported. Truly amazing.
  • And all the vibe code tests were against Claude? Let's port the Linux kernel and run all tests against a single application only!
  • > The runtime hosted Claude Code for months and I never saw the slightest issue.

    but did others?

  • We're never going to know how much it cost and how many hours of engineering time it took behind the scenes.
  • It's weird their promotional video repeats "you can do <million things> without installing dependencies", if I want headless browser testing is that wrong to install a project that offers that?

    Why would I want everything reimplemented in this massive binary? Why would Bun be anymore in touch with nuances of all these different technologies then individual projects dedicated to their own speciality?

    JS Runtime, Package Manager, Test Runner (both unit and headless browser), Bundler, JSX, PosgreSQL/MySQL/SQLite drivers, S3 client, Redis client, Formatter, Linter, etc.

    Not to mention parsers for YAML, TOML, Markdown which are easily three separate projects worth of complexity in their own right.

    I guess one clear downside is to get all these great features they're pushing for 1.4 you needed to wait until everything was ready. Given 1.3 was pushed out in October 2025, a 10 month release cycle across so many large technologies is tough. Before you give a pass because of the Rust rewrite Bun 1.2 was released in January 2025

    I have to respect Jarred knows how to work the algorithm, 10 carefully crafted X teaser posts for this release spaced out over 72 hours https://xcancel.com/jarredsumner

  • Out of the things you mentioned I think the following make totally sense to be included in a language runtime like this:

    JavaScript runtime (obviously), package manager, test runner for unit tests, bundler, JSX, SQLite bindings, formatter, linter, YAML and TOML parsers. Maaaaybe even a Markdown parser and HTML5 parser. Definitely JSON, CSV and XML parsers.

    I.e. similar to Python. Though Python is a bit of an incoherent mess. If you have all these you need them to be coherent.

  • Some of these are situational, but many are expectations of a modern platform.

    Take Python - the standard lib now has things like a toml parser, sqlite client.

    And while I avoid the entire JS ecosystem as much as possible, a simple search to find a good Postgres client was not elucidating.

    https://wiki.postgresql.org/wiki/List_of_drivers two options - with node-postgres / pg seeming to be the most supported or postgres.js which has more abstractions but is less active

    Contrast that to the question for Java, where it's clear the official JDBC driver is the best option.

  • Ideally everything not built specifically for any given project is part of the OS or some other battle tested, supported system package.

    For example, I might well choose to reimplement eg a subset of TOML parsing to avoid the dependency risk.

    I don’t write JavaScript/TypeScript, but if I did, I’d find Bun’s “batteries included” approach compelling, at least to the extent I decide I can trust Bun, after due diligence

  • Some of these feel like solved problems effectively, so having them in the standard library is nice (at the expense of keeping these forever for backwards compatibility once a new tech replaces it). I do think having a larger standard library for common things (like golang) is the way to go. If a dependency seems to basically be installed by default everywhere, maybe it should go in the standard library.
  • It's faster to have it in the runtime in native code.

    You have more options, not less, you can still use the external dependencies.

  • > It's weird their promotional video repeats "you can do <million things> without installing dependencies",

    A couple years ago a common complaint was that the JavaScript ecosystem relied too heavily on dependencies for everything. Remember the left-pad incident where the developer deleted the popular dependency out of protest for reasons I can even remember? Or when colors.js was sabotaged to break everything that depended on it? The node-ipc package was sabotaged to delete files on developer’s machines. Then we had a wave of supply chain attacks that tried to insert malware into build scripts of popular dependencies.

    So the ecosystem started moving toward more batteries-included style development in response.

  • Its strange how flip floppy the JS ecosystem is, because go back literally 1-3 years or so and the BIGGEST complaint was the lack of a standard library and having to use a package for everything.

    But now that Bun is actually doing it its somehow bad? Its also still open source, so those implementations you mention need dedicated teams can still get the attention they need by the community if needed.

    I'm on the side that I'd actually prefer if node included more out of the box and we could drastically cut down on the number of packages we need due to the amount of supply chain attacks that happen on packages in the node ecosystem.