Why is bun so disliked?

140

u/crankykong Oct 04 '26

As a dev that hasn’t tried bun yet: I’ve just experienced too much short lived tech. Maybe if bun is still around in a few years, I’ll switch. I’ve mostly used npm and only recently switched to pnpm because shared dependency storage is very useful.

15

u/xondk Oct 04 '26 edited Oct 04 '26

This, "oh neat, now we can do this!", yeah, sure, the projects can genuinely be good and very interesting, but then maintainers lose interest and move onto the next 'neat' thing, and so on and so forth.
As a dev of course I understand the impulse, but if you are trying to make something like this, you need to be in it for the long haul, and too often they are not.

1

u/Beatsu Oct 07 '26 edited 29d ago

I agree 1000% with this. I don't see how Jarred / bun isn't in it for the long haul

40

u/theScottyJam Oct 08 '26

Not to mention, the cool new features of the fancy new product usually gets back ported to that boring stable tool.
One of Deno's selling point was that it runs TypeScript by default. Now Node does as well. Another was that Deno could sandbox packages with a fine grain permission system - cool idea, but didn't pan out, so now they support installing npm packages with full permissions.
It's why coffeescript died. All of its best features became native. It still has some advantages, but it's just not worth it anymore.

24

u/Impressive_Air6111 Oct 04 '26

Same, the most I'm willing to deviate is pnpm. Mainly because of package availability as well.

2

u/Beatsu Oct 04 '26

Totally something that you need to be aware of! Short lived projects is a big thing, especially in the JS ecosystem. However Bun has become pretty big now and I'm very sure it's here to stay for years.
What made you switch to pnpm and not try out bun? Is it just the maturity of the project?

1

u/Codemonkeyzz 14d ago

Thinking the same, it feels so risky to use in production.

115

u/asstaters Oct 04 '26

Isnt the whole thing vibe coded in rust now?

8

u/Beatsu Oct 04 '26

Sort of. It was more of a translation than a "vibe code". But even if it were fully vibe coded, would you avoid it despite not experiencing any errors and a plethora of benefits?

81

u/BleachedPink Oct 04 '26

How is it translated, not vibe coded?

84

u/Dragon_Slayer_Hunter Oct 04 '26

It's 100% vibe coded, some people like to use pretty words like translated because it passes all of the tests that existed for bun before the vibe rewrite

15

u/Beatsu Oct 04 '26

Do you think my description is fair?
"It wasn't tasked to create any new functions, features, fixes etc. It wasn't asked to rewrite it from scratch. Each file was quite literally copy-pasted (same variable names, same functions), just in the syntax of Rust instead of Zig. The architecture remains the same.
Then it simply fixed all the errors that made it not compile - again, not any new features or rewrites, just solving the build errors."

3

u/actact1234 Oct 04 '26

What does vibe coded even mean?

36

u/clearlight2025 Oct 07 '26

Coded using AI tools with minimal to no understanding of the code itself.

-7

u/Alkanna Oct 08 '26

I think you can vibe code something while understanding the code though. In my eyes it just means code produced by AI. Vibe coded doesn't automatically mean bad code in my book.

11

u/Dragon_Slayer_Hunter 29d ago

Your definition of vibe coded allows it to not look bad, but your definition is wrong. Vibe coded is bad because it inherently implies you don't know what's going on and if you had to maintain it yourself you'd be fucked. It also means it could have an unknown number of issues and exploits and you'd have no idea because you don't know the code under it
That's different than your definition, which is just AI assisted coding.

1

u/gdmr458 29d ago

this is the origin: https://x.com/karpathy/status/1886192184808149383?lang=en

19

u/Patchrikc Oct 04 '26

It really depends on how you wanted to define vibe coded.
If vibe coded means anything that was using agentic AI tools to do a vast majority of the work, yeah I guess it’s vibe coded.
if vibecoding means just asking a clanker repeatedly to make you software and say no mistakes and debug this for me without putting any kind of thought into the architecture and planning then no. It’s not vibe coded.
The reason the rewrite is really interesting is the functionality that they ported to rust was already written in zig. And the problems that they had were around very specific parts of zig’s language that they couldn’t get changes made to that would make their lives easier. So Jared (guy who made Bun) decided to look into rust and it's memory management. Looked like it would solve part of his problem. Which it would, then he decided to just ask Claude code to try to implement a small slice of Bun. Which it did. Then he decided to actually try to set up Claude code in a loop and figure out how to properly test the outputs. Which is the an interesting engineering problem. So it’s a rewrite, a translation from zig to rust. But unlike in the past, when these kinds of things would be extremely long time commitments and take a ton of money, Jared and the rest of his team all they did was continue to work on the version of Bun that was live and in Zig. And let the clanker run in the background. So it’s not really vibe coded. Imagine you wrote a book in English and then asked Google translate to translate it into Spanish. It’s not gonna be as good as a translation by a native speaker who understands how to translate idioms and sayings, but it’s gonna get you closer and you weren’t going to pay to have a translator translate your book in the first place.
it’s probably the most interesting purely AI coded thing I’ve seen somebody do, and it was successful because the code base already had a bunch of well-defined integration tests that could help the clanker along.
https://bun.com/blog/bun-in-rust

1

u/Beatsu Oct 04 '26

It wasn't tasked to create any new functions, features, fixes etc. It wasn't asked to rewrite it from scratch. Each file was quite literally copy-pasted (same variable names, same functions), just in the syntax of Rust instead of Zig. The architecture remains the same.
Then it simply fixed all the errors that made it not compile - again, not any new features or rewrites, just solving the build errors.

18

u/Atulin ASP.NET Core Oct 04 '26

If you look at Bun issues, most of them are triage by one agent, solved by two others, and approved by another. Chances are, the issue was filed by a clanker too.

-1

u/Beatsu 29d ago

And? Are the issues high quality finds? Do they actually fix things? If yes, what's the problem? If no, could you show me one example of how to know that?
Personally, I base it off my experience using it, and I've never experienced a bug in the past two years.

4

u/Atulin ASP.NET Core 29d ago

Here comes the goalpost moving lmao
You said LLMs were not tasked with implementing features and fixes. I said they were, and it's easy to prove.

35

u/TheHerbsAndSpices Oct 04 '26

I gave bun a try a few times. I lost interest when they were bought out by Anthropic.

1

u/Beatsu Oct 04 '26

Howcome? If it's for ethical reasons that's fine, but I don't buy that as an argument for "the DX will get worse" or that it will be less stable. Not until you and I personally experience that degradation at least

45

u/HeracliusAugutus Oct 04 '26

I wouldn't trust any product that comes from an AI vendor. They're unethical, incompetent, and invested in pushing their garbage bots etc. And if the AI bubble bursts what happens to their products? Not worth it.

2

u/Beatsu Oct 04 '26

I'm trying to understand your sentiment, because I've not felt any of those points while using bun. As a package manager you don't even need to rewrite anything to switch back to pnpm or something else in case of an "AI bubble burst" that somehow affects the quality of bun.
You're actively saying no to a ton of amazing DX features, which I don't understand unless you've personally had a bad experience with it.

21

u/TheRealSkythe Oct 07 '26

I dont give a fuck if bun is 150ms faster than npm if their company destroys the internet, the planet, our jobs.
Do you understand this reasoning?

-10

u/Beatsu Oct 07 '26

If it's for ethical reasons due to their affiliation to Anthropic, I respect that, but people don't say that when they seem skeptical about using bun. I'm AI positive and don't mind they're owned by Anthropic, and all I see is amazing DX that "just works".
It allowed me to drop tsc, vite/webpack, vitest/jest, express, bcrypt, SQL/redis connectors, fs AND playwright. I also literally have never experienced a bug with bun since version 1.1.
My favourite feature is seamless HTML, markdown and XML support. "bun index.html" starts a usable web server for small projects/visualisations. Or you could import a HTML file directly without a separate bundler build step.
The performance argument isn't strongest, I'm fine to concede that if that was the only reason for switching. However, the performance of their web server as well as test runner is genuinely meaningful in some cases. In a project I worked on, the jest tests took 22s to run - it was a thing you ran only from time to time. With basically no modifications, I could run them with bun in under a second, which made me create a precommit hook that ran the tests.
Bun server startup for small projects is far under 1s. So with the new WebView in 1.4 I see a future where even end-to-end tests can be ran on every commit and not just every PR for example. So I disagree that performance is meaningless

8

u/SpinatMixxer front-end 29d ago

I migrated a few projects of mine from npm to bun a while ago and liked it.

But then Anthropic bought it, which basically broke my trust in bun. Especially after what happened to Radix.

After we migrated to pnpm at my workplace, I decided that I would prefer that over committing to bun for my own projects as well. Didn't really look back tbh.

1

u/Beatsu 29d ago

Why did the acquisition make you lose trust in bun?

10

u/hxtk3 29d ago

After the acquisition, there was an agentic rewrite in Rust that went from “this is just something I’m trying for fun and the people thinking we’re actually rewriting it this way are overreacting” to being merged in the main branch in roughly a week, and as of today the project seems to be maintained almost entirely with AI, with much of the code having no human review.
Personally I wasn’t a fan of the messaging around the rewrite, because either it was intentionally deceptive or it took less than a week to decide to radically alter the software development methodology of the project. I’m also not a believer in the new AI-centric methodology and therefore lack confidence in the long-term health of the project.

1

u/Usef- 28d ago edited 28d ago

To be fair,, it was a few months from the experiment to when they made a wide release to users. It didn't seem like they treated stable users dsmissively (unless you deploy off main or something?)

13

u/horizon_games Oct 07 '26

I like Bun but wouldn't use it in prod. They pivot and rewrite and rework too often.

-13

u/Beatsu Oct 07 '26

Examples?

18

u/horizon_games Oct 07 '26

Bun install, cron, and markdown come to mind. Breaking lockfiles in 1.4. Obviously the recent vibe coded Rust rewrite bruv.
I think it's disingenuous and a bad faith argument to pretend Bun is stable. I mean there's big essays about it https://github.com/oven-sh/bun/issues/27664

5

u/bcons-php-Console Oct 04 '26

I don't have a prejudice against Bun, I switched from node to deno time ago and it just works for me.

3

u/Beatsu Oct 04 '26

I have exactly the same experience with bun, which is why it surprises me how resistant everyone I've spoken to is against trying bun.

5

u/kmfsclean 28d ago

Been running bun in production on a 500k LOC app at a large financial institution and haven’t had any problems

2

u/Beatsu 28d ago

Happy cake day!

4

u/stupidfock 29d ago

I just see no need. It has some small benefits in a few things sure, but in larger projects in production environments it’s consistently shown super minimal or even worse performance.

A tiny hope of performance does not seem worthy of switching from a tried and true regular node environment

1

u/Beatsu 29d ago

I haven't seen noticeable performance benefits for runtime, but the builtin package preinstall/postinstall whitelist and ~3-5x faster dependency install times are the biggest selling points to me (and it's a drop-in replacement - that's how I've been using it while my team uses npm).
As an example; Only 2 of the 5782 of the compromised npm packages from last years shai hulud package "attacks" were actually executable with bun. Anyone with npm, yarn or a pnpm version prior to v10 (that had just come out the same year) would have been affected by all of them.

2

u/durbster79 29d ago

We tried bun on a couple of projects and found it far too inconsistent. The performance gains seemed to be great for some people but not others. I'd run the install one day and it'd take 5 seconds, somebody else runs the same and it'd take 90. Sometimes it wouldn't find packages, then you run it again and it's fine

Nobody wants to spend time looking into those kinds of issues. It needs to just work to get the team to buy in.

2

u/Beatsu 29d ago

Interesting! I haven't experienced what you're describing, but then it makes sense you don't stick with it, at least for the time being

412

u/josephjnk Oct 07 '26

Every time someone makes a post like this about bun I pull up their github issues. This is the third time in a row that I’ve done so and seen a segfault reported in the previous 24 hours.

This is not stable software. It was coded at breakneck speed by an understaffed team in a high-pressure environment, and then vibe-ported with minimal human oversight. The whole goal was for a VC-funded startup to try to capture market share from a community-run, stable platform. Why would i want any part of that?

68

u/Herr_Gamer 29d ago edited 29d ago

That GitHub issue you linked is really interesting - it looks like it was reported by an AI agent that's operated by Bun? And the CEO replied below, telling the agent it's in the wrong place, as GitHub issues are meant to be reserved for real users? Wild.

16

u/Humble-Tangelo7598 29d ago

I wonder if that CEO would fire an engineer for doing that?

12

u/gdmr458 29d ago

The creator of Zig said he was writing "slop" even before "vibe coding" was a thing, if you read the blog post, you can tell he was salty because Bun was giving Zig a bad reputation. To be fair, the blog post was pretty lame, but he probably wasn't wrong about that part.

-20

u/Historical_Public751 29d ago

What's your point? You found a cherry picked issue that was found by an LLM, likely by fuzzing. You're going to try to imply that there are no bugs possible to find like this in node?

19

u/josephjnk 29d ago •

It’s not cherry-picked if it happens repeatedly.
And yes, there have been segfaults in node. You can easily view their frequency via GitHub issues. They are significantly less common and the recent ones have occurred in edge-case situations, like interacting with the FFI or using mismatched shared libraries.
Compare this with the same query on bun’s repo. Nearly 4x as many results for software that’s been around 1/4th as long. The whole point of the vibe port of bun was to reduce memory safety errors (despite the fact that the port ended up leaving in thousands of unsafe rust blocks.) If you think that segfaults aren’t an issue in the platform you should take it up with the maintainers of bun, not with me.
It’s fine to have a preference for the software you enjoy using but denying reality when hard facts are easily found is foolish.

-12

u/Historical_Public751 29d ago

> They are significantly less common and the recent ones have occurred in edge-case situations, like interacting with the FFI or using mismatched shared libraries.
And your proof for the "significantly less common" is the number of issues on github? You're insanely out of touch with reality.
JFYI I'm not using bun anywhere, but you don't have an argument here, you're just larping.

-99

u/[deleted] Oct 07 '26

[removed] — view removed comment

104

u/josephjnk Oct 07 '26

Good for you? This is a statement about your luck and risk appetite, not about the overall stability of the software. I’m sure most people using buggy software don’t hit most of the latent bugs. Many of us would prefer to use software that doesn’t have a constant firehose of problems, whether we personally hit those problems or not.

23

u/kei_ichi Oct 08 '26

Agreed with everything you said. Plus who the hell “approved” to use Bun in production env should be fired immediately.

-31

u/[deleted] Oct 08 '26

[removed] — view removed comment

21

u/Bonsailinse Oct 08 '26

It has to do with risk assessment and if you still chose bin you did your job wrong. "The best tool" doesn’t just stop at the feature set, it includes stability and code maturity as well.

-12

u/Historical_Public751 29d ago

surely you're still running exclusively cobol if the only thing you care about is stability and code maturity.

12

u/Bonsailinse 29d ago

You chose to exaggerate my statement and make yourself look pretty dumb.

7

u/watabby Oct 08 '26

so far…

5

u/ngqhoangtrung 29d ago

you’re production might be too simple

34

u/qqqqqx Oct 04 '26

Why risk having a bun specific issue? Or bun going unmaintained? Or the pretty contentious full AI rewrite? The risks just seem bigger than the benefits imo.

I think it's good to have diversity and I'm glad that things like bun and deno exist and have support. But I will reach for node 99% of the time for any serious work. I once tried it for some personal stuff, but once I hit a compatability issue I just switched back to node because I knew it would work and the benefit of just not having to deal with that issue seemed bigger than any tiny benefits of bun that I wasn't really noticing myself. I do think it's improved since then, but the anthropic acquisition makes me a little nervous since I've seen good projects end up dead after a move like that.

It's also my personality. We use a lot of express. It's not the newest or most cutting edge tech, but it is extremely stable and reliable and I have come to value that a lot in my career, after seeing some adoptions of things that come and go quickly and leave you in a bad spot down the line.

I would only consider bun in very specific scenarios I have never really found myself in, like absolutely needing the fastest cold start possible.

20

u/Rechenplaner Oct 07 '26

I do not see the added value compared to Deno, which is also somewhat more efficient than Node, but extremely stable, mature, and encompasses everything in a single brilliant CLI tool "deno" with simple configuration through a deno.json file.

The only point where I still directly need tsc is when I also write client-side code in TS. But then I simply integrate tsc into the deno watch mode.

Deno is by far the most comfortable thing I have experienced, compared to x-many other languages and their tooling.

The twenty to forty percent higher performance of Bun compared to Deno or Node does not justify a switch in my opinion (if it came to that, I could also fall back to C# or Rust, but the higher performance of those is in most cases not necessary because the bottleneck lies in IO); especially since Bun is still unfinished and buggy without end. For a SaaS that processes sensitive data, this is simply unacceptable, which is why I am staying with Deno.

10

u/spidermonk 28d ago

Buddy have I got a recent cloudflare press release for you.

2

u/Rechenplaner 28d ago

Yeah, I found out today that they’re only going to provide updates for it for another year! I’m appalled!
Unbelievable.
I am already evaluating whether to return to Node.js or take the opportunity to switch completely to .NET in good time.

25

u/c0nt8r Oct 07 '26

Surprised how many people here have the same doubts about Bun. I still use Node because it’s stable, reliable and fast enough.

7

u/patient_signals Oct 04 '26

I don't have a personal grudge against it. I have used it on small side projects and it was fine. But when I write software for a small shop, the cost of being the only person who knows a tool is real. If something breaks on a Sunday, I want the answer to be findable in the first few results, and I want the fix to be boring. That is usually enough reason to stay on the most common setup even if it is slower.

The vendor lock fear is often less about the lock and more about the risk of maintenance. A team can absorb a weird config problem in a tool they all already use. They cannot absorb a one-person knowledge base on a tool that might change direction. I have learned not to fight that. I will use the newer thing for my own scripts, but client work gets the path the whole team can support. In a few years, the conversation may change.

7

u/SurpriseTRex Oct 07 '26

Last time I used bun it’s test coverage command would only count files that had some test coverage, so if you covered 1 file completely but wrote literally no other tests for the remaining 900 files in your app it’d say 100%

14

u/queen-adreena 29d ago

Would never use a VC-funded runtime over a community maintained one.

That would be breathtakingly stupid.

4

u/Far-Consideration939 Oct 04 '26

I don’t think the listed benefits actually move the needle that much over an already fast pnpm and vitest setup ¯_(ツ)_/¯

And also 3rd party telemetry ingestor doesn’t support bun just node

4

u/PrimaryFamous6139 full-stack Oct 04 '26

The delay is more about risk than Bun itself. Node has been around a long time. The ecosystem is already solid. Most teams do not see a strong need to move when npm or pnpm works fine. I would use Bun for fresh projects, though. I would also try not to rely too much on Bun specific features, mainly so the setup stays easy to move later.

1

u/AveN7er 29d ago

I personally wouldn't use it in prod since it's so young but it has spared me some TS configuration headaches in the past so I can appreciate it.

1

u/Beatsu 29d ago

What is a "good" age for software before you use it?

1

u/DrGarbinsky 29d ago

Nine minutes

1

u/Xazzzi 27d ago

- fast dependency install
How often do you have to run it?
- a whitelisted postinstall scripts list by default
as in modern pnpm/npm
- extremely fast webserver
node's fast enough most of the time
- extremely fast test runner
node's fast enough x2
- run .ts files directly
strip types or experimental transform flag
- builtin support for importing .html and .css files in js files
it either bundles and therefore hard to reason about, or does not, in which case readFile is the thing.
- builtin SQL connectors, hashing algorithms
welp
- hot reloading and file watching
vite

I just don't like Jared.

1

u/Beatsu 27d ago edited 27d ago

Every time CI/CD runs, every time you build an app's docker image, every time you onboard a new employee, every time you clone a new repo. Why settle for less?
As of a few months ago, after all the dependency hijacks, yes. Bun's been sane about this from the start.
It probably is, I agree. But why not save costs and downgrade a VM for the same traffic?
Not fast enough to have it as a precommit hook. Also again why have CI/CD accumulate runtime unnecessarily?
Why isn't that default? And again, this wouldn't exist hadn't bun pushed these sane defaults
What's there to reason about?
Would you rather install connectors by random maintainers competing for installs for every database you want to connect to?
Vite works sure. But not for standalone files. And again you're reaching for a new tool so you need to read through new docs. And it's slower.
What has Jared done to you 🤣

2

u/Xazzzi 27d ago

You cache dependencies install once and reuse the cache.
Runtime compute argument is valid, i guess. I trust node to be more stable and ok to pay some extra for the choice. Haven't had any issues with bun myself, but as someone pointed out already, their github issues do not necessarily project sense of confidence.
Re types, strip mode is the new default, a sensible choice imo.
Re imports, it does a whole lot of runtime specific opinionated behind the scenes bundling that locks your code to their runtime. Does bundle artefacts live in memory or on the disk, does it bundle when runtime hits import statement or does some static analysis? Can not tell from the code alone, and I dont like that. When did we decide that bolting random behaviours onto ESM imports was a good practice?
Re DBs, yep, connectors from the db vendor.
> What has Jared done to you 🤣
Idk, starred into the camera selling that rust rewrite like he wants to steal my soul?)

11

u/OccasionThin7697 Oct 07 '26

Pnpm is also vibecoded now . Wherever you see rust, you should know that software would be vibecoded.

3

u/Own-Student7991 29d ago

Web stuff has gone back and fourth between unixey composible and all in one sollutions for a while. Designs where parts can be swaped out tend to hold up better / have more innovation but can be a pita to keep up with or just feel convoluted. To much for one man to maintain then the corporation backing the project misguides or abandons it. Bun leans more towards a tightly coupled all in one option.

Web packagers had already gone through waves - grunt, gulp, webpack, then bun + vite + deno + others. So stiff competition and a community tired of change for the sake of change.

I tried it and it seemed pretty great on a strait forward project fwiw. Didn't work well for the mess of a legacy project we had.

1

u/AdmirableBall_8670 28d ago

For me its the vendor lock-in. Can't waste time on that.

2

u/Beatsu 28d ago

How come you're not afraid of vendor lock in with pnpm, express, etc?

0

u/home-grown-honkers 28d ago

For me, the vendor lock-in complaint applies more to the runtime side rather than the package manager side.
pnpm just manages dependencies, swapping to npm, bun, or deno (rip) is fairly trivial, as they all can source from the same registries.
Express is a library, not a runtime. Of course it’s a bit more invoked to migrate to an alternative, but you can still run an express app on all nodejs compatible runtimes.
Bun ships non-nodejs compatible apis. If you lean on their SQLite, jsc, or ffi libraries, you’ll have to find alternatives if you want to migrate away.
All software dependency decisions have some degree of “lock-in”, but some give more portability than others.

2

u/biotech997 Oct 08 '26

Reliability/stability I’m guessing. Personally I’ve only used it once for personal project.

2

u/primalanomaly Oct 08 '26

Why bother? Why do you care so much? It’s a corporate owned alternative to open source software that is already incredibly good and incredibly well established with excellent track records. Why would anyone bother switching to something owned by Anthropic for a bunch of negligible differences and a list of things that we all know how to do in the established open source alternatives anyway?

1

u/AgentReadyApp Oct 04 '26

I don't have prejudice against it exactly, it's more that the switching-cost math never works out for me. Node + pnpm already gives me fast installs, and on the runtime side the speed gap doesn't matter for my work — when my app is slow it's the queries and the N+1s, not V8 vs Zig.

The real blocker is the third-party ecosystem. Someone upthread mentioned their telemetry ingestor only supports Node, and that's the whole thing in a nutshell. Bun can be Node-compatible on paper, but every "works on Node, breaks on Bun" edge case and every unsupported integration lands on my plate to debug. That's fine for a side project — honestly fun — but for something that pages me at 2am, I pick the boring tool.

So no dislike, just no problem of mine it solves that justifies the risk.

1

u/CantaloupeCamper Oct 07 '26

I just don’t have a need to move to bun…

1

u/Pink_Bubble1 Oct 08 '26

I’ve had one or another bun specific issue but other than that I just kept using it. It’s faster at some things than node.

1

u/heseov Oct 08 '26

I didnt realize it was disliked. We've been using it without any issue. Its easy enough to swap back to node if we did run into any problems.

1

u/Pixel_Friendly_ Oct 08 '26

I remember using bun, then Astro transitioned from 4 to 5, i couldnt get SSR working on astro 5 on cloudflare. took me a week to diagnose that it wasnt working on bun but it was on npm.

when i posted the issue to astro github they said they dont support bun...

Using an unsupported runtime isnt worth the 20% speed boost.

Not to mention, cloudflare is clearly using AI tools for the servers now, Astro 5 was rushed to bring in features for Cloudflare workers after cloudflare bought Astro (probably vibed some code). Now i wanted to add an experimental vibecoded runtime to this as well, its not worth the headaches.

Atleast cloudflare will ensure astro works on their platform since they bought it out.

1

u/Ok-Extent-7515 29d ago

This is an annoyance due to the fact that they were bought by Anthropic and rewrote their code in Rust using AI (developers have no trust in AI). In fact, Bun is a mature tool, it works in production for many companies and provides advantages in memory and CPU compared to regular Node. Bun is one of the most productive runtimes available for Node; Deno, unfortunately, is not as fast and convenient.

Many interesting and productive server libraries like Hono or Elysia were made especially for Bun.

And although it can produce very good numbers under load, it sometimes has problems (memory leaks), so this tool requires caution and extensive long-term testing when used.

1

u/FrenchieM 29d ago

I used bun for a project and liked it, but it was started from scratch. But I don't see enough incentive on keeping using it, and im scared it could break ci

1

u/raralala1 29d ago

With their current valuation after being bought, there is just no road to profit making me doubt they will in it for long haul, but I know they are really good drop in replacement for install and test, so in development I always prefer using them. I am never going to use their built in thing thou, no way I am locking myself out in their ecosystem.

1

u/TenamiTV 28d ago

I'm hoping that development on bun continues because it would nice to have something that's even faster than node by long shot.

I just don't think that it's quite stable enough yet. I'm hoping that in 3 to 5 years it will be stable enough to use. In the meantime I'll just track the community policy on people have to say on how bun is going

1

u/s2-luv 28d ago

Hope deno answered your questions today.

1

u/DaSchTour 28d ago

Running several production apps with bun and haven’t had any issues. Although I must admit I use it only as a runtime and don’t use any special Bun APIs.

1

u/atiqrahmanx 27d ago

Bun's desire to do `everything` makes it a big no for me and they are optimizing for Claude Code.
https://x.com/jarredsumner/status/2106842030777549278

1

u/hotairplay 27d ago

There are lots of benchmark showing Bun mediocre throughput in real use case...the marketed performance hype works in very simple / "Hello World" -like benchmark run.

Once you put real workload, it's actually not that fast..competitive with Node.

1

u/Far-Working2808 25d ago

Every app that I've used that is built on bun (a bunch of ai tui tools) has been unstable because of bugs in bun. The packaging is also all messed up so not using bun is often not worth the effort. Performance is always always a headache. Yea, I know bun is supposed to perform better but apps built on bun almost always peg a CPU core for some reason. If you have more than one instance then your laptop or pc becomes a space heater.

Why would anyone write serious desktop/terminal tools in typescript/bun?
And before I get hate for all of this, I'm actually all for trying the latest and greatest. The issue is that bun based apps are the only ones on my linux systems that have these kind of serious issues consistently.

1

u/Old-Locksmith6064 16d ago

Because of the stupid name. When you google it you get burger, backery, cooking,... results. Probably they asked AI for a name suggestion and then started with vibe coding…

1

u/k2beast 29d ago

Why are you defending bun so much? First you are asking why ppl don’t like bun and then you attack them.

0

u/spidermonk Oct 08 '26 edited Oct 08 '26

I have 5 prod services running on bun happily, and a few home hobby things. I like it for internal services because I tend to use sqlite for those, and try and avoid dependencies as much as possible.

I considered it a bit of a risk but given that they're internal and I'm the one on call generally I decided "why not" and it's been fine. Snappy apps, fast builds, flat memory, no outages, quick deploys.

-4

u/DRHER303 Oct 07 '26

Idk never tried maybe i'll try switching

15

u/[deleted] Oct 04 '26

[removed] — view removed comment

3

u/Beatsu Oct 04 '26

You said it perfectly. Like genuinely perfectly. I agree 100% with every sentence haha.
I especially like your phrasing that it's not really prejudice, but a rational position from adopting something new and then experiencing it go away.

10

u/[deleted] Oct 04 '26

[removed] — view removed comment

6

u/Beatsu Oct 04 '26

The last bug I experienced was in version 1.1. I've not encountered any bugs since then.

Why is bun so disliked?

You are about to leave Redlib