1. 6

    Can’t wait for Generics and I don’t think I am ever going back to a JVM based language!

    1. 2

      Maybe go will be worth another look after generics. I guess it should make implementing a sequence/stream API more feasible. Although I suspect the performance would suck, go probably can’t optimize the virtual function calls as much as a JIT can.
      Coming from a JVM background, and having recently written a CLI app with go, I found the experience extremely painful, and I don’t quite understand why one would give up a higher level language to work with go for non-trivial applications.
      Being able to easily build and cross compile native binaries is a great feature, especially for CLI’s, but if running a JVM isn’t a major constraint, I’d take any major JVM language over go.

      1. 2

        This kind of reflects my views about Go as well. I think once you are out of “simplicity” dogma, you quickly realize how messy the code gets with interface{} casts everywhere. I use generics on daily base! Even a basic cache requires generic support. I don’t want to litter my code with castings and ifs when there exists a decent solution to do all of the manual undertaking for you. That is what compilers were invented for rather than just generating plain code. You can obviously ignore them if you don’t need them; but I not having them is a big pain in the a**.

        1. 7

          you quickly realize how messy the code gets with interface{} casts everywhere.

          It should essentially never happen that you use interface{} in day-to-day code. If you’re having that experience, I can understand why you’d be frustrated! You’re essentially fighting the language.

          interface{} and package reflect are tools of last resort that really only need to be used in library code.

      2. 1

        Two more releases, likely :)

        I’m curious to see how the generics will work out in practice. But I do look forward to having a sane assert.Equal().