[msoad]

I have not tried Bun yet but the long list of features makes me skeptical that it's all solid and bug-free. I'm wishing to be wrong. I'll give it a spin in a future project.

From a project management perspective I'm a little confused why would you spend time on S3 support while you're still not 100% Node.js compatible. Next.js is a very big ecosystem and if you can get Next.js customers onboard you'll grow much more than supporting S3.

[swiftcoder]

> while you're still not 100% Node.js compatible

100% compatibility is a nice marketing win, but the long tail of compatibility may not make much difference to the average user.

What percentage of the total Node.js API surface area do you actually use in your day-to-day? How many weird edge-cases therein are you actually depending on?

[homebrewer]

Do you inspect 100% of the code of each library you use to make sure it does not rely on missing or incompatible functionality?

[swiftcoder]

I mean, you are either auditing your supply chain or you are not. And if you are not, then minor node incompatibilities are the least of your worries.

[re-thc]

> From a project management perspective

This assumes you know what the project(s) is/are. Also the people working on it aren't robots. Maybe certain things take time to figure out and meanwhile you can do something else? It's also not just 1 person on the task.

> if you can get Next.js customers onboard you'll grow much more than supporting S3

Towards what? That doesn't make $$$. This is VC-backed. The goal isn't to provide Bun for free and gain all the users in the world.

[msoad]

This is a very uniformed response IMO. S3 seems very niche compared to Node.js compatibility. Not sure why you're attacking me for saying this?

[yoavm]

You mentioned Next.js and then Node.js. As for Next.js, it is supported by Bun (https://bun.sh/guides/ecosystem/nextjs). I don't think it's safe to assume that every single Node API is more commonly used than S3, which really is the standard cloud-based object storage API.

[elchangri]

S3 and niche don't fit in same sentence

[bmacho]

> I have not tried Bun yet but the long list of features makes me skeptical that it's all solid and bug-free.

Especially that it is written in Zig, which is very memory unsafe. I mean if you refer a variable that is not alive anymore, it just accesses some random unrelated memory instead of segfaulting (in debug and safe mode too)[0]. How hard would it be to bolt a memory liveness system above it, that flags a variable name dead and blocks access to it, if it is dead? No, "just don't write UB"[1].

Anyway I'd certainly not put a Zig made anything facing the internet, especially not a webserver.

[0] : https://news.ycombinator.com/item?id=41720995 [1] : https://github.com/ziglang/zig/issues/16467#issuecomment-164...

[zamalek]

In the early days of the project it was segfaulting during performance tests. That was a pretty hair-raising bit of information for me. Deno it is.

That being said, all of these run times use a JS JIT that are written in a memory unsafe language, that emit and execute raw machine code. They frequently have vulnerabilities.

[cassepipe]

Isn't it Deno written in Rust ?

Edit : It is

[drewbitt]

It is not very solid nor bug-free. We tried it last year and crashed all the time.

[nsonha]

> a bug where bun add would not respect the spacing and indentation in your package.json. Bun will now preserve the indentation of your package.json, no matter how wacky it is

I find this entry pretty funny. Who even asks for this and what makes they think it's worth writing code for.

[yieldcrv]

I’ve used it on big existing projects with tons of dependencies and small projects

I’m impressed

The dumbest thing I saw was Amazon’s CDK library looking for specific package manager lockfiles and was therefore semi-incompatible with bun

But if you use SST it doesnt matter