4 ms·
I use Go. I'm not a Rustacean. I've also used a whole bunch of things that are not Go. In reading this article, I'm finding myself agreeing with 100% of the au
by busterarm 5y ago
I use Go. I'm not a Rustacean. I've also used a whole bunch of things that are not Go.
In reading this article, I'm finding myself agreeing with 100% of the author's criticisms. I've seen every specific problem mentioned be a thing that bogs companies I've worked for down and erode productivity. A lot of time the ops peoples' (aka: my) productivity specifically.
I haven't worked at a single company where teams of developers using Golang have been able to get the basic networking stuff right.
"Why are my TCP connections not closing? Why am I encountering port exhaustion?"
Go's frustrating inability to inter-op matters quite a lot at the end of the day. GRPC and protobufs are f'in messy and full of footguns.
Thing is, I've been around the block. I know that these problems don't have to be problems. We have a tremendously bad tendency in this field to join cargo cults.
When looking for my next gig, if the company is big enough, I'm likely to start seeing Go as a negative, unless they've got that Tailscale kind of expertise.
- Thaxll 5y ago"Why are my TCP connections not closing? Why am I encountering port exhaustion?" This has nothing to do with Go. You're implying Go has a bug in its TCP implementation which I assume is false. Networking works just fine in Go and it's actually easy to use. https://pkg.go.dev/net https://pkg.go.dev/net Edit: I'm getting downvoted but please share with TCP issues in Go.
- Diggsey 5y ago> You're implying Go has a bug in its TCP implementation which I assume is false. No, the parent is implying that Go's TCP implementation is easy to use incorrectly. Specifically in ways which cause the aforementioned issues.
- busterarm 5y agoThe author of the blog post literally covered it in the article he wrote two years prior that's linked in the first sentence. It's not "TCP issues in Go" it's "Go leaves you to figure these things out for yourself and write bad code that doesn't work if you don't thoroughly understand its gotchas." Also, if you've been following Go over the years, you'll know that there's basically _always_ open issues (https://github.com/golang/go/issues/39063 https://github.com/golang/go/issues/39063) in net & net/http about how Timeouts get mishandled and connections end up not being closed. Cloudflare even had to write a whole (now old and outdated as hell) article explaining how to "do it properly" https://blog.cloudflare.com/the-complete-guide-to-golang-net-http-timeouts/ https://blog.cloudflare.com/the-complete-guide-to-golang-net... so that you don't footgun yourself.
- Thaxll 5y agoHmm not really, the only thing is the default http client that has no time out which is the case in many languages. The only issue I had was about idle connection and DNS resolution. And the ticket you show does not show any issues on the Go side.
- lenkite 5y agoThey really need to add a deprecation note to the default http server and client. I have seen SO many people trip over this.
- hnarn 5y ago> "Why are my TCP connections not closing? Why am I encountering port exhaustion?" So… why?
- pphysch 5y ago> GRPC and protobufs are f'in messy and full of footguns. Distributed data modeling is inherently messy and IME gRPC is one of the least messy, most scalable solutions to it. Or do you have a better alternative?
- azth 5y agoprotobuf has issues with optional fields, as was pointed out in the post. Couple that with a language with a weak type system like golang (no sum types), and it's very verbose and slow to develop in. Targeting better languages helps alleviate the latter.