5 ms·

Go was explicitly designed for writing servers. This means two things are normally true: - latency matters, for delivering a response to a client - the networ

Go was explicitly designed for writing servers. This means two things are normally true: - latency matters, for delivering a response to a client - the network is probably a relatively good datacenter network (high bandwidth, low packet loss/retransmission) Between these things, I think the default is reasonable, even if not what most would choose. As long as it’s documented. The fact that other languages have other defaults, or the fact that people use Go for all sorts of other things like system software, doesn’t invalidate the decision made by the designers.

iainmerrick 4y ago
It was originally designed as a C/C++ replacement, not necessarily for servers. If I remember right the first major application it was used for was log processing (displacing Google’s in-house language Sawzall) rather than servers.
- nine_k 4y ago
  Everything developed at Google is intended for transforming protobufs. And how are you going to get some protobufs in the first place? /s
  - anaganisk 4y ago
    Nex step build a language on top of protobuff
andrewxdiamond 4y ago
> the network is probably a relatively good datacenter network (high bandwidth, low packet loss/retransmission) The first lesson I learned about Distributed Systems Engineering is the network is never reliable. A system (or language) designed with the assumption the network is reliable will tank. But I also I don’t agree that Go was written with that assumption. Google has plenty of experience in distributed systems, and their networks are just as fundamentally unreliable as any
- AnimalMuppet 4y ago
  Relatively reliable. Not "shitty". If you've got a datacenter network that can be described as "shitty", fix your network rather than blaming Go.
- morelisp 4y ago
  This is an embarrassing response. The second lesson you should’ve learned as a systems engineer, long before any distributed stuff, is “turn off Nagle’s algorithm.” (The first being “it’s always DNS”.) When the network is unreliable larger TCP packets ain’t gonna fix it.
  - withinboredom 4y ago
    But it will at least let it get out of slow-start.
  - viraptor 4y ago
    Usually you have control over one of them only. If you run the whole network, sure, fix that instead. But if you don't, sending fewer larger packets can actually improve the situation even if it doesn't fix it.
    - Karrot_Kream 4y ago
      Fewer packets yes, but I've been on several networks where sending large packets ends up with bad reordering and dropping behavior.
- danpalmer 4y ago
  “Relatively” may have needed some emphasis here, but in general, networking done by mostly the same boxes operated by the same people, in the same climate controlled building, are going to be far more reliable than home networks, ISPs running across countries, regional phone networks, etc. Obviously nothing is perfect, but applications deploying in data centres should probably make the trade offs that give better performance on “perfect” networks, at the cost of poorer performance on bad networks. Those deploying on mobile devices or in home networks may better suit the opposite trade offs.

iainmerrick 4y ago

It was originally designed as a C/C++ replacement, not necessarily for servers. If I remember right the first major application it was used for was log processing (displacing Google’s in-house language Sawzall) rather than servers.

nine_k 4y ago
Everything developed at Google is intended for transforming protobufs. And how are you going to get some protobufs in the first place? /s
- anaganisk 4y ago
  Nex step build a language on top of protobuff

andrewxdiamond 4y ago

> the network is probably a relatively good datacenter network (high bandwidth, low packet loss/retransmission) The first lesson I learned about Distributed Systems Engineering is the network is never reliable. A system (or language) designed with the assumption the network is reliable will tank. But I also I don’t agree that Go was written with that assumption. Google has plenty of experience in distributed systems, and their networks are just as fundamentally unreliable as any

AnimalMuppet 4y ago
Relatively reliable. Not "shitty". If you've got a datacenter network that can be described as "shitty", fix your network rather than blaming Go.
morelisp 4y ago
This is an embarrassing response. The second lesson you should’ve learned as a systems engineer, long before any distributed stuff, is “turn off Nagle’s algorithm.” (The first being “it’s always DNS”.) When the network is unreliable larger TCP packets ain’t gonna fix it.
- withinboredom 4y ago
  But it will at least let it get out of slow-start.
- viraptor 4y ago
  Usually you have control over one of them only. If you run the whole network, sure, fix that instead. But if you don't, sending fewer larger packets can actually improve the situation even if it doesn't fix it.
  - Karrot_Kream 4y ago
    Fewer packets yes, but I've been on several networks where sending large packets ends up with bad reordering and dropping behavior.
danpalmer 4y ago
“Relatively” may have needed some emphasis here, but in general, networking done by mostly the same boxes operated by the same people, in the same climate controlled building, are going to be far more reliable than home networks, ISPs running across countries, regional phone networks, etc. Obviously nothing is perfect, but applications deploying in data centres should probably make the trade offs that give better performance on “perfect” networks, at the cost of poorer performance on bad networks. Those deploying on mobile devices or in home networks may better suit the opposite trade offs.