Live data from Hacker News

Beware of Bun.js

gist.github.com

41–50 of 53 posts

Re: Beware of Bun.js

#42

Earlier quoted context omitted.

Mind you, despite being a possible conflict of interest this also provides credentials for likely relevant expertise, with skill and interest in correcting errors. (Also, disclosure, not disclaimer.)

Or, perhaps the complete opposite, where it's someone who actually knows how to benchmark JS engines because they work for deno. But we won't know unless they explain which it is.

I think that’s a large part of what I was saying? I’m not sure how you interpreted what I said.

Re: Beware of Bun.js

#44
post #35

Creator of Bun here. Regarding the SQLite claim: The "view source" link for SQLite is out of date (fixing shortly), but the numbers are correct. I forgot to change the label on the landing page from "x/sqlite" to "x/sqlite3" and I forgot to update the source link. You can see I updated in this git commit: https://github.com/oven-sh/bun/commit/4b5c9acc72908ba22e3f70... Here is what it shows for me, but I encourage you…

Bun's SQLite implementation has correctness issues:

https://github.com/oven-sh/bun/issues/921

https://github.com/oven-sh/bun/pull/1056#pullrequestreview-1...

This makes SQLite transactions no longer serializable (in regard to the schema), and breaks the safety of any kind of external concurrency (e.g. mvSQLite and Litestream).

Re: Beware of Bun.js

#45

The thing about Bun that turns me off is around the OS-specific system call optimizations (using different optimizations for different platforms) which means that each new feature they add to bun that uses any system calls must be done 3 times for the 3 major platforms (MacOS, Windows, Linux) Another thing is I believe Deno supports WebGPU and Node supports WebGL via Angle etc (for e.g. running Tensorflow with GPU su…

It's surprisingly easy to develop OS-specific code using Zig (the language Bun uses), because of its excellent integrated support for cross compilation and comptime feature. For example, with some zig code I write (a posix layer for node), I build for many platforms in parallel every time I make a change.

Re: Beware of Bun.js

#46
post #28
post #9

Earlier quoted context omitted.

I don't think this is malice, more that frankly developers are really bad at benchmarks. Myself included.

I wouldn't say it's even that. To me it reads like they're using sane defaults for Deno that any developer would use. The fact performance can be improved by leveraging knowledge of Deno internals is irrelevant. Comparing default OOB performance is an apples-to-apples comparison. This "exposé" seems like mud slinging from a disgruntled Deno maintainer with inherent bias to see Deno perform better. If anything, it pai…

No, I disagree. A couple of those things pointed out are fair: they’re unfair comparisons that aren’t apples to apples, which matters for benchmarks. The SQLite one for example is like me benchmarking a game on two PCs to test graphics performance, but with wildly different settings on both. It tells the end user nothing useful about the comparative performance.

All of those things are easy mistakes to make though. Where it’s a bit not great is if there was apparently communication about it and the Bun team didn’t at least change the SQLite comparison — it’s not “OOTB” behaviour, it’s a library.

Re: Beware of Bun.js

#48
post #33

Earlier quoted context omitted.

I have nothing to do with anything in this space, but why would you not want to take advantage of the platform’s native capabilities?

it might drive some skepticism toward long term support or reliability ( everything has to be developed three times ) and unknown performance characteristics ( or even potential behavior ) across platforms. not sure I agree with the take, but that's how I read it

to be clear, this isn't my take.

Re: Beware of Bun.js

#49
post #46
post #28

Earlier quoted context omitted.

I wouldn't say it's even that. To me it reads like they're using sane defaults for Deno that any developer would use. The fact performance can be improved by leveraging knowledge of Deno internals is irrelevant. Comparing default OOB performance is an apples-to-apples comparison. This "exposé" seems like mud slinging from a disgruntled Deno maintainer with inherent bias to see Deno perform better. If anything, it pai…

No, I disagree. A couple of those things pointed out are fair: they’re unfair comparisons that aren’t apples to apples, which matters for benchmarks. The SQLite one for example is like me benchmarking a game on two PCs to test graphics performance, but with wildly different settings on both. It tells the end user nothing useful about the comparative performance. All of those things are easy mistakes to make though. W…

That's fair. It seems both issues have now been fixed[1].

I still think the approach of reporting this by the Deno developer was unnecessarily hostile.

[1]: https://news.ycombinator.com/item?id=33199911

Re: Beware of Bun.js

#50
post #49
post #46

Earlier quoted context omitted.

No, I disagree. A couple of those things pointed out are fair: they’re unfair comparisons that aren’t apples to apples, which matters for benchmarks. The SQLite one for example is like me benchmarking a game on two PCs to test graphics performance, but with wildly different settings on both. It tells the end user nothing useful about the comparative performance. All of those things are easy mistakes to make though. W…

That's fair. It seems both issues have now been fixed[1]. I still think the approach of reporting this by the Deno developer was unnecessarily hostile. [1]: https://news.ycombinator.com/item?id=33199911

That I absolutely agree with, this could’ve been resolved a lot more maturely.
Post reply on HN