Well, the JDK's ArrayList, for example, will box ints into Integers, but there are primitive int lists that won't. With Go, AFAIK, the problem is exactly the same. Can you write, say, a heap or a read-black tree that can store wither ints and strings, that will embed the ints? Also, value types are making it into the JVM in Java 9. I don't think that will solve the packed representation in a generic data structure problem, but neither does Go. OTOH, Java does optimizations that Go never can. For example, Java can inline interface calls, which Go can't (and due to the way Go defines interfaces, method calls are slower than Java even when not inlined in either).
Having said that, there are things about Go that I like better than Java: 1) no implicit primitive promotions (widening conversions), 2) a small standalone executable, 3) excellent start up time. The latter two make Go suitable for quick, small programs, like command line tools etc.
However, there are more things I like about Java the Go doesn't have: 1) dynamic linking, 2) final variables, 3) concurrent data structures, 4) awesome monitoring and profiling tools, 5) generics, 6) state-of-the-art GC, 7) a polyglot VM (I also prefer Java's exceptions and explicit interface implementation, but these are minor considerations). So whenever I need serious, long-running, server-side software, I'd stick with Java over Go. Particularly now that Java has fibers (goroutines)[1] (I'm the main author).
> Can you write, say, a heap or a read-black tree that can store wither ints and strings, that will embed the ints?
I'm not sure I understand this sentence. Do you mean a union type? Or a generic datastructure? We all know Go doesn't have generics - that topic has been beaten to death, so let's not derail the discussion and just say this can be a valid reason for Go not fitting your use-case. But just for comparison, here's an implementation of a "generic" LLRB Tree in Go using interfaces and runtime reflection:
> We all know Go doesn't have generics - that topic has been beaten to death, so let's not derail the discussion and just say this can be a valid reason for Go not fitting your use-case.
Parents point was that Go will still box primitives in a generic collection class...just like Java does. So this isn't a special advantage of Go at all (it has nothing to do with Go not having type parameters). The only languages that don't box in generic collections is C++ and perhaps C# (it doesn't have to because of its template-like type parameter semantics, but still might to reduce code duplication).
Right. Although the template method has its own issues. For example, once the element type size exceeds 64 bits, you can no longer assume an atomic write/read. This isn't a big problem considering that concurrent data structures don't usually rely on the write/read atomicity of the elements themselves (though they do rely on atomicity of modifying internal, structural data), but that's just something to think about.
You couldn't write a generic tree that packs the ints closely together, no. But you could write a non-generic tree that does.
Also, Dave was talking about Lists, which you certainly can have packed with ints trivially in Go. And every piece of software I've worked on uses approximately a million times as many lists as trees. Obviously, this is application-specific, but I think it's pretty fair to say that most programs will use a lot more lists than trees. If your application uses a lot of trees, Go is probably the wrong language for you, unless you're willing to make a tradeoff by using code generation to generate type-specific implementations.
> But you could write a non-generic tree that does.
As you could in Java.
> Also, Dave was talking about Lists, which you certainly can have packed with ints trivially in Go.
What lists? Array lists? Linked lists? Skip lists? Concurrent array lists? Concurrent linked lists? Concurrent skip lists? Go gives you packed ints for only one kind of list.
> If your application uses a lot of trees, Go is probably the wrong language for you.
Or if it uses any advanced data structure that Go simply doesn't have, let alone concurrent data types (Java has such a rich collection of data structures, usually with state-of-the-art implementations). Or if you need dynamic code loading. Or embedding a scripting language.
I actually think Go is a very nice language, but Java is much more appropriate for serious, long-running, high-performance server-side apps.
Having said that, there are things about Go that I like better than Java: 1) no implicit primitive promotions (widening conversions), 2) a small standalone executable, 3) excellent start up time. The latter two make Go suitable for quick, small programs, like command line tools etc.
However, there are more things I like about Java the Go doesn't have: 1) dynamic linking, 2) final variables, 3) concurrent data structures, 4) awesome monitoring and profiling tools, 5) generics, 6) state-of-the-art GC, 7) a polyglot VM (I also prefer Java's exceptions and explicit interface implementation, but these are minor considerations). So whenever I need serious, long-running, server-side software, I'd stick with Java over Go. Particularly now that Java has fibers (goroutines)[1] (I'm the main author).
[1]: https://github.com/puniverse/quasar