[na85]

>Are there people with experience in a wide variety of languages that prefer Go?

Other than Go, I have varying levels of experience in C, C#, Common Lisp, Python, (embedded) assembler, Fortran, Tcl, PHP, and maybe a few other languages I screwed around with for fun.

At first I really really liked Go, and I grew to loathe it. I still think Go probably excels in large software development shops where some of its design decisions make a little bit more sense. For a solo project, unless you're trying to get hired to write Go professionally, I would avoid it.

Some complaints in no particular order:

- An unused import is a compile error, which means every time you comment out a variable while debugging, you also have to go fuck with your imports

- SemVer is baked right into the language, but Go simply cannot handle major versions > 1.x in any sane way. The documentation[0] actually recommends that you copy-paste your entire codebase into a separate v2/ subdirectory and then maintain that.

- No function overloading

- Annoying type/interface system

- Smug, snotty community (mostly #go-nuts on freenode/libera)

That's about all off the top of my head but it was enough to turn me away from go for good. If I was writing an httpd or something similar, as part of a large team, I might choose Go. For just about any other use case I would not, because it sucks for those use cases.

[0] https://go.dev/blog/v2-go-modules

[saturn_vk]

> The documentation[0] actually recommends that you copy-paste your entire codebase into a separate v2/ subdirectory and then maintain that.

That's not the documentation though. Just a blog post. The documentation [0] recommends a branch be created. Creating a directory is not even mentioned.

[0] https://go.dev/doc/modules/major-version

[ovao]

> No function overloading

In my experience, non-type-specific function/operator overloads ultimately end up being a pain point. They’re generally wonderful —- until they’re abused, for which there’s a tendency. That’s certainly true of C++, and likely true in other languages which support overloading to varying degrees. With generics, the potential value of overloading in Go should now almost always be (hopefully) close to zero, so I think this criticism may be less notable than it was before.

> Smug, snotty community (mostly #go-nuts on freenode/libera)

I wonder if that’s not specific to those communities rather than the Go community as a whole. My general pulse on things is that the community Go isn’t less inclusive than others, but that may be a biased viewpoint.

[na85]

>I wonder if that’s not specific to those communities rather than the Go community as a whole.

Maybe. My experience with IRC communities, especially tech-focused ones, is that they tend to be pretty welcoming and friendly. For example #lisp and its sibling channels, on libera, are some of the nicest places around.

By contrast everyone I interacted with on #go-nuts seemed to have a huge chip on their shoulder and a quick snarky answer always at the ready for why Go is always better than $language in every way, no matter what.

[seanp2k2]

We're using go for some projects at work and I'm not a huge fan. I don't like things like the compiler just exiting 0 when a build completes with absolutely zero output by default. Things like logging feel too complicated for what they are. Errors that I ran into tended to be cryptic and hard to resolve.

One of the main reasons we went with go for a particular project was the ease of distribution and being able to build it for all platforms. The "all platforms" part isn't actually easy at all. It's a relatively simple app but does use GTK which is a nightmare to get working correctly on Windows, and a bigger nightmare to get working with our CI system that expects builds to be dockerized. In my opinion, it's not worth it.

At least it's fast when it does run, which isn't 100% of the time since sometimes it was just exiting with no output until we set up Sentry inside the app.

I feel like it's similar to Java, where the "write once, run anywhere" thing doesn't actually apply in practice. Combine with how GTK wants root stuff handled (TL;DR you have the app that runs in the background do the actual work that requires elevated privs and run the GUI as a separate app then do IPC / expose an API) and how different platforms have different ways of running a persistent daemon + how that complicated distribution (we're at the point now where we have an MSI for InTune for Windows and a JAMF package for Mac + the binary itself just works on Linux and we can push that with Salt) and...if it had been my decision, I would have just used python or node.

As a bonus, none of the libs for accessing our $BIGCO internal services are ported to go, so for some things we can use GRPC but other stuff just sucks to integrate with. It's so so so so so much easier to just use the most-supported or at least a well-supported language within a $BIGCO for the network effect.

[na85]

>I would have just used python or node

I've always stayed away from node because the ecosystem looks like such a shitshow from the outside, but the speed of V8 appeals to me.

Python is great for quick stuff that doesn't need to be performant. I use magic-wormhole and pgAdmin4 probably every day and they're great, but I shy away from Python for anything that needs threading.

One thing I will say in go's defense is that I found goroutines to be a fairly pleasant and straightforward experience (at least as far as multithreading can be straightforward and pleasant)