61–70 of 196 posts
Not rigged at all. Just a joke of a microbenchmark trying to equate a toy with an actual runtime. Bun may be great someday, but right now it’s missing such basic functionality that any benchmark is a farce. Nobody cares that you can quickly ack a request a half million times a sec if you can’t do something as basic as spawn a child process.
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.
> Javascript is plagued with idea that it is slow while it is not. I benchmarked a hello world in .net and node/express, and the .net version was multiple orders of magnitude faster than the node/express version. That's a starting point, and as you add more logic, that gap only grows in my experience. Javascript may be fast _enough_ for many cases, and in a tight JIT loop it may be faster again, but by any measure, j…
Where I think there’s more of a problem is cultural: similarly to Java, there’s a subset of programmers seemingly dedicated to layering abstractions faster than the JIT developers can optimize them.
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.
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.
Earlier quoted context omitted.
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"
It is [1] ( and should be ) pretty well known. 1.3 BILLION page view per month, 6K RPS with 9 ( Fairly Weak ) Servers, Sub 20ms response time with zero caching.
>also wondering what peak RPS is for HN.
Less than 100 RPS for logged in users. The number were pre 2020 but I doubt the current number is significantly higher.
This post doesn’t link to the original benchmark, or any code to verify what’s being suggested. Along with the click-bate heading, I think it’s fairly irrelevant. My assumption is that this is a micro benchmark doing just an echo response, that is so far from what Bun/Deno/Node will ever be used for it’s just a farce. The speed of your application frameworks http server will (almost) never be your bottleneck. Develop…
>This post doesn’t link to the original benchmark Searching Google for the exact text in the slide doesn't yield any results. So perhaps that was part of the post author's angst...that the numbers were presented in a venue where they wouldn't get much scrutiny? Edit: I did find that the author has posted previously about Deno, and seems to not be a fan: https://unetworkingab.medium.com/deno-is-slow-and-why-associ...
It seems like they are promoting their own library and doing a bit of their own deception by including a small library in their tests. Particularly a library that was designed entirely to perform well at that particular usecase (high throughout for small bits of data).
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.
There are too many front-end JS frameworks and now it seems to be leaking to the backend as well in the form of runtimes. I'm just waiting for one of these groups to say "productivity is priority 1, followed by performance/security etc."
Because JS is sort of a nice sedan at its best - truly nice. But if you want a Ferrari, you're at the wrong dealership - that's a "you" problem.
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 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 incompatible ones) actual compilers instead of transpilation BS. Actually good linters and static analysis. Actually good IDEs. The list of things all of these platforms do better than the whole JS/TS nightmare just goes on and on.
What you are getting when you buy JS is isomorphic code with browsers. That is all. DX? Forget it.
So we should intentionally handicap Deno? This is complete nonsense. If Bun wants to come out ahead of Deno, then they should also consider scaling with the number of CPU cores.
Single core CPUs are few and far between those days. Real-world performance is what matters.
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…
I think the benefit of deno or bun aren't as obvious when compared in the context of node on DX matter too.
Most of the tooling and standard library can be used without using the cli and switching runtime.
Tools like tsx simplifies running typescript code directly. It does pretty much what deno does internally using esbuild.
The modularity of runtime doesn't matter to consumers even if it's pretty cool.
FFI and security features are nice but I think the future is running sensitive code as a wasm module directly in separate isolated context.
The browser compatibility is an awesome boost but most bundler will polyfill that for you out of the box and you will use a bundler with either deno or node most of the time. I know polyfilling is not perfect but it's good enough for most.
I want to hear what strong reason people have for choosing to use either bun or deno in production.
I use deno for writing scripts because it's so easy to run them especially if they have any dependencies but outside of that, I haven't reached out for it.
> Deno is a multi-threaded server that utilizes in this test almost 2x the CPU-time while Bun is running single-threaded utilizing only 1x the CPU-time. So we should intentionally handicap Deno? This is complete nonsense. If Bun wants to come out ahead of Deno, then they should also consider scaling with the number of CPU cores. Single core CPUs are few and far between those days. Real-world performance is what matte…