Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Beware of Bun.js

gist.github.com

Post reply on HN
Print view View original

31–40 of 53 posts

Re: Beware of Bun.js

#31

Post by LegionMammal978 »

olliej wrote: post #15

This seems to not be entirely reasonable. [edit: apparently the author is a deno employee but did not choose to disclose such? If so then that throws any moral position they have out the window. The below however is still accurate to my reading of the complaints.] First up is the FFI test. On the one hand I think that this is a legitimate complaint, changing an existing benchmark for your comparisons is always suspec…

> apparently the author is a deno employee but did not choose to disclose such? If so then that throws any moral position they have out the window.

It seems like the author disclosed this a couple minutes after you wrote your comment.

> The sqlite complaint is not reasonable, if sqlite is being used as a demonstration of wasm performance there is nothing at all wrong with this test

Looking at that benchmark, it seems to be comparing Deno's WASM sqlite to Bun's native bun:sqlite, which I'd consider to be an unfair comparison.

Re: Beware of Bun.js

#32

Post by retSava »

olliej wrote: post #15

This seems to not be entirely reasonable. [edit: apparently the author is a deno employee but did not choose to disclose such? If so then that throws any moral position they have out the window. The below however is still accurate to my reading of the complaints.] First up is the FFI test. On the one hand I think that this is a legitimate complaint, changing an existing benchmark for your comparisons is always suspec…

They do disclose that now.

Re: Beware of Bun.js

#33

Post by fire »

KerrAvon wrote: post #21
fritolaid wrote: post #10

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…

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

Re: Beware of Bun.js

#34

Post by Scarbutt »

franciscop wrote: post #13

The benchmark, while it seems (without knowing the function specifics) that it is overtesting (testing hash(toptr(n)) instead of just hash(m)), it is the same on both tests so it does feel like a fair comparison? Sure it could be done differently to make a more atomic comparison, but the composite comparison still feels fair if both operations tend to be performed together. Def not an "expose". Overall though, Bun is…

I personally also don't like the direction Deno was taking,

Yeah, the story is:

Deno: Hi, we are a new nodejs alternative without all the mistakes nodejs made.

Bun: Hi

Deno: We are going to adopt all nodejs mistakes.

Re: Beware of Bun.js

#35

Post by Jarred »

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 to run it on your own computer to see for yourself:

    deno run --unstable -A deno.js
    cpu: Apple M1 Max
    runtime: deno 1.26.1 (aarch64-apple-darwin)

    benchmark                        time (avg)             (min … max)       p75       p99      p995
    ------------------------------------------------------------------- -----------------------------
    SELECT \* FROM "Order"          26.3 ms/iter   (25.06 ms … 29.23 ms)  26.74 ms  29.23 ms  29.23 ms
    SELECT \* FROM "Product"       53.91 µs/iter  (52.17 µs … 317.75 µs)     54 µs  65.63 µs  76.75 µs
    SELECT \* FROM "OrderDetail"  269.41 ms/iter (240.72 ms … 308.82 ms) 279.05 ms 308.82 ms 308.82 ms

    bun bun.js
    [0.26ms] ".env"
    cpu: Apple M1 Max
    runtime: bun 0.2.0 (arm64-darwin)

    benchmark                        time (avg)             (min … max)       p75       p99      p995
    ------------------------------------------------------------------- -----------------------------
    SELECT \* FROM "Order"         14.44 ms/iter   (13.71 ms … 17.82 ms)  14.56 ms  17.82 ms  17.82 ms
    SELECT \* FROM "Product"       34.39 µs/iter    (30.46 µs … 4.55 ms)  32.88 µs   48.5 µs  60.13 µs
    SELECT \* FROM "OrderDetail"  148.17 ms/iter  (144.8 ms … 154.92 ms) 149.85 ms 154.92 ms 154.92 ms
Regarding the FFI benchmark, you can see the commit from today here:

https://github.com/oven-sh/bun/commit/40506e33e73018103bcf08...

It threw an error until I googled "Deno pointer ffi", which mentioned this function https://doc.deno.land/deno/unstable/~/Deno.UnsafePointer and that worked. I assumed that `Deno.UnsafePointer.of` is the expected way to get a pointer to a buffer, but it seems that changing the type to "buffer" is a faster way for this case. Will update the page shortly.

Re: Beware of Bun.js

#36

Post by undefined_void »

Jarred wrote: 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…

Thank you for the comment. I'll update the gist with this.

Re: Beware of Bun.js

#37

Post by olliej »

LegionMammal978 wrote: post #31
olliej wrote: post #15

This seems to not be entirely reasonable. [edit: apparently the author is a deno employee but did not choose to disclose such? If so then that throws any moral position they have out the window. The below however is still accurate to my reading of the complaints.] First up is the FFI test. On the one hand I think that this is a legitimate complaint, changing an existing benchmark for your comparisons is always suspec…

> apparently the author is a deno employee but did not choose to disclose such? If so then that throws any moral position they have out the window. It seems like the author disclosed this a couple minutes after you wrote your comment. > The sqlite complaint is not reasonable, if sqlite is being used as a demonstration of wasm performance there is nothing at all wrong with this test Looking at that benchmark, it seems…

> Looking at that benchmark, it seems to be comparing Deno's WASM sqlite to Bun's native bun:sqlite, which I'd consider to be an unfair comparison.

Ah, then I have misunderstood what it's doing - that's hilariously terrible benchmarking, and if so the bun folk should feel bad.

Re: Beware of Bun.js

#39

Post by tmikaeld »

trilbyglens wrote: post #38

Does the world _really_ need another js runtime?

There's benefits to competition as well as choice, if any of the projects fail for any reason, there's another compatible alternative to use.

And now there's three: Deno, Bun and Cloudflare Workers

Re: Beware of Bun.js

#40

Post by olliej »

petesergeant wrote: post #22
troquerre wrote: post #3

There should be a disclaimer that the author works for Deno https://gist.github.com/littledivy

something to bear in mind for sure, but if what they're saying is true, then it really doesn't matter either way?

Agreed, simply having a conflict of interest isn't a reason to disregard the complaints. But the problem is that failing to disclose it up front creates the appearance of dishonesty, which undercuts the message. But it's important for us as readers because it makes us more aware that we should be looking for some of the techniques that can be more confounding or misleading.

I want to be clear, I am not saying that the post is wrong, just that we would know to be more careful in reviewing claims.

Post reply on HN