So I think it will be a huge step up for Go. This is of course if they do it in such a way that does not increase language complexity by an order of magnitude (e.g C++ style templates). I think Java style generics is not as complex and something along those lines would be a huge win IMO.
Again, I don't expect my personal preferences to dictate language development. Clearly many do not feel the way I do, but I do find it telling that those were the top two complaints. The pain is real, at least to a subset of us.
One aspect may be tools, too. Generics works great when things like contextual code completion (e.g. Intellisense) is present. One might see a bit of gaps, where someone's coming from C# on Visual Studio, compared to someone doing the same on a simple text editor. For this, I wonder if there's some correlation to preferred development environment, too. (IDE vs. editor, for instance.)
That's it right there! With Go you have to get over this idea that _your_ preference has any place in Go code. Go was designed to be inflexible in style and immune to preference from the start. For those new to Go, if they can't get over that hump then it's really hard not to be frustrated with the language.
Some may see the language being way too opinionated for that aspect, while some may be fine. (Also if such style is already aligned with their own established preference.)
I myself prefer less opinionated languages. As a professional, if someone presents me with a Go code, I will of course work with one, but it definitely won't be my go to language.
Oh, and let me leave "fmt" in the list of imports even when it's unused, because adding it every time I stick in a printf to debug something, and then needing to remove it later because of compiler errors, is incredibly frustrating.
I guess it will complicate things a bit, you're right. I'm pretty happy I don't have to use Java anymore though :)
Until Go comes with an OS, a set of drivers comparable to JDBC for Oracle, SQL Server, DB2, Informix, CMS tooling like Magnolia/Liferay, profilers like VisualVM/JFR, graphical debuggers (delve just barely does it), code reloading, dynamically loading, an UI toolkit that at least matches Swing, and plenty of other stuff, I rather leave it to Docker/K8S tooling.
And then there is that other special flavour of coffee beans out there.
Another big one is the data model. Go doesn’t have object types nor inheritance; it has value types, interfaces, pointers, and closures. While in Java I don’t have to use inheritance and one day there may be value types, inheritance and objects are and will continue to be pervasively used in the Java ecosystem, which means I’ll have to interact with lots of such code. Not the end of the world, but I really don’t enjoy it—I wouldn’t spend time fighting it if I have the option of using something else. More importantly, the data model and Go’s AOT allow me to reason about code performance more predictably, although JVM’s JIT compiler would be really nice for the very few highly dynamic programs that I write.
Notably, I don’t think Go does everything well or that it’s AOT model is good for everything and Java’s VM model is bad for everything. I actually would like to see a simpler, high performance JITing VM with better semantics for languages with value types (and a lower latency default GC although I hear that is improving in recent JVMs). I specifically don’t want all the bells and whistles for tuning my GC or my VM. I also want a dramatically simpler language running on it. Maybe a super simple lisp or something like Julia but geared toward general app dev.
I hear you re tools. I think there's definitely room for simpler ones, available out of the box. Anyway, I'll save your comment for future reference when the topic comes up (I work on OpenJDK).
As for GC, ZGC will have lower latency and higher throughput than Go's GC within a year, and the only tuning it needs is setting the heap size, and I expect Java will gradually increase the performance advantage it already has over Go. BTW, perhaps my biggest intrinsic reason for preferring Java (other than ecosystem size) is observability, which is also getting better with each release, and is probably ahead of any other mainstream runtime/language out there (and most non-mainstream ones, too), followed by performance, maintainability and flexibility.
* https://blogs.oracle.com/javamagazine/java-flight-recorder-a...