"Go's (really Plan 9 C's) composition support does "intermingle" methods,"

Just for clarity, what I mean is that when those methods are called, the get the specialized type, as opposed to multiple inheritance where the two base classes can end up calling into each other in a mutually-derived child because the methods still receive an object of the full derived type. You certainly can end up with conflicting method names. I have to admit I don't dock Go much on that, because as we all know, there are two hard problems in computer science, caching and naming things.

"I don't agree. Generic types are necessary, because you often can't express generic algorithms naturally without generic types."

I'm pretty sure I basically said that latter part.

"...polygon clipper..."

I didn't repeat it in this post, but in other places I actively volunteer my belief that anything that involves "doing lots of math" (in the full sense of the term, rather than "a lot of arithmetic") is a bad place to use Go. But I'd observe that every time someone reaches for a reason why they really badly needed generics, it always seems to involve math. I expect this means something.

(It's OK, you don't need to go searching for one that doesn't. I fully believe they exist, and I occasionally encounter them.)

"I think the lesson is "people will figure out design patterns to approximate things that your language doesn't support"... And what you've described in this post is nothing more than a set of design patterns."

I'm not sure that's supported by the text very well. The only thing in there that probably qualifies as a "design pattern" is the sum type approximation; everything else is too small. The only "design pattern" I find myself frequently reusing in Go is external API + "sum type" protocol + goroutine server receiving that protocol. (The boilerplate in that case is the external API implementation, and the use of a channel to return a value; the message types and the server loop themselves are generally not redundant.)

I cut this off the end, but maybe I shouldn't. More what I'm going for here is that I've got a simple language that does a good job with X% of the problems of the world, and over there, I've got a language with a laundry list of complicated features that are much harder to understand and work with, and it goes a good job with Y% of the problems of the world, and I think there's a lot of people who master one of those hard languages and come away thinking X is roughly 5% and Y is roughly 100%. But especially from an engineering-in-a-large-team perspective, it's worth being reminded that that's a cynical estimate, not a reasonable one. It varies from place to place, of course, but X can easily be 80% and Y merely 95%, and might want to try to be sure that you're only paying the price for Y when you're in that other 15%.

I'm curious whether it's possible to build a better language that covers more of the space between Go & Rust, but with a more Go-like cognitive footprint, and I'd like to poke interested people to consider if there might be an answer to that. Again, especially from a programming-in-a-large-group perspective, I still don't really love any of my options. I realize that from your POV (no sarcasm) Go seems like a terrible downgrade, but from my POV it has been an immense upgrade from a world of dynamic scripting languages, in terms of what I can guarantee and provide in my APIs without writing in a language that virtually nobody understands. There's no way I could put Rust or Haskell or anything else that strong and expensive into where I'm putting Go. Go's in a sweet spot that happens to be poorly occupied right now, and I would love nothing more than for someone to improve on it. This is especially true because other than perhaps getting real generics added on later (which I still think is at least conceivable) there's a lot of other places where Go is already very near its own local optima; it's not going to improve much, I think. It will be pretty much what it is.