I understand the reasoning behind this take - a lot of modern languages have wound up somewhat bloated, with features that are either non-orthogonal to other features and break the 'one way to do it' principle (Scala comes to mind), or with features that seem tacked-on and feel alien to the language (the latest versions of python come to mind). I understand, in theory, why go tries to buck this trend.
The problem is that in bucking this trend, go has (at least historically) not evolved enough to fix some of its own core issues. And it does have some big issues - nils, zero values, and non-thread safe primitives come to mind for me. I'm all for being thoughtful about introducing changes and making sure those changes are idiomatic and don't violate the 'ethos of go'. But avoiding making those changes in the name of 'keeping it simple' never made sense to me in cases where programmers are shooting themselves in the feet and already not having a simple time with your language.
"Java, JavaScript (ECMAScript), Typescript, C#, C++, Hack (PHP), and more [...] actively borrow features from one another. They are converging into a single huge language."
https://www.dotconferences.com/2015/11/rob-pike-simplicity-i...
We've learned a lot about language ergonomics in the past forty-nine years. Generics are super useful. Lambdas and streams can cut down on a lot of boilerplate. Immutables make code easier to reason about.
And I'm glad that I have access to all of those things in Java. I'm not upset that my workday language is being polluted by outside influences, because I'm not a purist, I'm a programmer. I don't care that records were lifted from Scala and Kotlin ... I care about how they can make my code better.
The idea that we should deprive ourselves of useful features because it makes languages too similar makes no sense to me.
The point is not that they're withholding features because it makes the language too similar to others, and I'm sure that's not what you were really thinking the argument is either. The thing they're trying to focus on is that with ever increasing amount of features, you have an ever increasing amount of complexity added, which has implications on the amount of conversations, decisions, readability and difficulty your team is going to have when tackling any given problem. It can really just be boiled down to increasing features past what is needed can be considered bloat, which does not come free to a developer or team's collective consciousness.
To quote/paraphrase from the 5:10 mark of his talk...
"If a language has too many features, or even more than you might need, you spend time programming thinking about which features to use... you might even spend half an hour messing with a few lines of code to [see how a given feature fits into the solution]... [and even more, when you revisit that code, you have to get back into the thought process you initially went through when determining which features to use]."
On the other hand, adding language complexity can decrease program complexity a great deal. Generics are the prime example of this. If you see List<Foo> and List<Bar>, you know exactly how both work. But if you see FooList and BarList, you might have to stop and worry about how each is individually implemented.
Or the whole "while is spelled for in Go" thing. Sure, they managed to strike out one whole keyword from their language, but anyone coming from another language is going to have a momentary brain skip while they try to figure out why that is, and how they need to re-write their while loop as a for-loop-but-not.
Heck, even if you're greenfield 100% of the time, the way the OS, the networking stack, the browser, any runtime support libraries you depend on, all work plus just figuring out how to model the problem you're trying to solve is still more complicated than the actual programming language.
https://www.php.net/manual/en/control-structures.match.php
https://www.python.org/dev/peps/pep-0622/
https://www.infoq.com/articles/java-pattern-matching/
https://docs.microsoft.com/en-us/archive/msdn-magazine/2019/...
I could go on with various topics, immutability etc ... It's pretty clear that in the past 10 years language evolved more quickly and borrow concepts from other languages.
*Note that the new Python pattern matching has a somewhat controversial design, and it probably won't see significant adoption in the wild for several years, if ever.
And yet PHP, Java and C# MVC web apps looks all the same in both syntax and structure. Same syntax for interfaces, classes, namespaces, entity models, query builders, controllers, views and so on. A modern Symfony application looks almost the same as a Spring one.
These languages are more similar to one another than they were 6 years ago. I don't know if it was meant to be taken literally, but I definitely don't think it's "outright stinky" to claim convergence.
[1] https://blog.codinghorror.com/you-can-write-fortran-in-any-l...
1. Only superficially, because they all share the same basic flow-control constructs and (except for Python) the same C-inspired syntax. They all have totally different standard libraries, package ecosystems, etc.
2. I don't see what makes Go exempt, other than "wow great they didn't add generics bless the Go core team."
I don't think they ever said they wouldn't implement Generics. It was a matter of maturing and consideration of different proposals.
The Go way was code generation. After they included generics, I wonder if the go team has let go of that principle.