2 ms·

> Go receives so much unjustified good will it is almost unbelievable... Yes. Yes it does and it really is annoying. I can't tell if it is the language or just

> Go receives so much unjustified good will it is almost unbelievable... Yes. Yes it does and it really is annoying. I can't tell if it is the language or just people not deeply understand the abstractions it provides because it doesn't use sane defaults (or the defaults are geared towards high-throughput, google scale nonsense). I help out a lot on FrankenPHP, and lately I've been digging into a weird bug, deep in Go, that causes FIN_ACK packets to get delayed by hundreds and hundreds of ms. There are so many layers of abstractions (nearly 100) to dig through. I know for a fact in the C# there are less than 10 to the CLR, then after you can rule out the language, you are just tracing IR. But no, I'm digging through hand-written asm, hunting for a bug or at least figure out how to report it with enough information that it doesn't sound like "my email can't be sent more than 500 miles" (google that one btw).

apgwoz 3y ago
> I've been digging into a weird bug, deep in Go, that causes FIN_ACK packets to get delayed by hundreds and hundreds of ms. Just going to put it out there: have you considered the problem might actually be [Nagle’s Algorithm](https://en.wikipedia.org/wiki/Nagle's_algorithm) https://en.wikipedia.org/wiki/Nagle's_algorithm)? This algorithm is the source of 10s of thousands of hours of wasted debugging time of “weird bugs related to latency of networking.” Even the “greats” have wasted time debugging something that ended up being “I forgot about Nagle.”
- withinboredom 3y ago
  Yes. Go doesn't even offer the ability to use Nagle's algorithm: https://withinboredom.info/2022/12/29/golang-is-evil-on-shitty-networks/ https://withinboredom.info/2022/12/29/golang-is-evil-on-shit... Nagle's algorithm is dealing with connections. These are FIN_ACK. Meaning the connection was told to close and we need to ack the closed connection.
  - kjksf 3y ago
    Of course it does: just call TCPConn.SetNoDelay(false). See https://github.com/golang/go/blob/master/src/net/tcpsock.go#L258C19-L258C29 https://github.com/golang/go/blob/master/src/net/tcpsock.go#...
    - withinboredom 3y ago
      You have to get access to the TCP connection first ... which, once you get more than a few layers above that, it is impossible to get to.

apgwoz 3y ago

> I've been digging into a weird bug, deep in Go, that causes FIN_ACK packets to get delayed by hundreds and hundreds of ms. Just going to put it out there: have you considered the problem might actually be [Nagle’s Algorithm](https://en.wikipedia.org/wiki/Nagle's_algorithm) https://en.wikipedia.org/wiki/Nagle's_algorithm)? This algorithm is the source of 10s of thousands of hours of wasted debugging time of “weird bugs related to latency of networking.” Even the “greats” have wasted time debugging something that ended up being “I forgot about Nagle.”

withinboredom 3y ago
Yes. Go doesn't even offer the ability to use Nagle's algorithm: https://withinboredom.info/2022/12/29/golang-is-evil-on-shitty-networks/ https://withinboredom.info/2022/12/29/golang-is-evil-on-shit... Nagle's algorithm is dealing with connections. These are FIN_ACK. Meaning the connection was told to close and we need to ack the closed connection.
- kjksf 3y ago
  Of course it does: just call TCPConn.SetNoDelay(false). See https://github.com/golang/go/blob/master/src/net/tcpsock.go#L258C19-L258C29 https://github.com/golang/go/blob/master/src/net/tcpsock.go#...
  - withinboredom 3y ago
    You have to get access to the TCP connection first ... which, once you get more than a few layers above that, it is impossible to get to.