5 ms·

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 rece

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.

dmix 4y ago
These sorts of things also build up over time. Usually when the underlying system is well thought out and performant it’s reflected in higher layers as well.
thinkingkong 4y ago
Its tempting to assume that just because this number is high, that the rest of the dependencies required to meaningfully respond will be equally performant. That is rarely the case. The challenge I have with these positions is that unless you have very specific latency requirements, most of the time youre better off focusing on solving a business problem and then measuring what is slow. Starting off with “well it has to be fast so lets use this brand new thing” is the swan song of the eventually remorseful.
- kotlin2 4y ago
  Bun has a philosophy that everything needs to be fast. Including things like CLI tools and process startup. Process startup being quick is important, especially in a severless environment. I understand your point, but it’d be nice to limit the discussion to Bun and Deno and not other theoretical possibilities.
  - hinkley 4y ago
    I appreciate that Bun wants to be fast, but what I need right now from Bun or Deno is a better concurrency primitive than sendMessage(). I’m so… angry that we waited all this time for a worker threads implementation in Node and what we got was this hot garbage. It’s a toy. There is no sane way to send multiple tasks to the same worker, because the results come back unordered and uncorrelated, unless you build your own layer on top of them. The public API should have been promise based, not event based.
- netheril96 4y ago
  But if the problem is in the framework or the runtime, it is too late to think about the performance AFTER you have tied yourself all up to the slower one.
- liuliu 4y ago
  Agreed. But the problem is not on "fast" but on "brand new". Sometimes, these are equal (because new things often advertising itself as fast alternative). Rare times when this is not equal, fast can be a good choice.
Jenk 4y ago
> But all else equal This is the point GP is making - they (the "junior-wannabe-senior") aren't even thinking of all else, and by focussing purely on the speed of operations are probably using the lesser optimal solution. Facetious example: A is faster than B, shaving a few cycles here and there. But nobody knows how to use A, it's support is lacklustre, and there are many known vulnerabilities that haven't been fixed. B is the most widely used in the industry, support and security is good. Junior-wannabe-senior is picking A because it's faster.
moffkalast 4y ago
> 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.
- hinkley 4y ago
  Also I shouldn’t have to say this but all of the current JavaScript applications have already been written. Switching a large production codebase to a new framework does not dovetail well with modern dev practices, amplifying the pain of doing so.
  - 0xCAP 4y ago
    I don't think application developers are the main target for their product. OTOH, if AWS/GCP/ETC. adopted Bun transparently to run your cloud functions faster and using less resources (thus less $$) that would be a win/win situation for all parties involved.
- jsf01 4y ago
  >use bun >segfault at runtime Bun is far from better in every way

dmix 4y ago

These sorts of things also build up over time. Usually when the underlying system is well thought out and performant it’s reflected in higher layers as well.

thinkingkong 4y ago

Its tempting to assume that just because this number is high, that the rest of the dependencies required to meaningfully respond will be equally performant. That is rarely the case. The challenge I have with these positions is that unless you have very specific latency requirements, most of the time youre better off focusing on solving a business problem and then measuring what is slow. Starting off with “well it has to be fast so lets use this brand new thing” is the swan song of the eventually remorseful.

kotlin2 4y ago
Bun has a philosophy that everything needs to be fast. Including things like CLI tools and process startup. Process startup being quick is important, especially in a severless environment. I understand your point, but it’d be nice to limit the discussion to Bun and Deno and not other theoretical possibilities.
- hinkley 4y ago
  I appreciate that Bun wants to be fast, but what I need right now from Bun or Deno is a better concurrency primitive than sendMessage(). I’m so… angry that we waited all this time for a worker threads implementation in Node and what we got was this hot garbage. It’s a toy. There is no sane way to send multiple tasks to the same worker, because the results come back unordered and uncorrelated, unless you build your own layer on top of them. The public API should have been promise based, not event based.
netheril96 4y ago
But if the problem is in the framework or the runtime, it is too late to think about the performance AFTER you have tied yourself all up to the slower one.
liuliu 4y ago
Agreed. But the problem is not on "fast" but on "brand new". Sometimes, these are equal (because new things often advertising itself as fast alternative). Rare times when this is not equal, fast can be a good choice.

Jenk 4y ago

> But all else equal This is the point GP is making - they (the "junior-wannabe-senior") aren't even thinking of all else, and by focussing purely on the speed of operations are probably using the lesser optimal solution. Facetious example: A is faster than B, shaving a few cycles here and there. But nobody knows how to use A, it's support is lacklustre, and there are many known vulnerabilities that haven't been fixed. B is the most widely used in the industry, support and security is good. Junior-wannabe-senior is picking A because it's faster.

moffkalast 4y ago

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

hinkley 4y ago
Also I shouldn’t have to say this but all of the current JavaScript applications have already been written. Switching a large production codebase to a new framework does not dovetail well with modern dev practices, amplifying the pain of doing so.
- 0xCAP 4y ago
  I don't think application developers are the main target for their product. OTOH, if AWS/GCP/ETC. adopted Bun transparently to run your cloud functions faster and using less resources (thus less $$) that would be a win/win situation for all parties involved.
jsf01 4y ago
>use bun >segfault at runtime Bun is far from better in every way