3 ms·

I've been using go for years now at my work, and I have to say that it does have applications where it's a perfectly capable tool. The problems arise when you

by kubb 5y ago

I've been using go for years now at my work, and I have to say that it does have applications where it's a perfectly capable tool. The problems arise when you try to do something it's not good at and you start wrangling with the language. If your coworkers have strong opinions on how Go is supposed to be used, it can make matters worse. My biggest qualm by far is the limited type system, e.g. it has no concept of immutability or non-null pointers :( Also accomplishing simple things sometimes requires surprisingly weird techniques, e.g. cloning a slice. The lucky people can evaluate a problem and choosing the right tool for it. The unlucky bastards like me get handed a language and are expected to build everything in it. It can be rough sometimes.

exacube 5y ago
> e.g. cloning a slice. https://golang.org/pkg/builtin/#copy https://golang.org/pkg/builtin/#copy
- kubb 5y ago
  I've been using Go for years, of course I know about copy. Someone did a writeup on this which is a perfect illustration of a general theme with Go: on the surface it looks fine, but the closer you look, the stranger things get: https://github.com/go101/go101/wiki/There-is-not-a-perfect-way-to-clone-slices-in-Go https://github.com/go101/go101/wiki/There-is-not-a-perfect-w...
  - exacube 5y ago
    Apologies for my tone, I didn't mean to insinuate you weren't experienced. I guess I was wondering what was wrong with copy(), thanks for the link! IMO, copy() is well-designed and the semantics are sensible. I think the other examples in that article are not clear, and the semantics have me second guessing what they're doing. > Drawback 1: if s is nil, the result sClone is not nil. I can see how this particular semantic seems an issue, but I think its sensible. If your copy() returned nil and you wanted to use it, then you'd have to check if sClone is not nil first, so that if statement is unavoidable. Instead, it's often safer in practice to check ahead of time. Sorry again for my tone, it's easy to appear rude on the internet on a late night.
icholy 5y ago
When I need to copy a slice it's usually a []byte. I'm looking forward to https://github.com/golang/go/issues/45038 https://github.com/golang/go/issues/45038
- kubb 5y ago
  This interestingly touches on another frustrating property of go. Most of the people using it seem to have a different usage pattern than me. Because of that, the language is unlikely to fix the issues that are very real to me. The community claims they don't need them, the language designers, perhaps a bit more arrogantly, claim that I don't need them. Yet, I've used other languages where I've never had to consider this. I can clone whatever I want, whenever I want. If I only ever cloned []bytes, I'd write a helper function, keep it in an utility package and go on with my life. This ties back to the original theme of "it works well for certain things, but if you try to do something that the designers didn't predict, good luck to you".

by kubb 5y ago

exacube 5y ago

> e.g. cloning a slice. https://golang.org/pkg/builtin/#copy https://golang.org/pkg/builtin/#copy

kubb 5y ago
I've been using Go for years, of course I know about copy. Someone did a writeup on this which is a perfect illustration of a general theme with Go: on the surface it looks fine, but the closer you look, the stranger things get: https://github.com/go101/go101/wiki/There-is-not-a-perfect-way-to-clone-slices-in-Go https://github.com/go101/go101/wiki/There-is-not-a-perfect-w...
- exacube 5y ago
  Apologies for my tone, I didn't mean to insinuate you weren't experienced. I guess I was wondering what was wrong with copy(), thanks for the link! IMO, copy() is well-designed and the semantics are sensible. I think the other examples in that article are not clear, and the semantics have me second guessing what they're doing. > Drawback 1: if s is nil, the result sClone is not nil. I can see how this particular semantic seems an issue, but I think its sensible. If your copy() returned nil and you wanted to use it, then you'd have to check if sClone is not nil first, so that if statement is unavoidable. Instead, it's often safer in practice to check ahead of time. Sorry again for my tone, it's easy to appear rude on the internet on a late night.

icholy 5y ago

When I need to copy a slice it's usually a []byte. I'm looking forward to https://github.com/golang/go/issues/45038 https://github.com/golang/go/issues/45038

kubb 5y ago
This interestingly touches on another frustrating property of go. Most of the people using it seem to have a different usage pattern than me. Because of that, the language is unlikely to fix the issues that are very real to me. The community claims they don't need them, the language designers, perhaps a bit more arrogantly, claim that I don't need them. Yet, I've used other languages where I've never had to consider this. I can clone whatever I want, whenever I want. If I only ever cloned []bytes, I'd write a helper function, keep it in an utility package and go on with my life. This ties back to the original theme of "it works well for certain things, but if you try to do something that the designers didn't predict, good luck to you".