No surprise to see generics being so strongly pined for again. Very curious about how Go getting generics will change its position in the landscape.
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...
Go cannot get generics because "conservative politics" in its community period. A lot of prominent gatekeepers are all about the status quo.
There are a few things Go could do to make it easier to work with, ease "type equivalence", introduce some covariance into the mix. Maybe unions, maybe replace multiple return types with tuples and destructuring assignement.
I don't believe a second Go will ever get generics and the courageous proposal done by Ian Lance Taylor, the hero of the language right now, won't really satisfy anybody because it's too complex yet doesn't do that much IMHO.
This is purely a political question, not a technical one. We had that debate for almost 10 years now and I dread more petty drama.
But I agree with you, as seen by the commit messages they still aren't fully there, and at the end it might just happen as with the error proposal anyway.
Who are these ?
Well, only 25% of respondents said there were any features blocking adoption; and of that group yes the majority want generics. Since this is a survey of Go developers, it is not surprising to find out that a very solid majority find the language usable as it is. I think this also limits what this particular survey can tell us about the uptick in adoption you might see if that feature ever lands.
I think it'll have minimal immediate effect. It'll quieten the vocal ones, but being a pragmatic bunch of people, most golang users just won't care much, at least at first. No doubt libraries will adopt it over time. Other golang projects will slowly follow.
Protecting map with a lock is a very naive solution, it'll perform badly with a lot of concurrent writes.
There's just no good reason that you can't reuse it without rewriting all call sites. []T and map[K]V and chan T should implement interfaces, everyone should always use those interfaces, and monomorphization should skip the runtime dispatch.