So, anybody using Bun? Does it live up to hype?
oh yeah, it's amazing! The speed is great but just the DX is so much nicer than npm, yarn, or node itself. It took us a few tries to getting it working for our prod environments, but nothing we couldn't figure out within the same day. I thought having a binary for a lock file was weird (don't know the technical reasons behind it besides maybe speed) but after using it for months now, it never has caused an issue for…
Bun’s New Crash Reporter
11–20 of 91 posts
Thanks for the feedback. What kind of product are you using it for? Any issues with library compatibility?
Re: Bun’s New Crash Reporter
#12So, anybody using Bun? Does it live up to hype?
using it on all my side projects, some of which made it to production. some of which had lots of dependencies in the past and seamlessly switched over
one employer/client has a big project I'm afraid to attempt changing anything on, but I wonder
Re: Bun’s New Crash Reporter
#13Re: Bun’s New Crash Reporter
#14So, anybody using Bun? Does it live up to hype?
Pretty awesome, but I hope they get the node:crypto module to 100% soon.
Re: Bun’s New Crash Reporter
#15So, anybody using Bun? Does it live up to hype?
It’s good unless you want a repl (they pretend to have one but it’s miserable: >6s latency all the time when it updates), or you plan to use any native modules. The error messages are also significantly worse than node’s. I used it for a bit, but node with ‘—loader tsx’ does everything I want nowadays with none of the downside. If I was building a simple server, perhaps with websockets, and I was sure it need native modules, I’d consider using Bun. I have several such services live now actually.
Re: Bun’s New Crash Reporter
#16So, anybody using Bun? Does it live up to hype?
I have not used it in production yet, but it's been great for one-off scripts and side projects. Setting up a TypeScript Node environment with ts-node, ts-jest, ESM support, top level await, etc. is more annoying than it should be. More recent Node releases have alleviated some of this pain, but not as trivial as running bun init.
I've enjoyed using the bun shell [1] API.
Re: Bun’s New Crash Reporter
#17Earlier quoted context omitted.
Started using it as soon as they hit 1.0 and never looked back, we’re implementing it in every project now.
Bun + uwebsocket cut my server costs and requirements significantly for my websocket app. It's a real delight to work with.
How did it cut your server costs - increased performance and therefore reduced load?
Bun looks quite promising, but I've heard mixed feedback on it being a "drop in" replacement of node. Any experience with that aspect?
Re: Bun’s New Crash Reporter
#18Few people would notice how much attention was put into it. Love it, really tells how much the folks behind bun care about their craft
Re: Bun’s New Crash Reporter
#19Microsoft is really good at this BTW. At SQL Server we had mini dumps they were tiny stripped out of personal info and incredibly useful. And a full dump of a production SQL Server even at that time (15 years ago) would be a huge file - too big to move around.
Re: Bun’s New Crash Reporter
#20Did you know that bun needs to download 37 packages before the repl becomes available? No internet no repl for you.
PS C:\Users\anon> bun repl
bun-repl [6/6]
error: FailedToOpenSocket downloading package manifest bun-repl
error: bun-repl@latest failed to resolve
Not a big deal, but I was expecting (and frankly excited) to have a single no-install executable to drop in my PATH and have it just work!