[foldr]

I fail to see the point of this. Buried in this post are one or two reasonable (but familiar) criticisms of Go. As for the rest of it, the author appears to be upset that everyone in the world didn't immediately stop using Go after reading his blog post of two years ago.

[aidenn0]

The author does not think everyone in the world should immediately stop using Go. TFA even mentions that tailscale's use of Go could very well be the correct choice.

TFA is about dismissive comments about the article and people burying their head in the sand rather than engaging with the criticisms.

[ilyt]

Or they are just fine with the drawbacks and are annoyed by another non-user whining about it.

Yet another whiner complaining about well-known problems that advanced users are aware of doesn't add anything and nothing in this article is new thing to any advanced user.

Especially if the asshole behind article makes the title extra confrontational and aggressive just to piss off people.

[richbell]

> Yet another whiner complaining about well-known problems that advanced users are aware of doesn't add anything and nothing in this article is new thing to any advanced user.

"Well-known problems that advanced users are aware of", in other words problems that you can and will shoot yourself in the foot with unless you've already shot yourself in the foot and know to avoid them? Why is it contentious to say that things should and could be better?

> Especially if the asshole behind article makes the title extra confrontational and aggressive just to piss off people.

Why do you feel the need to reproach constructive criticism as being from assholes and "whiners"? You can like Go, or anything else, while acknowledging its flaws and believing it should be better.

I thoroughly enjoy Kotlin, TypeScript, and a handful of other technologies but I will be the first to admit and lament their failings.

(I'll admit the title is cheeky/provocative, but I think calling the author an asshole and ascribing intent that they want to piss people off says more about you than them.)

[ilyt]

>> Yet another whiner complaining about well-known problems that advanced users are aware of doesn't add anything and nothing in this article is new thing to any advanced user.

>"Well-known problems that advanced users are aware of", in other words problems that you can and will shoot yourself in the foot with unless you've already shot yourself in the foot and know to avoid them?

Not really. For example the mutex copying will be caught by tooling

    ./main.go:14:7: assignment copies lock value to b: cake.asd

and majority of problems can be summed up "it makes writing some code more annoying and verbose", not "introduces subtle and hard to find errors"

If you read the actual article you'd know that's what author complained most about, annoyances (and I pretty much agree with most of it).

The biggest "trap" being probably not being able to have proper immutable types but honestly so far that haven't bitten me in any way; the argument presented in article shows it off in really stupid way too, I'd think anyone assumes methods on a type (especially ones named Change()) would modify it by default and if you dont want caller to mutate it you wouldn't pass reference in the first place.

Better example would be passing a struct that have nested references as that would be a bit questionable as passing struct shallow copies it, but not the deeper levels that could be changed by the caller, so when bad enough coding practices were applied it might lead to something funny

Some other sorta-footgun is lack of timeouts on http/tcp calls (technically stdlib footgun) which means carelessly written code might get into bad behaviour, and the fact that map does not shrink (but that's implementation footgun) so long lived map will have max size it seen on its lifetime.

[jasonhansel]

The author seems to be asking: given how bad Go is, why (sociologically) do people keep using it?

Of course, this only makes sense if you already accept the premise that Go is bad.

[somekyle2]

I think it may be an uncomfortable truth for many language enthusiasts that with a decent compiler/runtime and a reasonably skilled team, you can write very good software reasonably efficiently in even a mediocre language. Language design absolutely matters in terms of what can be expressed efficiently, what classes of mistakes are hard to make, what performance you can expect in normal code, but rough memory safety, some static typing, and basic abstraction gives you a lot of the value there, and you can close a lot of the remaining gap in language capability with some discipline and process. Naturally, ideally we'd still only use perfect languages, and not allow errors that could be avoided or suboptimal code, but not all PL power is free and personal taste/experience isn't irrelevant, so I'm not too surprised that some people prefer a tool that to me seems worse, because empirically it often works out quite well.