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

161–170 of 196 posts

Re: Deno vs. Bun performance is rigged

#161

Post by toastercat »

bornfreddy wrote: post #25
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…

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…

Kinda devil's advocate, but I've met several senior-should-be-junior cargo-culting devs who swear by popular tools that are objectively slower than alternatives, instead of actually taking the time to evaluate the less popular alternatives to see if the lack of surrounding ecosystem will actually affect their project. The result is a death by a thousand cuts, because they auto-pilot to "what is everyone else using"?

Re: Deno vs. Bun performance is rigged

#162

Post by toastercat »

nazka wrote: post #111
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 agree. PReact for instance comes to my mind. But it’s faster! And? And is it really in a business web app and not just a printf(« hello world »)? Does it matter that much? Do they have as many dev working on it? What about edge cases? More than anything for this type of change does your faster magic new thing has even an ecosystem?

The answer to all your questions are "it depends". Context matters. To be honest, Preact would probably be a better fit for most projects using React.

Re: Deno vs. Bun performance is rigged

#163

Post by leeoniya »

toastercat wrote: post #161
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…

Kinda devil's advocate, but I've met several senior-should-be-junior cargo-culting devs who swear by popular tools that are objectively slower than alternatives, instead of actually taking the time to evaluate the less popular alternatives to see if the lack of surrounding ecosystem will actually affect their project. The result is a death by a thousand cuts, because they auto-pilot to "what is everyone else using"?

> to see if the lack of surrounding ecosystem will actually affect their project

for projects of any significant size, that answer is a resounding "yes".

Re: Deno vs. Bun performance is rigged

#164

Post by burntsushi »

> Please - verify, verify, verify and think critically about what you read.

If you're going to excoriate someone for an improper benchmark, and then provide one of your own and advise your audience to "verify," then it might be wise to include instructions for how to reproduce your results.

Re: Deno vs. Bun performance is rigged

#165

Post by sorokod »

toastercat wrote: post #161
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…

Kinda devil's advocate, but I've met several senior-should-be-junior cargo-culting devs who swear by popular tools that are objectively slower than alternatives, instead of actually taking the time to evaluate the less popular alternatives to see if the lack of surrounding ecosystem will actually affect their project. The result is a death by a thousand cuts, because they auto-pilot to "what is everyone else using"?

Putting aside who-wants-to-be-what, a change in a common tech stack is a serious change with all sorts of implications. Arguments for and against should be carefully considered, and yes "going faster can't hurt" is not an argument.

Re: Deno vs. Bun performance is rigged

#166

Post by imjonse »

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…

Even when considering benchmarking errors, performance can be more objectively measured than developer ergonomics, good architecture, clear API and documentation, good implementation and other aspects that usually matter more than performance. It is usually the fun and immediately gamifiable aspect that more junior developers can and do easily optimize for.

Re: Deno vs. Bun performance is rigged

#167

Post by bornfreddy »

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…

It seems we are talking past each other.

Typing is the base for many reasons I love FastAPI, so yes it is useful. And I speak as someone who has used it in production on multiple projects, and even converted some from Flask (but not because of speed).

Far from "fast to get going", starting with FastAPI is slower actually, but it takes you further (as you pointed out). The train of thought that "typing" leads to "fast to get going" which leads to "fast" in the name... Let's say I don't buy it.

The link to "performance" is difficult to miss, I don't think that is a coincidence. And it's OK. If this is what matters to devs that much, they would be stupid not to highlight it. I'm actually happy people are using it, even if for the "wrong" reasons.

Re: Deno vs. Bun performance is rigged

#168

Post by TobyTheDog123 »

jpgvm wrote: post #123
TobyTheDog123 wrote: post #91

Earlier quoted context omitted.

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…

My usual project stack is React Native (+React Native Web) to cover iOS/Android/Windows/Mac/Web all in one repo, with serverless functions (Workers/C@E/etc) on the API side in another, and with shared types between the two as a third.

However I have different business goals where I can actually take some time to choose a non-TS stack...

... but unfortunately with those kind of goals/restrictions the choices aren't really there, afaik.

On the client-side, you have Flutter, which is cool enough (No JS, everything in a canvas), but I'm not Dart's biggest fan, and there's no Dart WASM target yet to be able to write in one language for both (and share types).

On the server-side, most cloud companies only support Javascript + Rust + WASM, and WASM just isn't mature enough yet where it's not a total pain to work with (I think it'll get there at some point though)

So I'm left pretty much where you are, my last and only hope is a Typescript monorepo.

Re: Deno vs. Bun performance is rigged

#169

Post by toastercat »

sorokod wrote: post #165
toastercat wrote: post #161

Earlier quoted context omitted.

Kinda devil's advocate, but I've met several senior-should-be-junior cargo-culting devs who swear by popular tools that are objectively slower than alternatives, instead of actually taking the time to evaluate the less popular alternatives to see if the lack of surrounding ecosystem will actually affect their project. The result is a death by a thousand cuts, because they auto-pilot to "what is everyone else using"?

Putting aside who-wants-to-be-what, a change in a common tech stack is a serious change with all sorts of implications. Arguments for and against should be carefully considered, and yes "going faster can't hurt" is not an argument.

Mostly agree; if you're a Java shop, maybe stick to Java instead of confusing all of your engineers just because you read on HN how much faster Golang can be. But again, YMMV.

Re: Deno vs. Bun performance is rigged

#170

Post by leeoniya »

xaduha wrote: post #143
user432678 wrote: post #141

Earlier quoted context omitted.

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

https://just.billywhizz.io/blog/
Post reply on HN