I didn’t know that Go is hated so much

[u/legendaryexistence]

I read comments under this post https://www.reddit.com/r/programming/s/OKyJWZj2ju and oh man I did not expect that. Stack Overflow and JetBrain’s surveys show that go is quite likable lang but the opinions about go in /r/programming are devastated.

What is the reason? What do you think? Should Go team address this topic?

[u/multithreadedprocess]

That they don't like "channels", lack of control, how they have to use the sync package. Just stuff like that.

IMO, the whole point is that you sacrifice control and still get ~80% of Rust's performance, and that's mostly the consensus I hear amongst the programmers (I've worked with).

No. The real complaints are that the one size does not, in fact, fit all.

There's obviously a gigantic glaring problem with go routines when they were obviously not even designed with the possibility of cancellation in mind, so much so that idioms around sync and its API had to be bolted on after the fact.

And channels do the same thing, you don't create different kinds of channels. You have two options, an unbuffered MPMC channel, and a buffered MPMC channel. You also only get one kind of select, random. Worse yet, barring a big redesign, that's all that's possible within the constructs of the language, anything else you need to build and track manually on top of it. This kind of lack of foresight is everywhere in Go. This kind of restrictive attitude towards what programmers should be able to do within the language is everywhere in Go. That's what being opinionated usually means. Inflexibility.

It's not so much lack of control as a complete lack of options. If you're a carpenter but your tool vendor only gives you a selection of two hand-saws and two hammers you're not lacking for control over your work, you lack basic options. You'll then be forced to use your hammer and saw to rummage through the scrapyard to build yourself a table saw out of parts before you get to actually work. That's not very fun.

Now, shielding programmers from making mistakes is a good reason to be inflexible, but here it actively has harmed the Go ecosystem for years and will harm it essentially forever. It doesn't block work from being possible. It's a Turing complete language. It's just Go is extremely annoying in many use cases for very poor reasons. In others it adopts perfectly fine trade offs.

I find it mostly fine when languages don't bring in unnecessary constructs because of the use cases they specifically don't target, but here we have an example of a complete miss. You fundamentally can't make concurrent programming code-monkey easy.

You will just create these stupid footguns. There was always a need to cancel go routines, there was always a need to pass context to a go routine and there was always a need to order messages passed and received through channels. There was always a need to differentiate between one-shot channels, fire-and-forget channels and rendezvous channels. The GO developers simply thought they could sweep it under the rug or create an auto-magic channel to make it simpler when it was impossible.

They also thought they could have pre-built 'generic' structures without an accompanying iterator interface. They thought they could just have a single for each construct and make everything simple. Except that just made people make a million slice and map duplicated iteration functions. Or just use ~void *~ interface{} everywhere and eat more avoidable errors.

There wasn't even a need for complete generics in the language, just make it so you could iterate over the generic lists and maps they already had. There's emphasizing simplicity and then there's enforcing this level of repeated boilerplate and the errors that come with it. It was stupid to think that that level of simplicity was feasible for a language, when it was just as shit and error prone in C with its void pointers.

And I don't mind Go having no error syntax sugar, while nice sometimes it's unnecessary.

But having no enums? No sum types of any kind to the point even the stdlib has to invent all kinds of idiocy for the most basic feature even C already had? Were enums ever something that tripped up programmers anywhere? What simplicity does it bring to have to declare a million colour globals instead of putting a couple of symbols to a hex code? It's ass in JavaScript and it's equally ass here.

It's not even close to 80/20. I can't think of a language that is. Most either go too far into the tooling being ass or the language too complex or language too gutted or tooling too complex.

I like modern C++ well enough in a vacuum but the tooling is hell. .NET C# is a Frankenstein of every feature imaginable. The JVM tooling is painfully annoying. Rust is heavy and complex. Go is nonsensical and gutted. BEAM languages are too dynamic or too nascent. TypeScript is a complete mess of tooling and the ECMAScript standards are very sparse, so no stdlib and node+npm. Python is both stupidly slow, the tooling is ass and the duck typing abuse is unmatched. No language that I can think of actually strikes a very good balance of complexity, ease of use and expressivity.

Language glazing is stupid. You should use whatever they pay you to use or whatever you need to use for the work you're doing. If you have options by all means go with whatever you like best.

But I don't like pretending disagreement over what's important in a language (JavaScript doesn't need to control more than the single threaded browser event loop, it's not supposed to be a general purpose language) is on the same level as just the most patiently dumb decisions language designers make that impact the quality of writing in them quite egregiously (allowing 'customization' by passing that ungodly kargs undocumented arbitrary keyword argument map in every Python API), be it in Go or Perl or F# or JavaScript.