[int08h]

Re: getting tooling "right" and that driving adoption/popularity.

I'll argue that Java and the JVM are very similar in this respect. Few will argue Java is a "good" language and the JVM has many shortcomings.

However the ecosystem of IDEs, JVM tools, and decades of big company investment (Sun, IBM, Oracle) have created an amazingly productive environment.

[steinuil]

Yes, my impression is that Go was created partly to be used in corporate environments to replace Java with a less verbose language that scaled well, and it seems to be doing well in that regard.

[kuschku]

Sadly, it ends up far more verbose than Java when you have (as I did after trying to port a project from java to go) over 200 copies of the same observable, sorted, copy-on-write set implementation, because Go doesn’t have generics. And then you change one thing in one place, and gotta change it everywhere again.

No thanks.

[eadmund]

Surely you could have used interfaces for this case, no?

[kuschku]

And how do I get the same type out that I put in? I'd end up with Java 1 style programming, no generics, and having to cast atuff from Object/interface{} everywhere.

interface{} is like Object, if it even exists once in your code, it's broken.

[eadmund]

> And how do I get the same type out that I put in?

You can only get out the same type you put in. Presumably in your code you know that collection of Foo objects contains Foos, so you can just do:

    if foo, ok = collection.get().(Foo); !ok {
      return errors.New("expected a Foo")
    }

Write a few wrapper functions and you're done.

[kuschku]

So, we’re back in Java 1.0, and using Object and just casting back again?

Seriously, this is why generics exist. I want to write it once, use it everywhere again, and want to have the compiler know if I made a mistake.

[wyager]

A couple reasons that wouldn't work well (there may be more, I haven't thought about this much):

1. Using an interface would nuke your performance. Data structures where every data structure operation requires one or more vtable lookups on items in the structure can really hurt your time and space performance. To get good performance, you need true type-level generics so the compiler can specialize at compile time.

2. Anyone could put anything that followed the interface in the data structure, even if it was of the wrong type. To get any form of static type safety, you'd still have to define a wrapper type and a bunch of functions for every type you'd want to put in the data structure. You could save a bit of work by re-using your (slow) code you wrote generically using interfaces.