4 ms·

Why isn't this a defect? It brought OP's transfer speed over Ethernet to 2.5MB/s.

tptacek 4y ago
It's an option, with a default. Arguably (I mean, I'd argue it, other reasonable people would disagree), Go's default is the right one for most circumstances. That's not a "defect"; it's a design decision people disagree with.
- rdslw 4y ago
  you clearly (in this post and yours others) did not read OP and other comments on this thread where it's documented that it WAS NOT design decision. why use it as an argument where it's written it was NOT by design. the same with LFS -> this post clearly shows detriment to LFS usage, and probably many other tools written with golang. 'most circumstances': prove it, or dont use.
loeg 4y ago
If there is a defect, it's in git-lfs. Picking a reasonable default is not a defect.
- maxbond 4y ago
  It being reasonable is what's in dispute.
  - tptacek 4y ago
    Not really, not on this thread. The debate is valid (though maybe not in this hyperbolic framing), but this is subthread where I'm responding to someone who "picked their jaw up off the floor" at this "defect" of a very obvious default in the Go standard library that has been there I think since its inception, as if no network software in the history of software had ever deliberately disabled Nagle, rather than that being literally standard socket programming advice for decades. (Again, being standard advice doesn't make it not debatable!)
    - maxbond 4y ago
      I. Don't at all understand this comment. You don't own this subthread? I don't really even really recognize the boundaries of subthreads from the larger thread, at least not in the way you're suggesting? The article is about surprising consequences of this decision. This being a "good default" is very much a subject of contention in this discussion. > (Again, being standard advice doesn't make it not debatable!) This seems to accept my premise that it's what's in dispute?
      - deleted 4y ago
        [deleted]
      - tptacek 4y ago
        I don't claim to own the thread, but since you've jumped in to respond on behalf of the other person I responded to, I'm going to to tell you again that what you want to talk about here isn't what I'm here to talk about. There are plenty of other subthreads here talking about whether disabling Nagle by default is a good thing or not; maybe join one of them.
        maxbond 4y ago
        I'm not responding on anyone's behalf. I think your attitude here is really weird. You are in fact asserting that you are the arbiter of what can be discussed in this subthread. If you don't want to discuss what I'm discussing - just don't respond? Telling me to go away is so strangely aggressive, I'm baffled. I'm not going to respond any further because this seems very unproductive.
        jonas21 4y ago
        Isn't that just how threads (and debates in general) work?
        metadat 4y ago
        I even tried emailing tptacek to try and be part of the change he said he wanted to see. Crickets. HN folk can be a bit hypersensitive and / or opaque at times. Text medium is not always ideal as it provides no signals for tone, and our brains backfill this information in a biased manner.
jonas21 4y ago
Because it's a tradeoff. The author touches on this in the last sentence: > Here’s the thing though, would you rather your user wait 200ms, or 40s to download a few megabytes on an otherwise gigabit connection? Though I'd phrase it as "would you rather add 200ms of latency to every request, or take 40s to download a few megabytes when you're on an extremely unreliable wifi network and the application isn't doing any buffering?" In the use cases that Go was designed for, it probably makes sense to set the default to do poorly in the latter case in order to get the latency win. And if that's not the case for a given application, it can set the option to the other value.

It's an option, with a default. Arguably (I mean, I'd argue it, other reasonable people would disagree), Go's default is the right one for most circumstances. That's not a "defect"; it's a design decision people disagree with.

rdslw 4y ago
you clearly (in this post and yours others) did not read OP and other comments on this thread where it's documented that it WAS NOT design decision. why use it as an argument where it's written it was NOT by design. the same with LFS -> this post clearly shows detriment to LFS usage, and probably many other tools written with golang. 'most circumstances': prove it, or dont use.

loeg 4y ago

If there is a defect, it's in git-lfs. Picking a reasonable default is not a defect.

maxbond 4y ago
It being reasonable is what's in dispute.
- tptacek 4y ago
  Not really, not on this thread. The debate is valid (though maybe not in this hyperbolic framing), but this is subthread where I'm responding to someone who "picked their jaw up off the floor" at this "defect" of a very obvious default in the Go standard library that has been there I think since its inception, as if no network software in the history of software had ever deliberately disabled Nagle, rather than that being literally standard socket programming advice for decades. (Again, being standard advice doesn't make it not debatable!)
  - maxbond 4y ago
    I. Don't at all understand this comment. You don't own this subthread? I don't really even really recognize the boundaries of subthreads from the larger thread, at least not in the way you're suggesting? The article is about surprising consequences of this decision. This being a "good default" is very much a subject of contention in this discussion. > (Again, being standard advice doesn't make it not debatable!) This seems to accept my premise that it's what's in dispute?
    - deleted 4y ago
      [deleted]
    - tptacek 4y ago
      I don't claim to own the thread, but since you've jumped in to respond on behalf of the other person I responded to, I'm going to to tell you again that what you want to talk about here isn't what I'm here to talk about. There are plenty of other subthreads here talking about whether disabling Nagle by default is a good thing or not; maybe join one of them.
      - maxbond 4y ago
        I'm not responding on anyone's behalf. I think your attitude here is really weird. You are in fact asserting that you are the arbiter of what can be discussed in this subthread. If you don't want to discuss what I'm discussing - just don't respond? Telling me to go away is so strangely aggressive, I'm baffled. I'm not going to respond any further because this seems very unproductive.
        jonas21 4y ago
        Isn't that just how threads (and debates in general) work?
        metadat 4y ago
        I even tried emailing tptacek to try and be part of the change he said he wanted to see. Crickets. HN folk can be a bit hypersensitive and / or opaque at times. Text medium is not always ideal as it provides no signals for tone, and our brains backfill this information in a biased manner.

jonas21 4y ago

Because it's a tradeoff. The author touches on this in the last sentence: > Here’s the thing though, would you rather your user wait 200ms, or 40s to download a few megabytes on an otherwise gigabit connection? Though I'd phrase it as "would you rather add 200ms of latency to every request, or take 40s to download a few megabytes when you're on an extremely unreliable wifi network and the application isn't doing any buffering?" In the use cases that Go was designed for, it probably makes sense to set the default to do poorly in the latter case in order to get the latency win. And if that's not the case for a given application, it can set the option to the other value.