5 ms·

This is a very good point. In many projects, performance is not just relevant. Of course it makes sense to follow good practices and not make things slow on pur

This is a very good point. In many projects, performance is not just relevant. Of course it makes sense to follow good practices and not make things slow on purpose, but thinking a lot about performance when it is not exactly a goal doesnt make sense. On startups, I think there is a fine balance. You have to focus on many things, performance might be critical or might not depending on the business case. You have to think about where to spend your focus.

IshKebab 7y ago
I disagree. Performance is almost always an implicit goal. People don't state it very often because it's so obvious. Why wants slow software? But more importantly this article is a rebuttal to people saying "we can optimise performance at the end". They aren't saying "We never intended for it to be fast and we aren't going to bother trying to do that." they're saying that performance is a goal. Look at the examples he screenshotted. Nobody says "dude, performance isn't a goal of this project; you just have to live with it being slow".
- 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.

IshKebab 7y ago

I disagree. Performance is almost always an implicit goal. People don't state it very often because it's so obvious. Why wants slow software? But more importantly this article is a rebuttal to people saying "we can optimise performance at the end". They aren't saying "We never intended for it to be fast and we aren't going to bother trying to do that." they're saying that performance is a goal. Look at the examples he screenshotted. Nobody says "dude, performance isn't a goal of this project; you just have to live with it being slow".

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.