I characterize it this way: Many people who have learned lots of languages are used to having a problem, and then poking through the new language for the feature that solves the problem. Languages designed by and used by these people tend to grow lots and lots of features.

In Go, you are expected to use the features that exist to accomplish the goal, so instead of knowing a ton of features at a somewhat surface level, you need to learn what is there fairly intimately, and use them to their full effect. For a simple example, there's no such thing as "class methods" in Go, so obviously anything best solved via class methods is impossible, right? Except of course it has "class methods". Class methods are just methods that don't reference the instance itself. Go doesn't have any syntactic label for them, but they exist just fine and I make fairly heavy use of them.

Personally, when I read someone complaining that they tried Go and it was "full of boilerplate, repetitive code everywhere and they kept having to copy&paste functions" that they were either A: in the completely wrong domain (see my other comment about how I don't think Go is good for math at all), or B: they didn't do this and were probably trying to jam a map/filter/reduce-heavy workflow, or an inheritance-heavy design, or something else not native to Go, into Go. My code isn't particularly repetitive. Even the error-handling in my mature code tends to be between 1/3-1/2 not "just return the error". (In prototyping it often starts out that way, but by the time I ship something, there's usually a lot more going on.)

As another for instance, you really need to learn to use interfaces to their fullest, as integrated into the type system. You can put methods on anything, even functions or other non-struct types, and anything with methods can conform to an interface. It's really helpful to be able to do that. If you reject all these options as "that's not how I want to design", you're in for a bad time.

Bizarrely, despite their incredible distance on my internal "map of all programming languages", this is one thing Go and Haskell kind of share in common, and something I took from my experiences with Haskell, where you are also handed a certain set of tools and expected to make them work. If you try to take Haskell and force it to be an object-oriented language, you're gonna have a bad time, and you'll complain about how stupid typeclasses are and how stupid immutable data is and how stupid it is that all your code has to be written in IO so why is it even separated out and all kinds of other things. But the solution is to learn how to actually do things the Haskell way, at which point you'll find that while it may not be the best choice for everything, it certainly has some interesting things to say. Go actually does too, around the virtues of structural typing and the privileging of composition over inheritance. It's much less profound than what Haskell has to say, but it's still something.

Neither Go nor Haskell are unique in this characteristic. You really ought to come in to every language you learn with the viewpoint to learning how it does things, rather than coming in and trying to make it be some other language. It's just the simple languages that tend to really put this in your face. The languages with bazillions of features usually have something on offer that looks close enough to what you want that you can force your way through into turning the language into a different language. (And when you ponder what it looks like when you've got a team of 50 people doing that, you start to see some of what Go is designed to fix.)

If I could upvote this twice, I would. You've managed to put words on something I've been struggling to articulate.

Your point about using Go's type system (esp. interfaces) rings particularly true. When I finally figured out how to effectively use the type system, I suddenly found myself writing extremely malleable code. You can move data types and functions around quite freely, and this makes it easy to design & refactor without losing your place.

The flip side, as you say, is that extreme flexibility requires you to build your own skeleton.

BTW, are you github.com/thejerf? If so, I've contributed to Suture, and use it quite often, so thanks for that.

Yes, that's me. I was slow on the draw and missed github.com/jerf .