[_cenw]

The article spends an inordinate amount of time to delve into meta arguments about groupthink and elitism and juniors vs. seniors which is interesting enough, but I find the meat of the argument a bit lacking.

Go has some warts, but they're all things that make sense if you know some basic concepts about go (as in you can derive them from knowing how go ticks), versus thousands of random caveats in the core library of other languages. They seem to be most upset about allocation, but it is in fact pretty simple. Types that can be nil are nil upon initialisation, and everything else is a zero value (by virtue of not being a pointer). C isn't actually different here. The only thing I'd expect to surprise a C programmer here is that strings aren't pointers by default, despite being variable length.

And I'm not sure what their point about CGO is. People always say to avoid it because you leave the Go world behind and because performance could be better, but it is still a legitimate way to achieve FFI. The SQLite package uses it and nobody recommends against using that either. It just comes with a "more complexity if you add this" disclaimer.

[kelnos]

> Go has some warts, but they're all things that make sense if you know some basic concepts about go

That's exactly the problem. I don't want to spend my time learning the myriad quirks of a language. I want to spend my time building my program. As someone who is an "advanced beginner" at Go, I assure you that just knowing "some basic concepts" is not enough to avoid Go's pitfalls and footguns.

I don't want to work in a language where the solution to all these things is "just be careful when writing code". I'm fallible. Compilers, less so. The compiler should be doing this work for me.

[loosescrews]

> I don't want to spend my time learning the myriad quirks of a language.

That is just it. Go's quirks are mostly a result of its consistency, not a result of a lack of consistency.

> I assure you that just knowing "some basic concepts" is not enough to avoid Go's pitfalls and footguns.

It seems that Go has two somewhat contradictory goals: consistency and similarity to popular yet inconsistent languages. This seems to result in a lot of people who can generally use the language, but haven't learned the language model because the language doesn't require that in order to get started. This seems to frustrate a lot of people and prevent them from ever learning the language model. Languages which appear completely different from popular languages don't seem to suffer this issue because people tend to learn the language model up front.

Go really only has one major source of inconsistency and that is the late addition of type parameterization. The built-in parameterized types are special, but still generally follow the same rules as other types with a few exceptions. The main thing you need to know about slices, maps, and interfaces is what they actually are. Once you know that, the normal rules apply. Channels are a different beast though.

[kaba0]

How can you honestly claim that the language is consistent when it didn’t use to be able to express a map without supporting it on a language level (instead of only being a lib)? A properly consistent language would be one where you could reasonably come up with how to use anything, including such a basic data type just from simple primitives. Go is very far from that.

Have a look at the excellent “Growing a language” talk by Guy Steele where he goes into great detail on what would a truly consistent language entail.

[majewsky]

"Being able to solve every programming problem" is not a necessary prerequisite for consistency. If that were true, SQL would be inconsistent because it cannot interface with libgl in order to render 3D graphics. That is clearly nonsense.

[kaba0]

Was this comment meant for me?

[mariusor]

> The SQLite package uses it and nobody recommends against using that either.

There is the modernc.org/sqlite package that doesn't use cgo. Currently the performance is lower, but it's an option.