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

121–130 of 196 posts

Re: Deno vs. Bun performance is rigged

#121

Post by coder543 »

bornfreddy wrote: post #58
lillecarl wrote: post #38

Earlier quoted context omitted.

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

Maybe - in that case I'm judging them wrongly. But flask (the king they dethroned) was faster to get going (with less features, granted) and their docs feature "Performance" [0] rather prominently. Note that I don't hold this against them. They simply understand what makes the devs pick them and adjusted their market strategy accordingly. It would be nice if they didn't have to though. [0] https://fastapi.tiangolo.co…

Flask is faster to get going in what way? Writing types instantly saves you a ton of time and effort right out of the gate.[0]

And if your framework is faster, then of course you're going to mention it. Do you really think Flask or Django wouldn't point out that they were fast, if they were? I'm quite sure they would, since it's not shameful to educate the reader on what your framework offers compared to the competition, but they can't, because they're not.

Your link goes to the very bottom of that page, so is it really prominently featured compared to everything else they're trying to sell you on? It really doesn't seem like it. More convincing would be pointing to their list of "key features" at the top, which does mention performance first, but then quickly focuses back on "Fast to code" and "Fewer bugs".

[0]: https://news.ycombinator.com/item?id=33224324

Re: Deno vs. Bun performance is rigged

#122

Post by douglaswlance »

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…

Claiming they're the fastest is a big marketing edge. It doesn't matter if they're only the fastest by 0.00001%.

Re: Deno vs. Bun performance is rigged

#123

Post by jpgvm »

TobyTheDog123 wrote: post #91
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…

You're getting downvoted, but I absolutely agree that the ecosystem is a problem. It's not the JS/TS language/syntax that is the problem per-se, but all the tooling that needs to exist around it for a decent DX. NPM, Yarn, Babel, Webpack, TSC, ESLint, Prettier, even VSCode itself all contribute to an ecosystem that is a nightmare if you are trying to do anything outside of a handful of common scenarios Tooling like V…

Yeah definitely. Typescript is passable, even has some decently cool stuff like discriminating unions which would be nice to have more widespread. The tooling however is just awful.

I'm trying to make it palatable with Bazel + rules_js/rules_ts and pnpm but even so still end up needing Babel and Webpack because browsers are a thing. This stack does make the build times somewhat more reasonable and actually manages to avoid too much wasted work locally/CI but boy does it take a lot of work to get done.

The time I'm investing in making a Typescript monorepo viable will pay off but only when compared to not implementing my changes and staying with TS, the comparison to simply not using the stack and using something better to solve our non-Typescript specific business problems would rather lopsided.

Re: Deno vs. Bun performance is rigged

#124

Post by O5vYtytb »

bornfreddy wrote: post #58
lillecarl wrote: post #38

Earlier quoted context omitted.

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

Maybe - in that case I'm judging them wrongly. But flask (the king they dethroned) was faster to get going (with less features, granted) and their docs feature "Performance" [0] rather prominently. Note that I don't hold this against them. They simply understand what makes the devs pick them and adjusted their market strategy accordingly. It would be nice if they didn't have to though. [0] https://fastapi.tiangolo.co…

flask took the approach of only providing basic funtionality and relying on 3rd party packages for things like openapi docs and thr like. fastapi has a lot more included and it makes the common tasks like documenting your api easier and more consistent

Re: Deno vs. Bun performance is rigged

#125

Post by phillipcarter »

coder543 wrote: post #105
phillipcarter wrote: post #96

Earlier quoted context omitted.

Is it really that big of a deal that you can do @app.post("/foo") instead of @app.route("/foo", methods=["POST"]) ?

That's not what anyone is talking about. Take this example from their docs: @app.get("/items/{item_id}") async def read_item(item_id: int, q: Union[str, None] = None): return {"item_id": item_id, "q": q} You are declaring the types of the parameters, and FastAPI parses and enforces them for you. This saves quite a bit of code, and lets you focus on your business logic. Writing the code this way also allows FastAPI to…

Properly supporting async seems like the main reason why it's taken off.

Re: Deno vs. Bun performance is rigged

#126

Post by tln »

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%.

Re: Deno vs. Bun performance is rigged

#127

Post by euos »

redox99 wrote: post #51
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…

I disagree. If we're talking of microbenchmarks focused on 100k rps or whatever that are mostly IO/syscall limited, sure. But if it's that JS execution is outright faster, it's a big deal. People here handwave "oh, your business doesn't require more than 10rps". Sure. But rps is just half the story, latency is the other. I'll give you two examples 1) SSR with something like Material UI is slow , especially because of…

You may be able to slash SSR from 200ms to 195ms by using a different JS runtime. Or you may slash it to 100ms by rewriting and optimizing code (caching and such). Resources are limited. You either do one or the other.

Re: Deno vs. Bun performance is rigged

#128

Post by FlorianRappl »

jddil wrote: post #34

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.

I fully agree. Played around with Bun quite a bit, but any benchmark is meaningless until it has all the features and stability to have it production ready. Until then it's just a promising (and very respectful) start - but nothing more.

Re: Deno vs. Bun performance is rigged

#129

Post by coder543 »

phillipcarter wrote: post #125
coder543 wrote: post #105

Earlier quoted context omitted.

That's not what anyone is talking about. Take this example from their docs: @app.get("/items/{item_id}") async def read_item(item_id: int, q: Union[str, None] = None): return {"item_id": item_id, "q": q} You are declaring the types of the parameters, and FastAPI parses and enforces them for you. This saves quite a bit of code, and lets you focus on your business logic. Writing the code this way also allows FastAPI to…

Properly supporting async seems like the main reason why it's taken off.

You think no one cares about the convenience of having the type system do a lot of the work for you? Or being able to autogenerate client libraries? I find that position confusing.

Proper async support is decently important to me in any language or framework, but in the real world, I haven't often run into other developers who care much about that.

Re: Deno vs. Bun performance is rigged

#130

Post by jpgvm »

jesse__ wrote: post #113
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…

Completely agree. I use C and C++ on a day to day basis, which has an extremely bad rap in the DX department. Even coming from languages that, by and large, have very poor DX, I find the JS and TS ecosystems to be intolerable. The tooling is extremely slow, buggy, and often produces straight-up incorrect results.

I originally came from a C background where the tooling is essentially the worst in the business (embedded) so yeah, I definitely know what poor DX looks like lol.

For me I would pick that again over the current state of Typescript/Javascript tooling. Atleast I felt like I had some semblance of sanity even when cobling together piles of CMake.

Post reply on HN