[37ef_ced3]

Go is a distillation of many decades of software engineering experience. The people behind Go (e.g., Russ Cox) have learned from history.

The peanut gallery loves to complain about superficial aspects of Go. Typically these are people with little or no actual experience using the language and tools. They fixate on imagined problems that don't matter in practice.

But anyone who has used Go full-time for a few years is likely to deeply respect and appreciate it.

[bjackman]

I've been using Go for a couple of years now and it's funny: I do not love Go, I just work effectively in it. I am not passionate about it, but I recommend it for absolutely all appropriate use-cases.

It doesnt go for intellectual satisfaction, it goes for getting shit done. You have to respect it for being so radically bland.

[jatone]

I get intellectual satisfaction from solving the problems not from the language I use to do it. go hits a fantastic blend in that regard.

[0des]

Go is boring and that's appreciated by myself and others in my peer group.

[kelnos]

I haven't used Go full-time, but I have used it on and off for more than a few years. There are certainly things I respect and appreciate about it, but there are also a lot of things that annoy me about it. Some that you might consider "superficial", I consider important. If I'm going to be spending all day in a language, I want the ergonomics of the language itself to work with me, not against me, and Go often does not fit the bill there (for me -- others' opinions are free to differ).

I don't find most of this article to be all that persuasive. Rust, for example, has a separate lock file, which the article derides. That doesn't really make sense, as lock files are also checked into source control, so you get the same benefit that Go touts of go.mod. My threat model doesn't consider having a separate module/package repository to be much of a risk, so I don't care about that point all that much. Admittedly, having source control be the source of truth is just simpler, which is good, but it also means that module publishers can pull versions (or the entire module) for arbitrary, selfish reasons, and then the community is left with a lot of difficulty (there's also a big problem if someone wants to move their code from GitHub to GitLab or something like that). Centralized module repositories can remove this problem if they choose to. The Go Module Mirror appears to be a hack that tacitly admits this problem.

I did find the "a little copying..." bit to be interesting, and I agree with it. With Rust, pulling in a single dependency tends to pull in many tens of transitive dependencies, which I don't like.

[merely-unlikely]

"but it also means that module publishers can pull versions (or the entire module) for arbitrary, selfish reasons, and then the community is left with a lot of difficulty"

By default go get will download the source code into the pgk/mod folder. So if a module is pulled by the author, you can just use your copy of the source to fork it.

[kelnos]

That's fine if you've already downloaded it, but doesn't help for people trying to pull it for the first time, either as a direct or transitive dependency.

[arccy]

that's what the proxy infrastructure is for: retracted versions won't be selected by default if you're adding it as a new direct dependency, but if you request a version directly (because you need it as an indirect dependency, you have a fresh machine, etc), it will always return the cached code.

[______-_-______]

For a decade+, people complained that go lacks generics. Would you say those were all people with no experience fixated on an imaginary problem that doesn't matter, or were the complaints valid?

[philosopher1234]

I would say that it is legitimately annoying to have to copy and paste data structures, but mostly doesn't matter, and the intensity of the complaining does not match the intensity of the problem.

People mostly just dont like the expertise of the go devs.

[zdw]

Some of those "superficial aspects" are really annoying.

For example, Go forced version tags to have a `v` prefix in git repos for their dependency system, which broke a whole host of CI tools that expected plain numeric values for release versions. There's a outsized amount of Go-specific special casing for this one seemingly arbitrary decision in multi-language CI systems.

[morelisp]

> Go forced version tags to have a `v` prefix in git repos for their dependency system

"Forced" is a bit strong - you can pin any ref, the vX tags just also have some default semver-ish treatment.

> a whole host of CI tools that expected plain numeric values for release versions

Like what? Pure numeric tags are also ambiguous with git refs; this can be worked around by careful arguments, but it means most tooling was already broken when dealing with such things.

If you were one of the people using "release-X.Y.Z" or "rXYZ" I feel for you though.

> Go-specific special casing

'v' tags have been idiomatic for ages. Semver 1.0 went so far as to mandate it in 2010, though that was taken out in 2.0. https://semver.org/spec/v1.0.0.html#tagging-specification-se...

[azth]

I've used golang at my employer for several years now, and I came out respecting and appreciating the design decision that have and are going into Java/C#/Kotlin much more given the atrocities I've seen written in golang.

[sbmthakur]

Are those some common Golang anti-patterns?

[s-video]

I love Go as well, but I don't think being the first to kick up a flame war will do anything for us.

[nu11ptr]

Couldn't disagree more (I spent years writing Go, and now Rust - will NEVER go back)

[mperham]

I couldn't have said it better.

Other ecosystems decided to use lots of little dependencies and I can't imagine a worse engineering decision. This way lies madness.

[seabrookmx]

A few years of Golang under my belt and I still hate it. Russ Cox and co. seem incredibly arrogant to me in that they can ignore decades of PL research only to reinvent a bizarre way of achieving what other languages do in a more standard way (package management, error handling), or just adopt that standard super late (generics).

Go has some great qualities and you can make great software with it no doubt. But I find the development of the language frustrating to witness, not inspiring.

[morelisp]

Who is doing "PL research" in package management?

[pphysch]

What is your favorite PL?

[seabrookmx]

C# probably. Though I enjoy Typescript and Python as well.

C# has generics, exceptions, is the birthplace of async/await, has LINQ, an unmatched standard library, a great build system and package management system, is open source, cross platform, fast..

It doesn't compile to a single native binary unlike golang which is a bummer. But 95% of my software ships as a container so this isn't too big of deal for me. The MS-provided base images are really good too.

[geodel]

Agreed. There are some folks very closely associated with other language ecosystems but they spend more time in endlessly critiquing every little thing about Go.

[laurent92]

I wonder how there are not more NPM vulnerabilities. We control nothing.

Especially during war.