Type embedding is still composition (so no inheritance)

There's no inheritance mostly because Go doesn't call its mechanism "inheritance". But the embedding type does magically gain a bunch of methods (and potentially fields) from the embedded type, and these do appear in the embedding type's API surface area. Both semantically and mechanically, it looks a lot like inheritance.

Heck, inheritance in C++ ends up looking a lot like Go's type embedding, at least structurally. In Go, you can refer to the embedded field. In C++, I can take a pointer to the base class. Heck, I can even engage in some good old-fashioned object slicing if I want. It's not exactly the same as in Go, but I think they're more similar than they are different.

Hum, I am not following you here. If you pass your struct to a function that takes an interface (which all that matters) then the compiler will complain big time, telling you something is missing.

I specifically was referring to "optional interfaces" in Go, like Formatter and GoStringer. These are interfaces that are checked at runtime, not at compile time. Those particular interfaces come up in custom string formatting, but they show up in other contexts as well.

Optional interfaces aside, being able to say "this struct is meant to implement that interface" is useful information for the reader. The longer I've been doing this, the more valuable I find these sort of "statements of intent".

2) Fair enough, it's indeed not easy, but when is that required?

Typically, when I want to make a change to an interface and need to know what types implement the interface. It's useful when I'm trying to make sense of a new codebase. It's particularly useful in cases where I can't lean on the compiler because I want to make a semantic change, not a structural change, to the interface.

If your struct requires specific construction, you use an explicit function or you simply don't export it and push your API at the module level.

That's just a constructor with extra steps. That is to say, we both agree that there is sometimes a need to have nontrivial initialization. In another language, I'd just add a constructor (which would in turn remove the implicit, default constructor) and I'm done. In Go, you might need to:

1. introduce a new interface
2. stop exporting the struct (which ends up manifesting as a rename, since casing matters for some reason)
3. update existing callers to switch from referencing the struct to instead reference the interface, and finally
4. add an additional module-level function.

I'm not going to hold up C++ as the ideal here. It has inherited too much baggage from C, and it's really annoying that there's a distinction between value-initialization, zero-initialization, and default-initialization. But other OO languages have corrected that mistake. In Java, you get the Go default initialization behavior by default. But you have the option to do something different if it makes sense for your type.

How many times in C++ have you wondered: "is this assignment doing a shallow copy or a deep copy"?

These days? Basically never. In the codebase that I work in, most types are either views (in which case copies are cheap because they don't own anything) or types that own their data (in which case the copy constructor / assignment operator does the right thing, and we often don't need to write any code for that to happen).

For example, if I have a std::vector as a field in my class, then when that class is cloned, the vector will be cloned and each element of the vector will, in turn, be cloned. Most custom types get a copy constructor for free, and you only really need to define your own infrequently.

Actually, I'd turn the tables on you here. Because Go doesn't allow you to control cloning behavior, and because the default behavior is sometimes incorrect, the user of the Go struct has to be familiar with the field of the struct. They need to know what will happen when the struct is cloned. Does the struct contain only scalar data, in which case the clone truly is a clone? Does it contain pointers, slices, or maps? I would expect that Go users need to think about this all the time.

But note that I didn't say "Go prevents me from writing complex copy constructors". I said "Go doesn't let me prohibit cloning". At least, if I could prevent automatic cloning, I could provide an ordinary method that clones safely. The well-known Mutex footgun in Go is a great example. Mutex is cloneable (because it's just a struct), but a cloned mutex is basically worthless. You always want to capture the mutex by pointer. The language should help you do the right thing, but Go provides no help here.

Hum, let me ask you, how many times did you change a private into public just to please the compiler?

Very rarely. It probably indicates that some high-level component is trying to micromanage some lower-level component. Or it means that I put an abstraction in between two things that should not have been separated.

I'm not saying that I never do it. But I usually have an idea of how my class fits into the larger picture, and I know what affordances my class should expose to the outside world. If I need to switch something from private to public as a "back door", then my design needs more thought.

If you have plain data in C++, there's nothing wrong with structs. You only need to use private when you want to enforce some invariant. And if you want to enforce some invariant, then you do not want people messing with your data.

This was the whole point of Go. [snip]

I think your summary here is very good. I think you're right that intent was to try to simplify C++. And I think it's important to look at things in context. Go was initially released in 2009, with development starting in like 2007, and that's all before C++11 was released. C++11 was a huge improvement. Move semantics and smart pointers are fantastic. Most of the time, things "just work".

But even now, it's still an awkward language. I will not hold up C++ as a "good" language.

Java, C#, Go, and others were all responses to the complexity and problems of C++. But, personally, I feel that Go sliced too much off. To me, it's hard to work in Go and not feel like something is missing. I'm shocked that it took them 10 years to add generics. Multiple other languages proved that generics work pretty well. Java added generics in 2004. C# added them in 2005. Maaaybe they were still seen as "unproven" when Go initially started development in 2007. But I am so used to having generics (or C++ templates) that it would be painful to go back to a world without them. So I'm glad they did finally add them.