I agree that they all converge on a standard set of features, but I disagree that the features are needed.
You could get everything done with Javascript's prototype system that you wanted done with classes.
You can get everything done with Go's interfaces (and a bit of boilerplate for the edge cases) that you can do with generics.
The problem is that people come to this language from other languages, and have expectations that this language is basically the same as the other language they already know (and if not, why not?). There's a constant pressure on languages to conform to a single set of "known good" conventions [0]
The unusual languages are needed because we need that diversity, but they are never going to be "mainstream" until/unless a Java dev can learn them inside 3 months without challenging any of their assumptions about programming.
[0] the classic is Erlang vs Elixir - Erlang is "weird", Elixir is "awesome"
> You could get everything done with Javascript's prototype system that you wanted done with classes.
> You can get everything done with Go's interfaces (and a bit of boilerplate for the edge cases) that you can do with generics.
by that logic why don't you just use lisp for everything ? it's been there since 1958 and you can also get everything done with it, including reimplementing yourself a Go- or Js-like DSL if you allow yourself a Racket.
The truth is, your "get everything done" actually does not include everything, because "writing less boilerplate" is not only a feature, but one of the most important ones. Boilerplate is unambiguously bad and a place where terrible bugs hide - any time you can replace it by something with much less chances of bugs, such as a language feature, you should (and I'd argue it's professional malpractice to chose not to when you have the option).
Boilerplate isn't necessarily evil. Imo, repetitive boilerplate is where the problem comes in. I.e. it's not a bad thing that every HTTP app has an almost-the-same way to start the HTTP server. It is a bad thing when you're writing almost the same code but with different types 37 times.
There's a seemingly inevitable tradeoff between complexity and bugs. Low complexity tends to lead to repetitive, simple, avoidable bugs. High complexity leads to unique, hard to reason about bugs.
I find the preference for simple vs complex code has to do with what kind of bugs programmers want to troubleshoot. Some prefer simple and repetitive bugs, others prefer fewer, more difficult bugs.
On that note, I remember when Borland released BIDS 1.0 and was doing with the preprocessor what Go, reinvented almost 20 years later.
Or using Eclipse EMF to read UML interchange files generated from Rational Rose and generate the boilerplate for Java applications, before generics and compiler plugins were a standard Java feature.
When languages aren't feature rich, someone will eventually start writing that boilerplate, hence why //go:generate exists, despite the fact that Go people telling writing boilerplate is not a problem.
You could get everything done with Javascript's prototype system that you wanted done with classes.
You can get everything done with Go's interfaces (and a bit of boilerplate for the edge cases) that you can do with generics.
The problem is that people come to this language from other languages, and have expectations that this language is basically the same as the other language they already know (and if not, why not?). There's a constant pressure on languages to conform to a single set of "known good" conventions [0]
The unusual languages are needed because we need that diversity, but they are never going to be "mainstream" until/unless a Java dev can learn them inside 3 months without challenging any of their assumptions about programming.
[0] the classic is Erlang vs Elixir - Erlang is "weird", Elixir is "awesome"