Rust can't settle down right now, because it still has to make necessary changes to critical parts of the language, such as async.
Go always had a very narrow and precise ambition and scope (a better C, aimed at server-side data plumbing). Which is the reason why it was able to nail a set of features from the start and keep it that way.
Rust has a much wider ambition : all the modern languages facilities (generics, metaprogramming, etc) with the speed of C, AND breakthrough memory-safety features.
Go doesn't try to innovate, and i suppose the author see innovation as something you should stay away until it's nothing new anymore.
One day, when it has proper generics, interface validation without compiler error tricks, and an usefull portable UI library, it might be a better Java.
More like a "different Python" than a better one. Way more performant, way more verbose, and (IMO) way better concurrency.
Not to go off on too much of a tangent, but I think asyncio is a huge mess and was a mistake. I still use gevent for everything in Python. https://glyph.twistedmatrix.com/2014/02/unyielding.html is frequently cited as an argument for why goroutines and gevent and green threads suck and why explicit asyncio-style concurrency is better, but I have a lot of issues with this article and find the former two way easier, simpler, and faster to work with.
I went to a Go meetup where I use Go as a complement to Ruby. The speaker and most of the others there were using it as a more expressive/easier C. The middle ground it has carved out seems to let everyone say that their language does something better, but there seems to be a good chance that Go does a reasonable job at what their language doesn't do well (and isn't too far off to learn).
I feel like there is a better way of posting this argument than laughing at them and dismissing what they say, and not providing any reasons why you disagree.
Java got async I/O in 2002, generics and "for (x : iterable)" in 2004, and lambdas in 2014. Vintage 2001 Java was drastically harder to read and slower, though error handling was always less cumbersome than Go.
It sounds like the point the person was trying to make was in use-case, rather than language semantics. As in, where one might've used Java before, they would now use Go. Not that Java and Go are semantically similar.
Installable binaries, around 2000, when the first commercial JDKs started having AOT compilation to native code.
Currently available on PTC, Aicas, IBM, OpenJDK AppCDS (originally from BEA J/Rockit), GradleVM native images, Android ART AOT compilation.
Dynamic heap size, since ever. Every JDK vendor had their own specific switches to configure it.
Versioned modules, since Java 9 alongside Maven/Gradle.
Value types, yeah point taken. There were Azul and IBM specific extensions, ObjectLayout and PackedObjects respectively, and the 2nd experimental release for value types was just made recently available.
If that would be the case, the companies that sell commercial JDKs would be out of business, and yet here they are, selling Java tooling since around 2000.
Maybe you are referring to the "real world" where developers don't pay for their tools.
As for embedding 150MB of JRE / JDK, it is hardly any different than embedding the Go's runtime into every static compiled executable.
Practically speaking this is a non-issue, since its not 1996 anymore. You install the JRE / JDK into your VM or container image. And you basically never think about it until you need to do an upgrade...
I don't know if "all the modern languages facilities" was a goal of Rust from the start. It seemed like the initial goal was to be able to develop a web browser with memory safety.
"all the modern languages facilities" seems to be something that's come along more recently (last couple of years) as a result of a lot of non web browser developers taking an interest in the language.
Go always had a very narrow and precise ambition and scope (a better C, aimed at server-side data plumbing). Which is the reason why it was able to nail a set of features from the start and keep it that way.
Rust has a much wider ambition : all the modern languages facilities (generics, metaprogramming, etc) with the speed of C, AND breakthrough memory-safety features.
Go doesn't try to innovate, and i suppose the author see innovation as something you should stay away until it's nothing new anymore.