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

141–150 of 196 posts

Re: Deno vs. Bun performance is rigged

#141

Post by user432678 »

LunaSea wrote: post #134
maccard wrote: post #103

Earlier quoted context omitted.

I'm afraid it was a while back so I don't have it to hand, but what I do have is the techempower benchmarks [0] which show about a 10x difference between asp.net or go, and all of the js options. I'm not going to claim they're perfect, and would be happy if you could provide some info that supports your argument? [0] https://www.techempower.com/benchmarks/#section=data-r21

JavaScript is ranked 5th on the ranking you linked to. 4 ranks before .Net.

Just-js is not really a Javascript: https://github.com/just-js/just. .Net in that list much closer to what everyone assumes.Net is.

Re: Deno vs. Bun performance is rigged

#142

Post by simpsond »

m00x wrote: post #108
detaro wrote: post #71

Earlier quoted context omitted.

And a real-world deployment of a single-threaded interpreter just runs multiple instances of it, so do and compare that. No need to "handicap" anything.

But then you need twice the initial app memory. This can be substantial for larger apps. There are definitely benefits of using multiple cores at once on a single app.

Copy on write fork mitigates some of that.

Re: Deno vs. Bun performance is rigged

#143

Post by xaduha »

user432678 wrote: post #141
LunaSea wrote: post #134

Earlier quoted context omitted.

JavaScript is ranked 5th on the ranking you linked to. 4 ranks before .Net.

Just-js is not really a Javascript: https://github.com/just-js/just . .Net in that list much closer to what everyone assumes.Net is.

Looks like Javascript to me

https://github.com/TechEmpower/FrameworkBenchmarks/tree/mast...

Re: Deno vs. Bun performance is rigged

#144

Post by rwalle »

jpgvm wrote: post #67
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 are buying into JS/TS the very last thing you are getting is DX. I have never worked with such a low quality ecosystem ever before and I hope I won't have to endure it for too much longer. If you want DX you are better off with JVM, Rust or something similarly well designed. Hell, Go has better DX than JS/TS and that is a pretty low bar. Real build systems, real module systems (instead of like 3 competing inco…

LOL

I have done front end development for hobby and professionally for over a decade. I can confirm that this guy does not understand the history, limitation and complexity of tooling around the ecosystem and is just here being uninformed and whining. Phrases like "real compiler" tell enough about people who mostly work in the back end that do not understand how the real world works for web.

Or let me ask this question: How would you change all this? Why would people find it better than the current status, and that proposal be universally adopted? And I am pretty sure you can't give a convincing answer. Because if it existed, people would have adopted it. Maybe you don't think this way, but there are a lot of smart people in this ecosystem and think about it a lot.

By the way, we have come a long way and are still much better than 2000s or early 2010s for many many reasons. I don't see any acknowledgement of that.

Re: Deno vs. Bun performance is rigged

#145

Post by azakai »

jesse__ wrote: post #101
geysersam wrote: post #37

Earlier quoted context omitted.

No realistic , decently written, js application would be "orders of magnitude" faster if rewritten in .net.

Maybe not .net, but I've worked on 3D graphics in the browser and can say with confidance that rewriting your app in C or C++ could see orders of magnitude perf increase over JS.

There is often a speedup, but maybe not by orders of magnitude. I've usually seen 2x-3x or so.

Re: Deno vs. Bun performance is rigged

#146

Post by jmartin2683 »

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…

It matters to the guy paying the AWS bill... or anyone who cares about their ecological impact. We have a duty to utilize resources as efficiently as possible, no different than anyone else. Building every new project on top of a mountain of abstraction that pushes resource utilization to few orders of magnitude beyond what is actually necessary to do the job is financially stupid at the least and socially irresponsible at worst.

If you're an auto manufacturer and you discover something like fuel injection that will dramatically improve efficiency for your customers (the people paying that bill), not doing so makes you a terrible engineer. The 'developer velocity' argument is pure BS... there's absolutely no direct (or even really indirect) correlation there. If the ones you have need someone else to write 9 libraries so that they can build a REST API, you need better engineers.

Re: Deno vs. Bun performance is rigged

#147

Post by donio »

kristoff_it wrote: post #12

I think nobody should be surprised that two startups competing for more or less the same space end up fighting over benchmarks. My recommendation is to ignore all benchmarks altogether and simply run the tests yourself.

Or to be on the safe side just ignore both products. Too much drama for my taste.

Re: Deno vs. Bun performance is rigged

#148

Post by jsf01 »

moffkalast wrote: post #63
kotlin2 wrote: post #42

Earlier quoted context omitted.

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.

> all else equal All else is never equal. The level of adoption and support is what drives decisions in the end. That's why everyone still uses Node when Bun is probably better in every way.

>use bun

>segfault at runtime

Bun is far from better in every way

Re: Deno vs. Bun performance is rigged

#149

Post by jpgvm »

rwalle wrote: post #144
jpgvm wrote: post #67

Earlier quoted context omitted.

If you are buying into JS/TS the very last thing you are getting is DX. I have never worked with such a low quality ecosystem ever before and I hope I won't have to endure it for too much longer. If you want DX you are better off with JVM, Rust or something similarly well designed. Hell, Go has better DX than JS/TS and that is a pretty low bar. Real build systems, real module systems (instead of like 3 competing inco…

LOL I have done front end development for hobby and professionally for over a decade. I can confirm that this guy does not understand the history, limitation and complexity of tooling around the ecosystem and is just here being uninformed and whining. Phrases like "real compiler" tell enough about people who mostly work in the back end that do not understand how the real world works for web. Or let me ask this questi…

I'm not uniformed, I am aware better solutions don't currently exist for the frontend.

This however is a thread about using TS/JS on the backend as a web server and I think you will find all my arguments perfectly valid in that context.

Saying "Javascript tooling is better in 2022 than in 2000" is a useless statement even if true when saying "Javascript tooling is vastly inferior to JVM tooling" is also valid in 2022.

Just because it's better than it was doesn't make it good.

Re: Deno vs. Bun performance is rigged

#150

Post by locutous »

maccard wrote: post #103
kaba0 wrote: post #59

Earlier quoted context omitted.

I’m sorry, but I simply don’t buy that. You either measured something unrelated (e.g. framework), or it was a faulty benchmark for some other reason.

I'm afraid it was a while back so I don't have it to hand, but what I do have is the techempower benchmarks [0] which show about a 10x difference between asp.net or go, and all of the js options. I'm not going to claim they're perfect, and would be happy if you could provide some info that supports your argument? [0] https://www.techempower.com/benchmarks/#section=data-r21

And yet the top js entry is above all c# and go entries. It takes the top overall on the composite score.

Not that it is representative of actual use cases. Can't use just-js in production as it's hyper optimized for this benchmark rather than a work horse. But it does provide a better view of what is possible if the work is put in.

Post reply on HN