Frankly code generators to fake generics aren’t remotely easy either.

Well yes obviously I know everything is passed by value, just like in literally every other popular language. I'm talking about the difference between pointer parameters/receivers vs value parameters/receivers.

But that's the thing right? Like I come from Java. In Java, we have objects. They are pointers. That's it. You don't get to decide on whether you want a pointer or a value (I guess primitives are an exception lol). But it was so simple!

And same in JavaScript. Everything is a pointer except primitives. That's it. End of story.

And I have written Rust too, and while the situation is definitely more complicated there, the guidance is extremely simple and straightforward: If the struct implements Copy, then it is very cheap to copy and you should pass by value. Otherwise, you should pass by pointer/reference.

And meanwhile in Go, I just see pointers and values being used seemingly interchangeably, and seemingly at random.

I mean it's a great idea, and I fully agree that I do not want to worry about memory allocation. So then why is `make` a thing? And why is `new` a thing? And why can't I take an address to a primitive/literal? And yet I can still take an address to a struct initialization? And why can't I take an address to anything that's returned by a function?

My assembler days were 4 decades ago, but

"Everyone can read Go code and understand what happens."

There seems to be a difference between "easy to read" and "understand what happens" - or what happens on what level. The challenge is that there is a tradeoff between the two. Assembler is too low to understand what "really" happens, on the other hand Haskell for example with Monad stacks is again very easy to read + understand what happens "most of the time", but hard to understand all the abstracted away side effects.

In Haskell with

   add 3 5

In assembler

  ld a, 3
  add a, 5

The tradeoff is how much you want to be explicit, with the downside of creating too much noise, and how much you want to abstract away, with the downside of magic happening somewhere.

My opinion on Kubernetes as a yardstick example of Go is this:

This was one of the first large systems developed in Go, not too long after the language hit version 1.0 (ca. 12 years ago). What constituted good Go style and package architecture were not well known at that time even. Given that and hindsight being 20:20, I could easily imagine the internal architecture (not even the public surface) for Kubernetes being a lot different and simpler. The package architecture alone makes me cringe. As a hypothetical counterpoint, I wonder what Kubernetes would have looked like had Dave Cheney (https://dave.cheney.net/) and Rob Pike built it in that era. I think that would have been a better yard stick.

I have a unique appreciation for this first large systems perspective as I co-designed an adjacent product in the cloud native ecosystem at that time (Prometheus). There was no good example to follow when it came to large program structure and design in Go at that time. We were all figuring that out for ourselves — organically.

I think this point about organic evolution of the architecture is important to call out explicitly, because developers often look at an existing structure and essentially mimic it with their additions, changes, and refactors irrespective of whether the structure was correct for the problem it was trying to solve or even good. Given that reality, is it really any wonder that one of the first major pieces of software ended up being this metaphorical mess? And the truth is that's not a language-specific problem: it could have happened with any new language. And taking a legacy system of this age and refactoring is difficult from a social perspective, ignoring the gradient/cost of refactoring that is language-specific. You'll have a lot of people who will oppose structural change just because, so probably a significant refactoring to achieve these goals is just not in the cards.

Had there been so much as something similar to https://google.github.io/styleguide/go at that time (ca. 2012) (it's based on the very spartan https://go.dev/wiki/CodeReviewComments), that would have been tremendously useful and impactful in helping preserve simplicity.