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

191–196 of 196 posts

Re: Deno vs. Bun performance is rigged

#191

Post by jmartin2683 »

xyzzy123 wrote: post #188
jmartin2683 wrote: post #146

Earlier quoted context omitted.

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 irresponsi…

For apps that are not successful, the entire output is waste, and the majority of the emissions burden is carbon output of the developers. For work of speculative value (most startups...), optimising for dev efficiency is IMHO the right thing to do.

The only problem is that then you end up married to your mountain of abstractions. Designing things to work as intended from the outset is, in my experience, always the better path. It’s like ‘buy once, cry once’ for technical debt/effort.

Re: Deno vs. Bun performance is rigged

#192

Post by andirk »

squeaky-clean wrote: post #155
andirk wrote: post #109

Earlier quoted context omitted.

Javascript isn't Java. Javascript follows ECMAScript, which also isn't Java. And ECMAScript isn't a language.

I don't know if they were making a JS joke but I have legitimately had newer programmers tell me that Java is an interpreted language because it compiles to a bytecode language which is interpreted by the JVM. Inversely I've had people argue that JS and Python are compiled languages because their interpreters convert statements into bytecode before executing them. When someone starts trying to argue those points I fi…

Describing Javascript can be confusing. C++ compiles -> C compiles -> assembly language compiles -> 1-for-1 to machine code. But Javascript be like "Javascript is the programming language interacts with your browser" or "Javascript conforms to the ECMAScript specification that describes how the language should act but is implemented according to the browser vendor's interpretation of said specification, and is further compiled according the browser." And that only covers browsers' Javascript.

And I'm not even sure if the above is 100% accurate.

Re: Deno vs. Bun performance is rigged

#193

Post by user432678 »

billywhizz wrote: post #181
xaduha wrote: post #143

Earlier quoted context omitted.

Looks like Javascript to me https://github.com/TechEmpower/FrameworkBenchmarks/tree/mast...

it is! people who love bashing JavaScript always come up with this line that just-js "is not JavaScript". ¯\_(ツ)_/¯

Oh, come on! I am in fact a front end developer. And when I saw the result first time a few years ago, I was surprised and wanted to use this “just JS”, but the reality was quite far from what I was expecting. It might look like JS, but if you check the source code of the app for the benchmark, you’ll realise that it looks more like C or C++.

More details in this thread: https://github.com/just-js/just/issues/5

Re: Deno vs. Bun performance is rigged

#194

Post by m00x »

simpsond wrote: post #142
m00x wrote: post #108

Earlier quoted context omitted.

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.

It's not clear what OP is saying. I assumed multiple container instances, but even then, CoW isn't as efficient.

Re: Deno vs. Bun performance is rigged

#195

Post by hayd »

tln wrote: post #126
xaduha wrote: post #90

Gotta mention https://www.techempower.com/benchmarks/#section=data-r21&tes... is these threads always.

...and the fastest server is javascript. https://github.com/just-js/just Not that you should choose it over node or bun.sh or deno. I look forward to seeing where bun.sh ends up on the chart. Currently (well, as of the last benchmark, in July) deno is 0.9%-1.6% of the speed of the fastest options, while faster node options are around 20-40%.

That's pretty shocking. Both that deno is so behind and just is so ahead (even rust/C).

Would love to read what is going on here / what just is doing so much better than deno. I think deno is using a pure js server in that benchmark (vs it's newest/unstable ffi-based one) but, even still, 1% is awful.

Re: Deno vs. Bun performance is rigged

#196

Post by blooalien »

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.

Also what I thought … and indeed turns out to be the case in actual usage. It's quite fast to get a usable API up and running with FastAPI, starting from zero to the point of making useful requests to the API and getting back useful data. The actual speed of API access itself (the response times for the requests, etc) has never really been an issue I've wrestled with (me not being Twitter, etc. and not needing zillions of requests per second).
Post reply on HN