4 ms·

I've become a lot more positive on Go over the years. I tried it a few times starting from when it was released and always found some roadblocks that aggravated

I've become a lot more positive on Go over the years. I tried it a few times starting from when it was released and always found some roadblocks that aggravated me enough not to keep going except for toy projects. They've pretty steadily been removing those even if they keep others, but on the balance the benefits of the language outweigh the remaining drawbacks for me when I'm looking to make something where Go shines such as when a single static binary is a benefit. Overall I still prefer to work in Clojure, all other things being equal, but Go is a nice tool to add to the belt. A huge one for me was the lack of a reasonable project structure - they expected all your Go code to live in one huge directory nested deeply by the import path. It probably worked fine inside Google due to their reputed giant monorepo but it was aggravating to me who has a (much more common, I think) `~/Code` directory with a bunch of projects in it, one level deep. They fixed this along with managing dependency versioning with `go.mod` and `go.lock` files some versions ago and it completely eliminated the problem for me. Generics was another one. I don't love generics but there are some classes of code for which a lack of generics only leads to pain. It's nice that they finally added them. One thing that hasn't changed is their amazing commitment to not breaking existing code. It's really nice to pull up an old project, update the version in `go.mod` (or add one if it didn't exist) and things Just Work™ along with whatever extra benefits you gain from the version upgrade. They clearly did extensive research to avoid breaking even what I consider extremely non-obvious and borderline erroneous behavior (that for loop thing) and did it in a way that makes sense. Their standard lib is good, and pretty well documented. I can often get what I need without having to resort to pulling in a dependency or writing it myself. That's handy. The VSCode support for it is top notch and also Just Works™ in my experience. There's no REPL of course but the debugger can fill a similar role aided by the extremely fast compilation time.

tapirl 2y ago
> One thing that hasn't changed is their amazing commitment to not breaking existing code. Er, are you sure? * https://x.com/zigo_101/status/1856173025839960333 https://x.com/zigo_101/status/1856173025839960333 * https://x.com/zigo_101/status/1854918262523621805 https://x.com/zigo_101/status/1854918262523621805 * https://x.com/zigo_101/status/1854213142177624169 https://x.com/zigo_101/status/1854213142177624169
- arccy 2y ago
  how obnoxious can you be with constantly reposting these
  - hu3 2y ago
    wow! I thought you were exaggerating but on a quick glance, their presence in HN is mostly about criticizing Go.
    - tapirl 2y ago
      I wrote many Go articles praising Go: https://go101.org/ https://go101.org/ I am neither a no-brainer Go hater nor a no-brainer Go lover. Good is good, bad is bad. All my articles/posts are based on facts.
  - tapirl 2y ago
    I only post facts. :D
    - arp242 2y ago
      You need to stop doing this. It's now at the point where you're derailing every other Go thread with this. Quite frankly, it's becoming obsessive. I'm not saying you can never mention this, but you need to stop derailing every other Go thread. In many cases you post it more than once (two here). In other cases it's bizarrely off-topic (e.g. the Russ Cox resigning thread).
      - tapirl 2y ago
        > You need to stop doing this. It's now at the point where you're derailing every other Go thread with this. This is not true. I haven't posted any comments in many Go threads. I only comment when it is related. And most gophers have not been aware of the problems of the new semantics of 3-clause "for;;" loops and it looks Go official don't have the intention to let them know. So I do it. I think this is good for the Go community.
mathw 2y ago
We do have to acknowledge Go's significant influence on language tooling. I'm not sure my own joy in Rust's tooling would be in the same place at all if we didn't have Go there shipping package management and autoformatting out of the box. Autoformatting - what a revolution in creating a language community where that's a standard, required part of the workflow! What an entire class of pointless arguments that's helped to eliminate. Marvellous. I'm glad I turned down a job working in Go though. Whenever I read some open source tool's code to find out what it does, anything in Go seems unnecessarily verbose and extremely simplistic. It's all the design principles of Java that I don't like, but more of it. Not my style, but an undeniable positive impact elsewhere also. And to some extent the idea that we can have modern languages with modern tooling which compile to native code and run really fast is much perpetuated by Go, and this is highly valuable in a world where far too many things are written in JavaScript and bundled with a web browser to render them because that's "easier".
- benhoyt 2y ago
  > It's all the design principles of Java that I don't like, but more of it. I'm curious what you're referring to there. I think of Go as the "anti-Java". Where Java has "org.apache.commons.httpclient", Go has "net/http". Where Java has stuttering like "final Logger logger = LogManager.getLogger();", Go has "logger := log.New()" (and no log4j vulnerablity). A typical "simple" app in Java puts files in "src/com/username/simplewebapp/subdir", typical Go project structure is to put files in just "subdir", or even just in the root dir. And so on.
a-french-anon 2y ago
Tried to contribute to a Go project a few months ago and got bitten by https://github.com/golang/go/issues/67296 https://github.com/golang/go/issues/67296 due to questionable doc quality. I was pretty disappointed to find that natural sort isn't builtin since Go was the Unicode language in my mind (Go runes, made by some Plan 9 thus UTF-8 creators). Go has a lot of good points, but I immediately felt "dirty" when using it. Like that time when I tried to wrap a closure variable over itself ("my_closure = new closure calling my_closure") and needed to use a temporary variable because closure captures are always by reference: if you want to build abstractions, you got to think them better; as it stands, this is the worst of both worlds I know (C++ makes capture type explicit and customizable, Common Lisp was designed by wizards who knew what to do cf https://www.tfeb.org/fragments/2023/02/22/how-to-understand-closures-in-common-lisp/ https://www.tfeb.org/fragments/2023/02/22/how-to-understand-...).
- foldr 2y ago
  We may have different definitions of 'temporary variable', but you don't need what I would think of as a temporary variable to make a self-calling closure: toCapture := 99 var myClosure func() int myClosure = func() int { return myClosure() + toCapture } // nonsense myClosure() It would be nice if Go would just allow the use of function definition syntax inside functions, though. Seems like a small and non-breaking change that could easily be made.
- dfawcus 2y ago
  One can sort of get a non reference capture, by passing the same name as a argument; but yes it would be nice if one could somehow say capture by value. foo := 1 closure := func(foo int) func() int { return func() int { return foo += 1 } }(foo) x := closure() // 2, w/o altering outer foo If not something like the above, I'm not sure what you're trying to express. Possibly what 'foldr' suggested, or that with mine such that one passes in the initial closure function as a argument?

tapirl 2y ago

> One thing that hasn't changed is their amazing commitment to not breaking existing code. Er, are you sure? * https://x.com/zigo_101/status/1856173025839960333 https://x.com/zigo_101/status/1856173025839960333 * https://x.com/zigo_101/status/1854918262523621805 https://x.com/zigo_101/status/1854918262523621805 * https://x.com/zigo_101/status/1854213142177624169 https://x.com/zigo_101/status/1854213142177624169

arccy 2y ago
how obnoxious can you be with constantly reposting these
- hu3 2y ago
  wow! I thought you were exaggerating but on a quick glance, their presence in HN is mostly about criticizing Go.
  - tapirl 2y ago
    I wrote many Go articles praising Go: https://go101.org/ https://go101.org/ I am neither a no-brainer Go hater nor a no-brainer Go lover. Good is good, bad is bad. All my articles/posts are based on facts.
- tapirl 2y ago
  I only post facts. :D
  - arp242 2y ago
    You need to stop doing this. It's now at the point where you're derailing every other Go thread with this. Quite frankly, it's becoming obsessive. I'm not saying you can never mention this, but you need to stop derailing every other Go thread. In many cases you post it more than once (two here). In other cases it's bizarrely off-topic (e.g. the Russ Cox resigning thread).
    - tapirl 2y ago
      > You need to stop doing this. It's now at the point where you're derailing every other Go thread with this. This is not true. I haven't posted any comments in many Go threads. I only comment when it is related. And most gophers have not been aware of the problems of the new semantics of 3-clause "for;;" loops and it looks Go official don't have the intention to let them know. So I do it. I think this is good for the Go community.

mathw 2y ago

We do have to acknowledge Go's significant influence on language tooling. I'm not sure my own joy in Rust's tooling would be in the same place at all if we didn't have Go there shipping package management and autoformatting out of the box. Autoformatting - what a revolution in creating a language community where that's a standard, required part of the workflow! What an entire class of pointless arguments that's helped to eliminate. Marvellous. I'm glad I turned down a job working in Go though. Whenever I read some open source tool's code to find out what it does, anything in Go seems unnecessarily verbose and extremely simplistic. It's all the design principles of Java that I don't like, but more of it. Not my style, but an undeniable positive impact elsewhere also. And to some extent the idea that we can have modern languages with modern tooling which compile to native code and run really fast is much perpetuated by Go, and this is highly valuable in a world where far too many things are written in JavaScript and bundled with a web browser to render them because that's "easier".

benhoyt 2y ago
> It's all the design principles of Java that I don't like, but more of it. I'm curious what you're referring to there. I think of Go as the "anti-Java". Where Java has "org.apache.commons.httpclient", Go has "net/http". Where Java has stuttering like "final Logger logger = LogManager.getLogger();", Go has "logger := log.New()" (and no log4j vulnerablity). A typical "simple" app in Java puts files in "src/com/username/simplewebapp/subdir", typical Go project structure is to put files in just "subdir", or even just in the root dir. And so on.

a-french-anon 2y ago

Tried to contribute to a Go project a few months ago and got bitten by https://github.com/golang/go/issues/67296 https://github.com/golang/go/issues/67296 due to questionable doc quality. I was pretty disappointed to find that natural sort isn't builtin since Go was the Unicode language in my mind (Go runes, made by some Plan 9 thus UTF-8 creators). Go has a lot of good points, but I immediately felt "dirty" when using it. Like that time when I tried to wrap a closure variable over itself ("my_closure = new closure calling my_closure") and needed to use a temporary variable because closure captures are always by reference: if you want to build abstractions, you got to think them better; as it stands, this is the worst of both worlds I know (C++ makes capture type explicit and customizable, Common Lisp was designed by wizards who knew what to do cf https://www.tfeb.org/fragments/2023/02/22/how-to-understand-closures-in-common-lisp/ https://www.tfeb.org/fragments/2023/02/22/how-to-understand-...).

foldr 2y ago
We may have different definitions of 'temporary variable', but you don't need what I would think of as a temporary variable to make a self-calling closure: toCapture := 99 var myClosure func() int myClosure = func() int { return myClosure() + toCapture } // nonsense myClosure() It would be nice if Go would just allow the use of function definition syntax inside functions, though. Seems like a small and non-breaking change that could easily be made.
dfawcus 2y ago
One can sort of get a non reference capture, by passing the same name as a argument; but yes it would be nice if one could somehow say capture by value. foo := 1 closure := func(foo int) func() int { return func() int { return foo += 1 } }(foo) x := closure() // 2, w/o altering outer foo If not something like the above, I'm not sure what you're trying to express. Possibly what 'foldr' suggested, or that with mine such that one passes in the initial closure function as a argument?