I think the sticking point is what people mean when they say simple. To me, and likely to many saying Go isn't simple, simple is not a synonym for easy.

Go is easy, but it is not simple. For example, solving the problem of generics in a generic way from the start so the same problem can be addressed in the same way everywhere, would be simple, but maybe not (as) easy. Contrast that to giving the runtime/standard library a special exception with maps and lists. That's easy, but not simple. People used to literally use code generators or weird UTF-8 characters to fake generics, that's not remotely simple.

The first is simply a question about what an embedded interface is. Any way in which you learned about this feature should also answer the question.

The second isn't related to Go.

The third I can see as being a bit confusing, but isn't it something you try once and then remember forever?

Here's one: Creating a new variable via shorthand that shadows a variable in an outer scope - that can be confusing and an easy mistake to make.

But broadly, I would strongly advocate that it is simpler than most other languages, even if it has some quirks. In the same vein of "If I had more time, I'd write a shorter letter", sometimes it takes a bit of time to understand why something is simpler than the alternatives. No language has zero ramp-up. Go doesn't exist in a vacuum, you have to compare it's learning curve and complexity to other languages.

I am not going to answer the questions, but this is a very strange complaint, to be honest.

For example, passing by value/passing by reference is something covered immediately in the Go FAQ document once and for all. Everything is passed by value in Go, that is it. There should be no confusion at all. If you spend 15 minutes reading Russ Cox's post on the internals of the most common data types, you will also understand what data structures have implicit pointers under the hood.

Your thinking is too complex for Go. You might be better of with Rust.

Same about benchmarking, if you want and need the fastest code, or the best memory management, use Rust.

If you need something faster than Python in general but not the fastest, use Go.

> but do I really know without performing a benchmark?

Not really. But that’s one of Rob Pikes rules [1], I think the intention is to write whatever is simplest and optimize later. The programmer doesn’t need to remember 100 rules about how memory is allocated in different situations.

[1] https://users.ece.utexas.edu/~adnan/pike.html

RiscV assembly is even easier to read by that metric.