5 ms·

As someone who have been using Deno for the last few years, is there anything that Bun does better? Bun seems to use a different runtime (JSC) which is less tes

by Tiberium 11mo ago

As someone who have been using Deno for the last few years, is there anything that Bun does better? Bun seems to use a different runtime (JSC) which is less tested than V8, which makes me assume it might perform worse in real-world tasks (maybe not anymore?). The last time I checked Bun's source code, it was... quite messy and spaghetti-like, plus Zig doesn't really offer many safety features, so it's not that hard to write incorrect code. Zig does force some safety with ReleaseSafe IIRC, but it's still not the same as even modern C++, let alone Rust. I'll admit I'm somewhat biased against Bun, but I'm honestly interested in knowing why people prefer Bun over Deno.

ecares 11mo ago
It has wayyyyy better nodejs compatibility (day 1 goal)
- Tiberium 11mo ago
  As far as I know, modern Node compat in Deno is also quite great - I just import packages via 'npm:package' and they work, even install scripts work. Although I remember that in the past Deno's Node compat was worse, yes.
- 0x457 11mo ago
  Pretty sure one of the Deno day 1 goals was to correct mistakes made during the early days of Node.js.
  - deleted 11mo ago
    [deleted]
TheFlyingFish 11mo ago
I haven't used Deno, but I do use Bun purely as a replacement for npm. It does the hard-linking thing that seems to be increasingly common for package managers these days (i.e. it populates your local node_modules with a bunch of hard links to its systemwide cache), which makes it vastly quicker and more disk-efficient than npm for most usage. Even with a cold cache, `bun install` with a large-ish dependency graph is significantly faster than `npm install` in my experience. I don't know if Deno does that, but some googling for "deno install performance vs npm install" doesn't turn up much, so I suspect not? As a runtime, though, I have no opinion. I did test it against Node, but for my use case (build tooling for web projects) it didn't make a noticeable difference, so I decided to stick with Node.
- homebrewer 11mo ago
  pnpm does all that on top of node. Also disables postinstall scripts by default, making the recent security incidents we've seen a non-issue.
  - antihero 11mo ago
    I’m not sure why but bun still feels snappier.
    - B56b 11mo ago
      This is why: https://bun.com/blog/behind-the-scenes-of-bun-install https://bun.com/blog/behind-the-scenes-of-bun-install
    - babyshake 11mo ago
      Aside from speed, what would the major selling points be on migrating from pnpm to bun?
  - daheza 11mo ago
    Are there any popular packages that require postinstall scripts that this hurts?
  - junon 11mo ago
    As the victim of the larger pre-Shai-Hulud attack, unfortunately the install script validation wouldn't have protected you. Also, if you already have an infected package on the whitelist, a new infection in the install script will still affect you.
  - replete 11mo ago
    A whitelist in package.json is only a partial assist
- satvikpendem 11mo ago
  Deno does all that. Hell, yarn does too, or pnpm as the sibling mentioned.
cesarvarela 11mo ago
I've found it to be at least twice as fast with practically no compat issues.
- smarnach 11mo ago
  Twice as fast at executing JavaScript? There's absolutely zero chance this is true. A JavaScript engine that's twice as fast as V8 in general doesn't exist. There may be 5 or 10 percent difference, but nothing really meaningful.
  - johnfn 11mo ago
    You might want to revise what you consider to be "absolutely zero chance". Bun has an insanely fast startup time, so it definitely can be true for small workloads. A classic example of this was on Bun's website for a while[1] - it was "Running 266 React SSR tests faster than Jest can print its version number". [1]: https://x.com/jarredsumner/status/1542824445810642946 https://x.com/jarredsumner/status/1542824445810642946
    - smarnach 11mo ago
      I only claimed there is absolutely zero chance that Bun is twice as fast at executing general JavaScript as Deno. The example doesn't give any insight into the relative speeds of Bun and Deno, as fast as I can tell.
      - johnfn 11mo ago
        johnfn@mac ~ % time deno eval 'console.log("hello world")' hello world deno eval 'console.log("hello world")' 0.04s user 0.02s system 87% cpu 0.074 total johnfn@mac ~ % time bun -e 'console.log("hello world")' hello world bun -e 'console.log("hello world")' 0.01s user 0.00s system 84% cpu 0.013 total That's about 560% faster. Yes, it's a microbenchmark. But you said "absolutely zero chance", not "a very small chance".
        11mo ago
FragenAntworten 11mo ago
Easily bundling and serving frontend code from your backend code is very appealing: https://bun.com/docs/bundler/fullstack https://bun.com/docs/bundler/fullstack Despite the page title being "Fullstack dev server", it's also useful in production (Ctrl-F "Production Mode").
gre 11mo ago
I had memory leaks in bun and not in deno or node for the same code. ymmv
kenhwang 11mo ago
I always figured Bun was the "enterprise software" choice, where you'd want to use Bun tools and libraries for everything and not need to bring in much from the broader NPM library ecosystem. Deno seems like the better replacement for Node, but it'd still be at risk of NPM supply chain attacks which seems to be the greater concern for companies these days.
- skybrian 11mo ago
  If you want to download open source libraries to be used in your Bun project then they will come from npm, at least by default. [1]. So it seems odd to say that Bun is less dependent on the npm library ecosystem. [1] It’s possible to use jsr.io instead: https://jsr.io/docs/using-packages https://jsr.io/docs/using-packages
  - kenhwang 11mo ago
    Yes, both can pull in open source libraries and I can't imagine either dropping that ability. Though they do seem to have different eagerness and competency on Node compatibility and Bun seems better on that front. From a long term design philosophy prospective, Bun seems to want to have a sufficiently large core and standard library where you won't need to pull in much from the outside. Code written for Node will run on Bun, but code using Bun specific features won't run on Node. It's the "embrace, extend, ..." approach. Deno seems much more focused on tooling instead of expanding core JS, and seems to draws the line at integrations. The philosophy seems to be more along the lines of having the tools be better about security when pulling in libraries instead of replacing the need for libraries. Deno also has it's own standard library, but it's just a library and that library can run on Node.
    - skybrian 11mo ago
      That’s true of some parts of Deno’s standard libraries, but major functionality like Deno.test and Deno.serve are Deno-specific API’s. Here are the Bun API’s: https://bun.com/docs/runtime/bun-apis https://bun.com/docs/runtime/bun-apis Here are the Deno API’s: https://docs.deno.com/api/deno/ https://docs.deno.com/api/deno/
gr4vityWall 11mo ago
> I'll admit I'm somewhat biased against Bun? Why? Genuine question, sorry if it was said/implied in your original message and I missed it.
- Tiberium 11mo ago
  Good question, hard to say, but I think it's mainly because of Zig. At its core Zig is marketed as a competitor to C, not C++/Rust/etc, which makes me think it's harder to write working code that won't leak or crash than in other languages. Zig embraces manual memory management as well.
  - ecshafer 11mo ago
    Rust is more of a competitor to C++ than C. Manual memory management is sometimes really helpful and necessary. Zig has a lot of safety features.
  - AndyKelley 11mo ago
    > At its core Zig is marketed as a competitor to C, not C++/Rust/etc What gives you this impression? I directly created Zig to replace C++. I used C++ before I wrote Zig. I wrote Zig originally in C++. I recently ported Chromaprint from C++ to Zig, with nice performance results. I constantly talk about how batching is superior to RAII. Everyone loves to parrot this "Zig is to C as Rust is to C++" nonsense. It's some kind of mind virus that spreads despite any factual basis. I don't mean to disparage you in particular, this is like the 1000th time I've seen this.
    - Aeolun 11mo ago
      I got to love that the author of the thing can show up and say “Why?! I never said any of that!” A lot of stuff related to older languages is lost in the sands of time, but the same thing isn’t true for current ones.
    - deleted 11mo ago
      [deleted]
    - 11mo ago
satvikpendem 11mo ago
Search for pointer exceptions or core dumps on Bun's GitHub issues and you'll see why people (should) use Deno over Bun, if only because Rust is a way more safe language than Zig.
- reactordev 11mo ago
  This is a non sequitur. Both Rust and Zig and any other language has the ability to end in an exception state. Whether it be kernel exception, pointer exception, or Rust's panic! - these things exist. The reason why you see so many GitHub issues about it is because that's where the development is. Deno is great. Bun is great. These two things can both be great and we don't have to choose sides. Deno has it's use case. Bun has it's. Deno want's to be secure and require permissions. Bun just wants to make clean, simple, projects. This fight between Rust vs The World is getting old. Rust isn't any "safer" when Deno can panic too.
  - skipants 11mo ago
    I agree. Pointing at Github issues is a strange metric to me. If we want to use that as a canary then you shouldn't use Deno (2.4k open issues) or Bun (4.5k open issues) at all.
  - satvikpendem 11mo ago
    Don't make a false equivalence, how many times does one get a panic from Deno versus a segmentation fault in Bun? It's not a similar number, and it's simply wrong to say that both are just as unsafe when that's plainly untrue.
    - ricardobeat 11mo ago
      Anecodtally? Zero segfaults with bun since I started using it back in beta.
      - satvikpendem 11mo ago
        I'm talking statistically in terms of number of issues that reference segmentation faults in the Bun vs Deno GitHub repositories. Anecdata doesn't mean much.
skybrian 11mo ago
I’ve been using Deno too. Although npm support has improved and it’s fine for me, I think Deno has more of a “rewrite the world” philosophy. For example, they created their own package registry [1] and their own web framework [2]. Bun seems much more focused on preexisting JavaScript projects. [1] https://jsr.io/ https://jsr.io/ [2] https://fresh.deno.dev/ https://fresh.deno.dev/
- Tiberium 11mo ago
  It's interesting that people have directly opposite opinions on whether Deno or Bun are meant to be used with the existing ecosystem - https://news.ycombinator.com/item?id=46125049 https://news.ycombinator.com/item?id=46125049
  - hardwaregeek 11mo ago
    I don’t think these are mutually exclusive takes. Bun is essentially taking Node and giving it a standard library and standard tooling. But you can still use regular node packages if you want. Whereas Deno def leaned into the clean break for a while
- wetpaws 11mo ago
  [dead]
bcye 11mo ago
It just works. Whatever JavaScript/TypeScript file or dependencies I throw at it, it will run it without needing to figure out CJS or ESM, tsconfig, etc. I haven't had that experience with deno (or node)
- catapart 11mo ago
  Same. I had a little library I wrote to wrap indexedDB and deno wouldn't even compile it because it referenced those browser apis. I'm sure it's a simple flag or config file property, or x, or y, or z, but the simple fact is, bun didn't fail to compile. Between that and the discord, I have gotten the distinct impression that deno is for "server javascript" first, rather than just "javascript" first. Which is understandable, but not very catering to me, a frontend-first dev.
  - bcye 11mo ago
    Even for server ~~java~~typescript, I almost always reach for Bun nowadays. Used to be because of typestripping, which node now has too, but it's very convenient to write a quick script, import libraries and not have to worry about what format they are in.
pjmlp 11mo ago
Agreed, the language would be interesting during the 1990's, nowadays not so much. The tools that the language offers to handle use after free is hardly any different from using Purify, Insure++ back in 2000.
- defen 11mo ago
  I find comments like this fascinating, because you're implicitly evaluating a counterfactual where Bun was built with Rust (or some other "interesting" language). Maybe Bun would be better if it were built in Rust. But maybe it would have been slower (either at runtime or development speed) and not gotten far enough along to be acquired by one of the hottest companies in the world. There's no way to know. Why did Anthropic choose Bun instead of Deno, if Deno is written in a better language?
  - pjmlp 11mo ago
    Because maybe they reached out to them, and they didn't took the money, while Bun folks business model wasn't working out? Who knows? Besides, how are they going to get back the money spent on the acquisition? Many times the answer to acquisitions has nothing to do with technology.
    - defen 11mo ago
      > Claude Code, FactoryAI, OpenCode, and others are all built with Bun. Anthropic chose to use Bun to build their tooling.
      - pjmlp 11mo ago
        We can think of they making bun an internal tool, push roadmap items that fit their internal products, whatever, which doesn't answer the getting back money of the acquisition. Profit in those products has to justify having now their own compiler team for a JavaScript runtime.
  - n42 11mo ago
    Don't engage with this guy, he shows up in every one of these threads to pattern match back to his heyday without considering any of the nuance of what is actually different this time.
silasdavis 11mo ago
Stopped following Deno while they were rejecting the need for a package management solution. Used Bun instead.
- croes 11mo ago
  Isn’t because packages are one of the problems deno tried to fix?
  - WorldMaker 11mo ago
    They tried to realign package management with web standards and tools that browsers can share (URLs and importmaps and "cache, don't install"). They didn't offer compatibility with existing package managers (notably and notoriously npm) until late in that game and took multiple swings at URL-based package repositories (deno.land/x/ and JSR), with JSR eventually realizing it needed stronger npm compatibility. Bun did prioritize npm compatibility earlier. Today though there seems to be a lot of parity, and I think things like JSR and strong importmaps support start to weigh in Deno's favor.
    - silasdavis 11mo ago
      Yeah it does look like things have moved on, but there were echoes from previous Go conversations around the idea of a standardised package and the attendant years of hurt that it turned me off a little while ago. I did try: https://github.com/denoland/deno/issues/4574#issuecomment-626755249 https://github.com/denoland/deno/issues/4574#issuecomment-62...
spiffytech 11mo ago
I tried several times to port Node projects to Deno. Each time compatibility had "improved" but I still didn't have a working build after a few days of effort. I don't know how Deno is today. I switched to Bun and porting went a lot smoother. Philosophically, I like that Bun sees Node compatibility as an obvious top priority. Deno sees it as a grudging necessity after losing the fight to do things differently.
- fastball 11mo ago
  Which makes sense given that a big impetus for Deno's existence was the creator of Node/Deno (Ryan Dahl) wanting to correct things he viewed as design mistakes in Node.
dmit 11mo ago
> is there anything that Bun does better? Telling prospective employees that if you're not ready to work 60-hour weeks, then what the fuck are you doing here? for one. > Zig does force some safety with ReleaseSafe IIRC which Bun doesn't use, choosing to go with `ReleaseFast` instead.
yieldcrv 11mo ago
I've been using Bun since 2022 just to be trendy for recruitment (it worked, and still works despite it almost being 2026) Bun is fast, and its worked as a drop in replacement for npm in large legacy projects too. I only ever encountered one issue, which was pretty dumb, Amazon's CDK has hardcoded references to various package manager's lock files, and Bun wasn't one of them https://github.com/aws/aws-cdk/issues/31753 https://github.com/aws/aws-cdk/issues/31753 This wasn't fixed till the end of 2024 and as you can see, only accidentally merged in but tolerated. It was promptly broken by a bun breaking change https://github.com/aws/aws-cdk/issues/33464 https://github.com/aws/aws-cdk/issues/33464 but don't let Amazon's own incompetency be the confirmation bias you were looking for about using a different package manager in production you can use SST to deploy cloud resources on AWS and any cloud, and that package works with bun
WorldMaker 11mo ago
> Bun seems to use a different runtime (JSC) which is less tested than V8, which makes me assume it might perform worse in real-world tasks (maybe not anymore?). JSC is still the JS engine for WebKit-based browsers, especially Safari, and per Apple App Store regulations the only JS engine supposedly allowable in all of iOS. It's more "mature" than V8 in terms of predating it. (V8 was not a fork of it and was started from scratch, but V8 was designed to replace it in the Blink fork from WebKit.) It has different performance goals and performance characteristics, but "less tested" seems uncharitable and it is certainly used in plenty of "real-world tasks" daily in iOS and macOS.
torginus 11mo ago
Is it just me, but I don't find npm that slow? Sure it's not a speed demon, but I rarely need to do npm install anyways so it's not a bottleneck for me. For deploy, usually running the attached terraform script takes more time. So while a speed increase is welcome, but I don't feel it gives me such a boost.
- hinkley 11mo ago
  The speed shows up for large projects. Especially if you end up with multiple node_modules directories in your dev sandbox.
dunham 11mo ago
Is JSC less tested? I thought it was used in Safari, which has some market share. I used bun briefly to run the output of my compiler, because it was the only javascript runtime that did tail calls. But I eventually added a tail call transform to my compiler and switched to node, which runs 40% faster for my test case (the compiler building itself).
kabirgoel 11mo ago
My team has been using it in prod for about a year now. There were some minor bugs in the runtime's implementation of buffers in 1.22 (?), but that was about the only issue we ran into. The nice things: 1. It's fast. 2. The standard library is great. (This may be less of an advantage over Deno.) 3. There's a ton of momentum behind it. 4. It's closer to Node.js than Deno is, at least last I tried. There were a bunch of little Node <> Deno papercuts. For example, Deno wanted .ts extensions on all imports. 5. I don't have to think about JSR. The warts: 1. The package manager has some issues that make it hard for us to use. I've forgotten why now, but this in particular bit us in the ass: https://github.com/oven-sh/bun/issues/6608 https://github.com/oven-sh/bun/issues/6608. We use PNPM and are very happy with it, even if it's not as fast as Bun's package manager. Overall, Deno felt to me like they were building a parallel ecosystem that I don't have a ton of conviction in, while Bun feels focused on meeting me where I am.
creata 11mo ago
Looking at Bun's website (the comparison table under "What's different about Bun?") and what people have said here, the only significant benefit of Bun over Node.js seems to be that it's more batteries-included - a bigger standard library, more tools, some convenience features like compiling JSX and stripping TypeScript types on-the-fly, etc. It's not clear to me why that requires creating a whole new runtime, or why they made the decisions they did, like choosing JSC instead of V8, or using a pre-1.0 language like Zig.
bodge5000 11mo ago
I really want to like Deno and will likely try it again, but last time I did it was just a bit of a pain anytime I wanted to use something built for npm (which is most packages out there), whereas bun didn't have that problem. There's certainly an argument to be made that, like any good tool, you have to learn Deno and can't fall back on just reusing node knowledge, and I'd absolutely agree with that, but in that case I wanted to learn the package, not the package manager. Edit: Also it has a nice standard library, not a huge win because that stuff is also doable in Deno, but again, its just a bit less painless
kamikazechaser 11mo ago
At this stage I don't think either is better over the other. Deno has inexplicable high memory usage issues in Linux containers. Bun more or less suffers from the same with an added dose of segfaults. 1. https://github.com/denoland/deno/issues?q=is%3Aissue%20state%3Aopen%20docker%20memory https://github.com/denoland/deno/issues?q=is%3Aissue%20state... 2. https://github.com/oven-sh/bun/issues?q=is%3Aissue%20state%3Aopen%20docker%20memory https://github.com/oven-sh/bun/issues?q=is%3Aissue%20state%3... Node.js is a no-brainer for anyone shipping a TS/JS backend. I'd rather deal with poor DX and slightly worse performance than risk fighting runtime related issues on deployment. Linux needs to be a first class citizen for any runtime/langauge toolchain.
Griffinsauce 11mo ago
Crash. According to my experience trying it many times oves the past years. It feels like a very unfocused project, every few months they introduce a new feature that is to replace an entire class of tools, while the original promise of "drop in Node replacement" was never fulfilled (or at least, that was the vibe for the past years when I was still paying attention). We'll see how this works out but speed + lack of scope never works out well in the long term.

ecares 11mo ago

It has wayyyyy better nodejs compatibility (day 1 goal)

Tiberium 11mo ago
As far as I know, modern Node compat in Deno is also quite great - I just import packages via 'npm:package' and they work, even install scripts work. Although I remember that in the past Deno's Node compat was worse, yes.
0x457 11mo ago
Pretty sure one of the Deno day 1 goals was to correct mistakes made during the early days of Node.js.
- deleted 11mo ago
  [deleted]

TheFlyingFish 11mo ago

I haven't used Deno, but I do use Bun purely as a replacement for npm. It does the hard-linking thing that seems to be increasingly common for package managers these days (i.e. it populates your local node_modules with a bunch of hard links to its systemwide cache), which makes it vastly quicker and more disk-efficient than npm for most usage. Even with a cold cache, `bun install` with a large-ish dependency graph is significantly faster than `npm install` in my experience. I don't know if Deno does that, but some googling for "deno install performance vs npm install" doesn't turn up much, so I suspect not? As a runtime, though, I have no opinion. I did test it against Node, but for my use case (build tooling for web projects) it didn't make a noticeable difference, so I decided to stick with Node.

homebrewer 11mo ago
pnpm does all that on top of node. Also disables postinstall scripts by default, making the recent security incidents we've seen a non-issue.
- antihero 11mo ago
  I’m not sure why but bun still feels snappier.
  - B56b 11mo ago
    This is why: https://bun.com/blog/behind-the-scenes-of-bun-install https://bun.com/blog/behind-the-scenes-of-bun-install
  - babyshake 11mo ago
    Aside from speed, what would the major selling points be on migrating from pnpm to bun?
- daheza 11mo ago
  Are there any popular packages that require postinstall scripts that this hurts?
- junon 11mo ago
  As the victim of the larger pre-Shai-Hulud attack, unfortunately the install script validation wouldn't have protected you. Also, if you already have an infected package on the whitelist, a new infection in the install script will still affect you.
- replete 11mo ago
  A whitelist in package.json is only a partial assist
satvikpendem 11mo ago
Deno does all that. Hell, yarn does too, or pnpm as the sibling mentioned.

cesarvarela 11mo ago

I've found it to be at least twice as fast with practically no compat issues.

smarnach 11mo ago
Twice as fast at executing JavaScript? There's absolutely zero chance this is true. A JavaScript engine that's twice as fast as V8 in general doesn't exist. There may be 5 or 10 percent difference, but nothing really meaningful.
- johnfn 11mo ago
  You might want to revise what you consider to be "absolutely zero chance". Bun has an insanely fast startup time, so it definitely can be true for small workloads. A classic example of this was on Bun's website for a while[1] - it was "Running 266 React SSR tests faster than Jest can print its version number". [1]: https://x.com/jarredsumner/status/1542824445810642946 https://x.com/jarredsumner/status/1542824445810642946
  - smarnach 11mo ago
    I only claimed there is absolutely zero chance that Bun is twice as fast at executing general JavaScript as Deno. The example doesn't give any insight into the relative speeds of Bun and Deno, as fast as I can tell.
    - johnfn 11mo ago
      johnfn@mac ~ % time deno eval 'console.log("hello world")' hello world deno eval 'console.log("hello world")' 0.04s user 0.02s system 87% cpu 0.074 total johnfn@mac ~ % time bun -e 'console.log("hello world")' hello world bun -e 'console.log("hello world")' 0.01s user 0.00s system 84% cpu 0.013 total That's about 560% faster. Yes, it's a microbenchmark. But you said "absolutely zero chance", not "a very small chance".
      - 11mo ago

FragenAntworten 11mo ago

Easily bundling and serving frontend code from your backend code is very appealing: https://bun.com/docs/bundler/fullstack https://bun.com/docs/bundler/fullstack Despite the page title being "Fullstack dev server", it's also useful in production (Ctrl-F "Production Mode").

gre 11mo ago

I had memory leaks in bun and not in deno or node for the same code. ymmv

kenhwang 11mo ago

I always figured Bun was the "enterprise software" choice, where you'd want to use Bun tools and libraries for everything and not need to bring in much from the broader NPM library ecosystem. Deno seems like the better replacement for Node, but it'd still be at risk of NPM supply chain attacks which seems to be the greater concern for companies these days.

skybrian 11mo ago
If you want to download open source libraries to be used in your Bun project then they will come from npm, at least by default. [1]. So it seems odd to say that Bun is less dependent on the npm library ecosystem. [1] It’s possible to use jsr.io instead: https://jsr.io/docs/using-packages https://jsr.io/docs/using-packages
- kenhwang 11mo ago
  Yes, both can pull in open source libraries and I can't imagine either dropping that ability. Though they do seem to have different eagerness and competency on Node compatibility and Bun seems better on that front. From a long term design philosophy prospective, Bun seems to want to have a sufficiently large core and standard library where you won't need to pull in much from the outside. Code written for Node will run on Bun, but code using Bun specific features won't run on Node. It's the "embrace, extend, ..." approach. Deno seems much more focused on tooling instead of expanding core JS, and seems to draws the line at integrations. The philosophy seems to be more along the lines of having the tools be better about security when pulling in libraries instead of replacing the need for libraries. Deno also has it's own standard library, but it's just a library and that library can run on Node.
  - skybrian 11mo ago
    That’s true of some parts of Deno’s standard libraries, but major functionality like Deno.test and Deno.serve are Deno-specific API’s. Here are the Bun API’s: https://bun.com/docs/runtime/bun-apis https://bun.com/docs/runtime/bun-apis Here are the Deno API’s: https://docs.deno.com/api/deno/ https://docs.deno.com/api/deno/

gr4vityWall 11mo ago

> I'll admit I'm somewhat biased against Bun? Why? Genuine question, sorry if it was said/implied in your original message and I missed it.

Tiberium 11mo ago
Good question, hard to say, but I think it's mainly because of Zig. At its core Zig is marketed as a competitor to C, not C++/Rust/etc, which makes me think it's harder to write working code that won't leak or crash than in other languages. Zig embraces manual memory management as well.
- ecshafer 11mo ago
  Rust is more of a competitor to C++ than C. Manual memory management is sometimes really helpful and necessary. Zig has a lot of safety features.
- AndyKelley 11mo ago
  > At its core Zig is marketed as a competitor to C, not C++/Rust/etc What gives you this impression? I directly created Zig to replace C++. I used C++ before I wrote Zig. I wrote Zig originally in C++. I recently ported Chromaprint from C++ to Zig, with nice performance results. I constantly talk about how batching is superior to RAII. Everyone loves to parrot this "Zig is to C as Rust is to C++" nonsense. It's some kind of mind virus that spreads despite any factual basis. I don't mean to disparage you in particular, this is like the 1000th time I've seen this.
  - Aeolun 11mo ago
    I got to love that the author of the thing can show up and say “Why?! I never said any of that!” A lot of stuff related to older languages is lost in the sands of time, but the same thing isn’t true for current ones.
  - deleted 11mo ago
    [deleted]
  - 11mo ago

satvikpendem 11mo ago

Search for pointer exceptions or core dumps on Bun's GitHub issues and you'll see why people (should) use Deno over Bun, if only because Rust is a way more safe language than Zig.

reactordev 11mo ago
This is a non sequitur. Both Rust and Zig and any other language has the ability to end in an exception state. Whether it be kernel exception, pointer exception, or Rust's panic! - these things exist. The reason why you see so many GitHub issues about it is because that's where the development is. Deno is great. Bun is great. These two things can both be great and we don't have to choose sides. Deno has it's use case. Bun has it's. Deno want's to be secure and require permissions. Bun just wants to make clean, simple, projects. This fight between Rust vs The World is getting old. Rust isn't any "safer" when Deno can panic too.
- skipants 11mo ago
  I agree. Pointing at Github issues is a strange metric to me. If we want to use that as a canary then you shouldn't use Deno (2.4k open issues) or Bun (4.5k open issues) at all.
- satvikpendem 11mo ago
  Don't make a false equivalence, how many times does one get a panic from Deno versus a segmentation fault in Bun? It's not a similar number, and it's simply wrong to say that both are just as unsafe when that's plainly untrue.
  - ricardobeat 11mo ago
    Anecodtally? Zero segfaults with bun since I started using it back in beta.
    - satvikpendem 11mo ago
      I'm talking statistically in terms of number of issues that reference segmentation faults in the Bun vs Deno GitHub repositories. Anecdata doesn't mean much.

skybrian 11mo ago

I’ve been using Deno too. Although npm support has improved and it’s fine for me, I think Deno has more of a “rewrite the world” philosophy. For example, they created their own package registry [1] and their own web framework [2]. Bun seems much more focused on preexisting JavaScript projects. [1] https://jsr.io/ https://jsr.io/ [2] https://fresh.deno.dev/ https://fresh.deno.dev/

Tiberium 11mo ago
It's interesting that people have directly opposite opinions on whether Deno or Bun are meant to be used with the existing ecosystem - https://news.ycombinator.com/item?id=46125049 https://news.ycombinator.com/item?id=46125049
- hardwaregeek 11mo ago
  I don’t think these are mutually exclusive takes. Bun is essentially taking Node and giving it a standard library and standard tooling. But you can still use regular node packages if you want. Whereas Deno def leaned into the clean break for a while
wetpaws 11mo ago
[dead]

bcye 11mo ago

It just works. Whatever JavaScript/TypeScript file or dependencies I throw at it, it will run it without needing to figure out CJS or ESM, tsconfig, etc. I haven't had that experience with deno (or node)

catapart 11mo ago
Same. I had a little library I wrote to wrap indexedDB and deno wouldn't even compile it because it referenced those browser apis. I'm sure it's a simple flag or config file property, or x, or y, or z, but the simple fact is, bun didn't fail to compile. Between that and the discord, I have gotten the distinct impression that deno is for "server javascript" first, rather than just "javascript" first. Which is understandable, but not very catering to me, a frontend-first dev.
- bcye 11mo ago
  Even for server ~~java~~typescript, I almost always reach for Bun nowadays. Used to be because of typestripping, which node now has too, but it's very convenient to write a quick script, import libraries and not have to worry about what format they are in.

pjmlp 11mo ago

Agreed, the language would be interesting during the 1990's, nowadays not so much. The tools that the language offers to handle use after free is hardly any different from using Purify, Insure++ back in 2000.

defen 11mo ago
I find comments like this fascinating, because you're implicitly evaluating a counterfactual where Bun was built with Rust (or some other "interesting" language). Maybe Bun would be better if it were built in Rust. But maybe it would have been slower (either at runtime or development speed) and not gotten far enough along to be acquired by one of the hottest companies in the world. There's no way to know. Why did Anthropic choose Bun instead of Deno, if Deno is written in a better language?
- pjmlp 11mo ago
  Because maybe they reached out to them, and they didn't took the money, while Bun folks business model wasn't working out? Who knows? Besides, how are they going to get back the money spent on the acquisition? Many times the answer to acquisitions has nothing to do with technology.
  - defen 11mo ago
    > Claude Code, FactoryAI, OpenCode, and others are all built with Bun. Anthropic chose to use Bun to build their tooling.
    - pjmlp 11mo ago
      We can think of they making bun an internal tool, push roadmap items that fit their internal products, whatever, which doesn't answer the getting back money of the acquisition. Profit in those products has to justify having now their own compiler team for a JavaScript runtime.
- n42 11mo ago
  Don't engage with this guy, he shows up in every one of these threads to pattern match back to his heyday without considering any of the nuance of what is actually different this time.

silasdavis 11mo ago

Stopped following Deno while they were rejecting the need for a package management solution. Used Bun instead.

croes 11mo ago
Isn’t because packages are one of the problems deno tried to fix?
- WorldMaker 11mo ago
  They tried to realign package management with web standards and tools that browsers can share (URLs and importmaps and "cache, don't install"). They didn't offer compatibility with existing package managers (notably and notoriously npm) until late in that game and took multiple swings at URL-based package repositories (deno.land/x/ and JSR), with JSR eventually realizing it needed stronger npm compatibility. Bun did prioritize npm compatibility earlier. Today though there seems to be a lot of parity, and I think things like JSR and strong importmaps support start to weigh in Deno's favor.
  - silasdavis 11mo ago
    Yeah it does look like things have moved on, but there were echoes from previous Go conversations around the idea of a standardised package and the attendant years of hurt that it turned me off a little while ago. I did try: https://github.com/denoland/deno/issues/4574#issuecomment-626755249 https://github.com/denoland/deno/issues/4574#issuecomment-62...

spiffytech 11mo ago

I tried several times to port Node projects to Deno. Each time compatibility had "improved" but I still didn't have a working build after a few days of effort. I don't know how Deno is today. I switched to Bun and porting went a lot smoother. Philosophically, I like that Bun sees Node compatibility as an obvious top priority. Deno sees it as a grudging necessity after losing the fight to do things differently.

fastball 11mo ago
Which makes sense given that a big impetus for Deno's existence was the creator of Node/Deno (Ryan Dahl) wanting to correct things he viewed as design mistakes in Node.

dmit 11mo ago

> is there anything that Bun does better? Telling prospective employees that if you're not ready to work 60-hour weeks, then what the fuck are you doing here? for one. > Zig does force some safety with ReleaseSafe IIRC which Bun doesn't use, choosing to go with `ReleaseFast` instead.

yieldcrv 11mo ago

I've been using Bun since 2022 just to be trendy for recruitment (it worked, and still works despite it almost being 2026) Bun is fast, and its worked as a drop in replacement for npm in large legacy projects too. I only ever encountered one issue, which was pretty dumb, Amazon's CDK has hardcoded references to various package manager's lock files, and Bun wasn't one of them https://github.com/aws/aws-cdk/issues/31753 https://github.com/aws/aws-cdk/issues/31753 This wasn't fixed till the end of 2024 and as you can see, only accidentally merged in but tolerated. It was promptly broken by a bun breaking change https://github.com/aws/aws-cdk/issues/33464 https://github.com/aws/aws-cdk/issues/33464 but don't let Amazon's own incompetency be the confirmation bias you were looking for about using a different package manager in production you can use SST to deploy cloud resources on AWS and any cloud, and that package works with bun

WorldMaker 11mo ago

> Bun seems to use a different runtime (JSC) which is less tested than V8, which makes me assume it might perform worse in real-world tasks (maybe not anymore?). JSC is still the JS engine for WebKit-based browsers, especially Safari, and per Apple App Store regulations the only JS engine supposedly allowable in all of iOS. It's more "mature" than V8 in terms of predating it. (V8 was not a fork of it and was started from scratch, but V8 was designed to replace it in the Blink fork from WebKit.) It has different performance goals and performance characteristics, but "less tested" seems uncharitable and it is certainly used in plenty of "real-world tasks" daily in iOS and macOS.

torginus 11mo ago

Is it just me, but I don't find npm that slow? Sure it's not a speed demon, but I rarely need to do npm install anyways so it's not a bottleneck for me. For deploy, usually running the attached terraform script takes more time. So while a speed increase is welcome, but I don't feel it gives me such a boost.

hinkley 11mo ago
The speed shows up for large projects. Especially if you end up with multiple node_modules directories in your dev sandbox.

dunham 11mo ago

Is JSC less tested? I thought it was used in Safari, which has some market share. I used bun briefly to run the output of my compiler, because it was the only javascript runtime that did tail calls. But I eventually added a tail call transform to my compiler and switched to node, which runs 40% faster for my test case (the compiler building itself).

kabirgoel 11mo ago

My team has been using it in prod for about a year now. There were some minor bugs in the runtime's implementation of buffers in 1.22 (?), but that was about the only issue we ran into. The nice things: 1. It's fast. 2. The standard library is great. (This may be less of an advantage over Deno.) 3. There's a ton of momentum behind it. 4. It's closer to Node.js than Deno is, at least last I tried. There were a bunch of little Node <> Deno papercuts. For example, Deno wanted .ts extensions on all imports. 5. I don't have to think about JSR. The warts: 1. The package manager has some issues that make it hard for us to use. I've forgotten why now, but this in particular bit us in the ass: https://github.com/oven-sh/bun/issues/6608 https://github.com/oven-sh/bun/issues/6608. We use PNPM and are very happy with it, even if it's not as fast as Bun's package manager. Overall, Deno felt to me like they were building a parallel ecosystem that I don't have a ton of conviction in, while Bun feels focused on meeting me where I am.

creata 11mo ago

Looking at Bun's website (the comparison table under "What's different about Bun?") and what people have said here, the only significant benefit of Bun over Node.js seems to be that it's more batteries-included - a bigger standard library, more tools, some convenience features like compiling JSX and stripping TypeScript types on-the-fly, etc. It's not clear to me why that requires creating a whole new runtime, or why they made the decisions they did, like choosing JSC instead of V8, or using a pre-1.0 language like Zig.

bodge5000 11mo ago

I really want to like Deno and will likely try it again, but last time I did it was just a bit of a pain anytime I wanted to use something built for npm (which is most packages out there), whereas bun didn't have that problem. There's certainly an argument to be made that, like any good tool, you have to learn Deno and can't fall back on just reusing node knowledge, and I'd absolutely agree with that, but in that case I wanted to learn the package, not the package manager. Edit: Also it has a nice standard library, not a huge win because that stuff is also doable in Deno, but again, its just a bit less painless

kamikazechaser 11mo ago

At this stage I don't think either is better over the other. Deno has inexplicable high memory usage issues in Linux containers. Bun more or less suffers from the same with an added dose of segfaults. 1. https://github.com/denoland/deno/issues?q=is%3Aissue%20state%3Aopen%20docker%20memory https://github.com/denoland/deno/issues?q=is%3Aissue%20state... 2. https://github.com/oven-sh/bun/issues?q=is%3Aissue%20state%3Aopen%20docker%20memory https://github.com/oven-sh/bun/issues?q=is%3Aissue%20state%3... Node.js is a no-brainer for anyone shipping a TS/JS backend. I'd rather deal with poor DX and slightly worse performance than risk fighting runtime related issues on deployment. Linux needs to be a first class citizen for any runtime/langauge toolchain.

Griffinsauce 11mo ago

Crash. According to my experience trying it many times oves the past years. It feels like a very unfocused project, every few months they introduce a new feature that is to replace an entire class of tools, while the original promise of "drop in Node replacement" was never fulfilled (or at least, that was the vibe for the past years when I was still paying attention). We'll see how this works out but speed + lack of scope never works out well in the long term.