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

Deno vs. Bun performance is rigged

unetworkingab.medium.com

Post reply on HN
Print view View original

41–50 of 196 posts

Re: Deno vs. Bun performance is rigged

#41

Post by BiteCode_dev »

lillecarl wrote: post #38
bornfreddy wrote: post #25

Earlier quoted context omitted.

You'd be surprised. I've had countless battles with (junior-wannabe-senior) devs who wanted to use a different framework simply because it is "fast". When you point out that this project will be a huge success if it has 10 req/s, the usual answer is "well it doesn't hurt", when it truth it does - if nothing else, because it diverts discussion from important matters (like consistency of the company's tech stack) to ir…

I've thought of the fastapi name as that it's fast to get going with rather than speed, it's python after all.

That's my take on it as well. Fast apu does use asyncio which may have speed avantages in some circonstances. But the main takeaway and the killer feature is the fact you build your api just declaring functions signatures.

Re: Deno vs. Bun performance is rigged

#42

Post by kotlin2 »

thinkingkong wrote: post #5

Im surprised performance at this level even matters to most folks. Like if you truly thought this microbenchmark was the reason to choose one runtime over another Id be shocked. It makes it equally surprising that this error from the Deno crew, who should all know better. In either case, I hope they announce a correction and move on to more important matters. If youre trying to shave another tiny bit of rps out of yo…

But all else equal, wouldn’t you want the fastest option available? Also, it’s not just about raw qps. When a client connects to your app, you want them to receive data as quickly as possible so that they get the best user experience. That’s true wether you have 1 qps or 100,000. Having a development philosophy that every part of the stack must run quickly is attractive.

Re: Deno vs. Bun performance is rigged

#43

Post by swyx »

pier25 wrote: post #10
thinkingkong wrote: post #5

Im surprised performance at this level even matters to most folks. Like if you truly thought this microbenchmark was the reason to choose one runtime over another Id be shocked. It makes it equally surprising that this error from the Deno crew, who should all know better. In either case, I hope they announce a correction and move on to more important matters. If youre trying to shave another tiny bit of rps out of yo…

Exactly. Very few companies will need to reach 1000 reqs/s consistently, let alone 100k reqs/s. StackOverflow peaks at about 6000 reqs/s and it's an extremely popular website.

got a source for this stackoverflow peak?

also wondering what peak RPS is for HN. i feel like most (non consumer) startups would be like "ok if its good enough for HN its good enough for me"

Re: Deno vs. Bun performance is rigged

#44

Post by redleggedfrog »

pier25 wrote: post #10
thinkingkong wrote: post #5

Im surprised performance at this level even matters to most folks. Like if you truly thought this microbenchmark was the reason to choose one runtime over another Id be shocked. It makes it equally surprising that this error from the Deno crew, who should all know better. In either case, I hope they announce a correction and move on to more important matters. If youre trying to shave another tiny bit of rps out of yo…

Exactly. Very few companies will need to reach 1000 reqs/s consistently, let alone 100k reqs/s. StackOverflow peaks at about 6000 reqs/s and it's an extremely popular website.

...that runs on .NET. :^P

Re: Deno vs. Bun performance is rigged

#45

Post by [deleted] »

Jarred wrote: post #30
asojfdowgh wrote: post #24

And the original benchmarks of bun vs deno had bun using a native-code http server against a deno using a js-code http server, afaik. And the bun-specific-fork-of-react vs deno + normal react, was suspect too.

When you import “react-dom/server” in Node, it actually loads “react-dom/server.node.js” When you import “react-dom/server” in browsers or Deno, it loads “react-dom/server.browser.js” When you import “react-dom/server” in Bun, it will load “react-dom/server.bun.js”. https://twitter.com/sebmarkbage/status/1560609478227030016

[deleted]

Re: Deno vs. Bun performance is rigged

#46

Post by onlywicked »

Ygg2 wrote: post #40
lucasyvas wrote: post #32

If you care about performance that much you should be using neither. What you are buying into with these is DX, including features and language portability with other parts of your stack. As long as they are the same overall performance class, it doesn't matter.

DX? What's that?

Developer Experience

Re: Deno vs. Bun performance is rigged

#47

Post by EamonnMR »

Ygg2 wrote: post #40
lucasyvas wrote: post #32

If you care about performance that much you should be using neither. What you are buying into with these is DX, including features and language portability with other parts of your stack. As long as they are the same overall performance class, it doesn't matter.

DX? What's that?

Maybe Developer Experience?

Re: Deno vs. Bun performance is rigged

#48

Post by dmix »

kotlin2 wrote: post #42
thinkingkong wrote: post #5

Im surprised performance at this level even matters to most folks. Like if you truly thought this microbenchmark was the reason to choose one runtime over another Id be shocked. It makes it equally surprising that this error from the Deno crew, who should all know better. In either case, I hope they announce a correction and move on to more important matters. If youre trying to shave another tiny bit of rps out of yo…

But all else equal, wouldn’t you want the fastest option available? Also, it’s not just about raw qps. When a client connects to your app, you want them to receive data as quickly as possible so that they get the best user experience. That’s true wether you have 1 qps or 100,000. Having a development philosophy that every part of the stack must run quickly is attractive.

These sorts of things also build up over time. Usually when the underlying system is well thought out and performant it’s reflected in higher layers as well.

Re: Deno vs. Bun performance is rigged

#49

Post by kitd »

naillo wrote: post #13
ex3ndr wrote: post #7

Earlier quoted context omitted.

Javascript is plagued with idea that it is slow while it is not. Many devs now have PTSR after arguing day after day that javascript is a good thing and not slow. Performance is a very important thing in js world for a peace of mind of devs.

To be fair it did used to be quite slow. But that was like 10 years ago. General awareness hasn't caught up to the huge engineering efforts it seems.

Ikr. You can regularly read some random dev tell the world "interpreted" Java is "too slow" for them.

Re: Deno vs. Bun performance is rigged

#50

Post by echopom »

lucasyvas wrote: post #32

If you care about performance that much you should be using neither. What you are buying into with these is DX, including features and language portability with other parts of your stack. As long as they are the same overall performance class, it doesn't matter.

> If you care about performance that much you should be using neither.

Unfortunately by the time the coding industry understand this , we'll already have a fifth JS runtime that will promise to solve all the performance issues that exist within the 4 others...

Node.JS / Electron are some of my most favorite tech , but if I need performance I'll go with Kotlin / Go / Rust , it's just simpler IMHO.

Post reply on HN