5 ms·

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 lar

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.

enitihas 7y ago
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.
- swagonomixxx 7y ago
  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 :)
- uluyol 7y ago
  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.
  - enitihas 7y ago
    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,
hvs 7y ago
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.
- throwaway894345 7y ago
  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.
  - unsignedint 7y ago
    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.)
    - cy_hauser 7y ago
      > 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.
haolez 7y ago
What if "huge applications" is a bad pattern and Go is pushing forward in the right direction? :)
- uluyol 7y ago
  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.
qqssccfftt 7y ago
And when Java gets Project Loom then Go will not have any real world advantages.
- vips7L 7y ago
  If only the JVM could get it's memory usage down.
  - pron 7y ago
    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.
    - pjmlp 7y ago
      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.
      - pron 7y ago
        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 https://bugs.openjdk.java.net/browse/JDK-8234863).
        pjmlp 7y ago
        Agreed, but it depends very much on which JVM one is using, and not all of them offer the same capabilities as Hotspot. And then there is that other special flavour of coffee beans out there.
twblalock 7y ago
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.
- coryrc 7y ago
  Integrate `goimports` into your editor.
- spyspy 7y ago
  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.
  - xzel 7y ago
    But doesn't that require some level of generics? This is an honest question not rhetorical / a retort.
    - majewsky 7y ago
      Go has several generic functions like append() or make() baked into the compiler (https://golang.org/pkg/builtin/ 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.
      - xzel 7y ago
        I'm talking more along the line for Map/Filter/Reduce support and why those weren't included in Go originally.
pjmlp 7y ago
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.
apta 7y ago
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).

enitihas 7y ago

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.

swagonomixxx 7y ago
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 :)
uluyol 7y ago
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.
- enitihas 7y ago
  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,

hvs 7y ago

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.

throwaway894345 7y ago
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.
- unsignedint 7y ago
  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.)
  - cy_hauser 7y ago
    > 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.

haolez 7y ago

What if "huge applications" is a bad pattern and Go is pushing forward in the right direction? :)

uluyol 7y ago
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.

qqssccfftt 7y ago

And when Java gets Project Loom then Go will not have any real world advantages.

vips7L 7y ago
If only the JVM could get it's memory usage down.
- pron 7y ago
  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.
  - pjmlp 7y ago
    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.
    - pron 7y ago
      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 https://bugs.openjdk.java.net/browse/JDK-8234863).
      - pjmlp 7y ago
        Agreed, but it depends very much on which JVM one is using, and not all of them offer the same capabilities as Hotspot. And then there is that other special flavour of coffee beans out there.

twblalock 7y ago

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.

coryrc 7y ago
Integrate `goimports` into your editor.
spyspy 7y ago
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.
- xzel 7y ago
  But doesn't that require some level of generics? This is an honest question not rhetorical / a retort.
  - majewsky 7y ago
    Go has several generic functions like append() or make() baked into the compiler (https://golang.org/pkg/builtin/ 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.
    - xzel 7y ago
      I'm talking more along the line for Map/Filter/Reduce support and why those weren't included in Go originally.

pjmlp 7y ago

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.

apta 7y ago

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).