There are many of us in the Go community who like Go the way it is. The last thing we want is another Java ecosystem, which feels like something designed by archonaut committee more than anything coherent. Better to not have generics than to have generics that are bodged into the language like they were in Java.
> The last thing we want is another Java ecosystem,
Which practically contains almost everything one can think of? Yeah, like that's not a good thing. Where's the golang equivalent of Hadoop, Spark, Vertx, Netty, Akka, etc.? Not to mention the Java standard library with it's new time package, and java.util.concurrent, and many more.
> Better to not have generics than to have generics that are bodged into the language like they were in Java.
Strawman fallacy. Not to mention that generics in Java are not botched, they made a tradeoff and it paid off quite well, just look at the number of existing JVM languages. That beings said, there is work being done to improve generics in Java even more.
The Java time package has been a disaster for 20 years until Java 8, before that everyone was using Joda. As for generics have a look at what C# does for "proper" generics.
I'm aware of what C# does, that's why I said it was a tradeoff. Compare the number of languages on the JVM to those on the CLR to see why they made this tradeoff. The JVM folks are working on improving generics even further in upcoming releases.
I know about Joda time, that even another point in how mature the Java ecosystem is. There's no similar offering in golang.
> Compare the number of languages on the JVM to those on the CLR to see why they made this tradeoff
IMO the main reason why people aren't creating more CLR language is unrelated to generics. You can compile many languages to CLR bytecode and never emit these ldelem/stelem/unbox.any instructions. The main reason is C# is good language, and it evolves fast enough.
I don't believe Java developers deliberately crippled Java to incentivize third parties to develop more JVM languages.
Java Time is a renamed Joda Time with some improvements, from the same guy who did Joda Time. It's a pretty great example of Java being defined by its community actually.
You think it's a good thing. The parent doesn't. So isn't it better that both Go and Java exist, rather than Go be Java-ised, so you both get what you want?
> Strawman fallacy.
It's only a straw man to those who like the tradeoff. Tradeoffs are always a matter of judgement. The parent (and many others) make a different judgement to you. So isn't it better that both the Java and Go approaches exist, to satisfy different tastes?
This is my biggest worry about the future of Go, that it will gain enough adoption at enterprise shops that we'll end up with another Java-esque ecosystem. So far it has seemed to have avoided that trap, but it is still a young language.
I am ... Quite surprised to see folks arguing that Java has "too many" features. For a log time the problem was we couldn't get ANY new language features through committee and so we were resorting to outrageous hacks.
The only people in my experience that complain about the Java ecosystem have limited experience with Java 7 or before and haven't done any real modern Java development in many years.
I've been using Java since it was released, and (at the same time) Go for several years now.
The amount of cognitive overhead in dealing with all the history that's baked into Java is really annoying. Things like the dated concurrency model, the overachieving in logging (and other) libraries (when one to use?), the poorly thought out I/O libraries, the crazy build tools and slow builds, ... It's always a relief to get back the the smoothness of Go.
