If Go ends up getting generics it will be a serious competitor to Java in the enterprise small-medium size application space, and perhaps make it viable for larger applications.
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.
I'm probably not representative, but when I last really tried to use Go on a project seriously the lack of generics and the way that errors were handled became a real blocker for me. Which is unfortunate, because I really wanted to like the language and did for the most part. But those two things made development feel like a real chore.
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.
I hear complaints like this sometimes but I don’t relate. I don’t know if my style of programming is simply less abstract than others or if I just learned how to write (typesafe) abstract code without depending heavily on genetics. Note that there are still times where I can’t get the abstraction I want in a typesafe way, but these cases have been rare for me.
I feel it really boils down to the preferences and approach to the programming. My preference is C# and having no generics and exceptions irritates me quite a bit. (among with unused import/variable and styling being enforced.)
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.)
> I feel it really boils down to the preferences and approach to the programming.
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.
As a Java developer I would need a few things to switch and maintain my current level of productivity: generics, a map/filter/reduce paradigm for working on collections, and more flexible error handling -- in that order.
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.
It's been an unpopular opinion but I've contended for a long time that if Go had map/filter/reduce from the onset like it has copy and append, most people screaming for generics would have been silenced.
Go has several generic functions like append() or make() baked into the compiler (https://golang.org/pkg/builtin/). When people are asking for generics, they're asking for a language-level mechanism for defining additional generic functions beyond these provided by the compiler.
Yes. The distinction is that there are two ways to implement map/filter/reduce: either as additional built-in functions or in std. Only the second way requires language-level generics support.
Java is moving to complicated generics though, see project Valhalla, although not like C++ templates, but more about specialization for primitive types, which can be a huge performance win.
More complicated for the JVM to implement, sure, but if anything, won't this simplify the semantics? Users don't need to worry about boxing/unboxing values.
I am eagerly waiting for this to land, but it will complicate both JVM implementation and user programms, since now List<int> might be a separate class,
Interesting, I haven't heard of Valhalla (I haven't really used Java since around 2014). From their landing page it seems like their priorities are value types (which Go already has - you need to specify pointer types explicitly) and support value types as generic type parameters, which Go has to do, because it has value types.
I guess it will complicate things a bit, you're right. I'm pretty happy I don't have to use Java anymore though :)
An eco-system is much more than a language grammar.
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.
I don't even know what this means. Are you arguing for doing less or breaking up a task into components like with microservices? If the latter, all you've done is changed the scope of the application (now your application is made of multiple services not one), not it's size. If the first ... not all problems are small.
golang has got nothing on Java's (and the JVM's) performance, monitoring, profiling, GCs, etc. Not to mention all the new features Java is getting which are not even on golang's roadmap, such as records and pattern matching. This is not even touching on golang's bad design decisions that won't get fixed (e.g. structural typing of interfaces).
I think that >75% of people who complain about Java's memory usage don't provide a heap size and use the default, which is asking Java to go ahead and take up up to 25% of RAM whether it really needs to or not. You want to use less RAM? Tell Java to use less RAM.
And even then, many are just doing bad stuff like using new in loops, iterators in hot loops, and most relevant not actually thinking about their data structures.
Iterators and other allocations in hot loops are not universally harmful to performance and footprint. Very often they are scalar-replaced (allocated on the stack and reused)-- in fact, if they don't escape, they're almost certain to be. Escape analysis is also now significantly stronger and able to see through abstraction in JDK 14 thanks to increasing the default inlining depth from 9 to 15 (https://bugs.openjdk.java.net/browse/JDK-8234863).
Because it is too high or too low? What would be a sane default? Note that native applications don't have an upper limit at all, but to Java's GCs will be happy to trade available memory for performance.
Tooling and deployment are two big ones. Go doesn’t have a Turing complete DSL for it’s project files (that you have to run in daemon mode if you want a fast feedback loop); just a simple list of dependencies and a lock file. Testing is dead simple and built into the standard library and toolchain. Documentation generation is just comments; no javadoc syntax to learn, nor documentation packages to build and publish—godoc.org and friends can read any package available to them (including private repos if you host your own instance) and they automatically link to other packages’ docs without additional work. Also, static linkage by default that just works—yeah, fat jars and AOT are things in the Java world, but they take extra setup and often they aren’t feasible in practice. Meanwhile, I can send a Go binary to any Linux server and it will run. A lot of Java people love Java tooling because everything is super configurable and you can do just about everything you could ever theoretically want to do, but I rarely find this helpful—Go’s tooling generally does what I want it to do; I rarely have problems but I benefit immensely from being able to quickly figure out how to solve my problem. Different values, I guess.
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.
Yeah, I've been hearing that the ZGC work is promising! What an exciting development! It's interesting that you cite observability--I've always been of the impression that observing the inner workings of the JVM is tremendously difficult and requires a high degree of expertise? I'm tremendously impressed with the JVM as a runtime (JIT and ZGC); I just hope they're (you're?) able to really make the developer experience seamless so things Just Work.
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.