4 ms·

Good enough performance is the goal. If the latency is 100-200ms, then it is often not a big problem if your request cycle is 30ms instead of 3ms. Unless you ex

by cies 7y ago

Good enough performance is the goal. If the latency is 100-200ms, then it is often not a big problem if your request cycle is 30ms instead of 3ms. Unless you expect heaps of traffic, then the 10x performance improvement means a lot.

RL_Quine 7y ago
Lets be realistic, no "apps", front end websites etc are hitting sub-second latencies for anything. Hacker News, and the linked article are stark exceptions where the page load itself was under 200ms for me. Posting this comment of course took about 3 seconds. The amount of latency in the modern web is fairly astounding if we're being honest.
- cies 7y ago
  > Lets be realistic Ok. > no "apps" Sure? > Hacker News, and the linked article are stark exceptions where the page load itself was under 200ms for me So let's be realistic (sorry :) ), it is possible, but it needs to be a strong requirement up front as its going to dictate a lot of choices that are hard to re-evaluate down the road. > The amount of latency in the modern web is fairly astounding if we're being honest. We can totally high-five on that one. One thing I feel contributes here is that good devs are expensive. So we prefer them to use tools that help m to deliver quickly. Super low latency stuff usually incurs build times, this is not making your devs more efficient. Also less good devs find it often harder to produce optimized code "by default".
  - RL_Quine 7y ago
    I can’t work out if you’re attempting to be a dramatization of the problem or not. Low latency developing “incurring build times” in particular doesn’t make a lot of sense. It just takes considered design, nothing about the result is necessarily expensive.
    - cies 7y ago
      I've programmed web stuff in rust and in rails. i can tell you that build times (and REPL on error, and a console with DB connectivity, and lots of pre-existing modules/libs/plugins) do matter. We can get all that stuff in Rust (C/C++/Zig) too, but it is simply not there yet. Only Go is both run time efficient AND compile time efficient. My point: all is possible at unlimited resources, but that's unrealistic.
      - loopz 7y ago
        Go is a delight to work with, if you solve new problems in your own way. Not so much unfortunately solving same old problems again, ie. SOAP/XML and similar.

by cies 7y ago

RL_Quine 7y ago

Lets be realistic, no "apps", front end websites etc are hitting sub-second latencies for anything. Hacker News, and the linked article are stark exceptions where the page load itself was under 200ms for me. Posting this comment of course took about 3 seconds. The amount of latency in the modern web is fairly astounding if we're being honest.

cies 7y ago
> Lets be realistic Ok. > no "apps" Sure? > Hacker News, and the linked article are stark exceptions where the page load itself was under 200ms for me So let's be realistic (sorry :) ), it is possible, but it needs to be a strong requirement up front as its going to dictate a lot of choices that are hard to re-evaluate down the road. > The amount of latency in the modern web is fairly astounding if we're being honest. We can totally high-five on that one. One thing I feel contributes here is that good devs are expensive. So we prefer them to use tools that help m to deliver quickly. Super low latency stuff usually incurs build times, this is not making your devs more efficient. Also less good devs find it often harder to produce optimized code "by default".
- RL_Quine 7y ago
  I can’t work out if you’re attempting to be a dramatization of the problem or not. Low latency developing “incurring build times” in particular doesn’t make a lot of sense. It just takes considered design, nothing about the result is necessarily expensive.
  - cies 7y ago
    I've programmed web stuff in rust and in rails. i can tell you that build times (and REPL on error, and a console with DB connectivity, and lots of pre-existing modules/libs/plugins) do matter. We can get all that stuff in Rust (C/C++/Zig) too, but it is simply not there yet. Only Go is both run time efficient AND compile time efficient. My point: all is possible at unlimited resources, but that's unrealistic.
    - loopz 7y ago
      Go is a delight to work with, if you solve new problems in your own way. Not so much unfortunately solving same old problems again, ie. SOAP/XML and similar.