Yeah, I edited it out because after I took a breath I figured you didn't mean it that way. =) Hugs all around.
But I really don't think it's a major thing, because there's no meaningful difference, in terms of performance, between "struct { int x; int y; } A" and "int Ax; int Ay;". I'm suspicious of claims that Go, as fundamentally a not that different language to a JVM language, is going to yield significant performance benefits. I'm not saying they aren't a nice convenience (value types are one of the things I love about C# when I'm writing code under MonoGame), I'm saying that I can't think of a reasonable way, barring bugs or short-sighted implementations, that they made for faster code.
Java value types are going to be in Java 10 i.e. years away. So may be it is not big deal for you but JVM developers think it is going to be big deal for lot of performance sensitive code.
This is despite the fact that most advanced GC available in Java.
Are you aware that Java already has value types? Do you realize that the JVM has primitive collections, which completely ignore all of the boxed types that are, yes, a performance suck, via Trove? Nobody writing perf-conscious Java is using bleeping HashMap<K, V> or even ArrayList<T>. They're using Trove's TIntIntMap, TLongSet, etc. and getting the. exact. same. thing you're saying they're not.
Or they're using arrays. And here's the one difference that I have acknowledged since my first post, but there's a but to it: there is one material performance-relevant difference between parallel arrays-of-members and arrays-of-structs, and that's locality of reference. But any multithreaded (or cooperative, for that matter) system of nontrivial size is already chucking cache coherency out the window to the point where I'm very, very skeptical of the claims of magicfastness because two int members are next to one another. If you can prove that cache coherency is killing you and you need to run more consistently to avoid eviction, then you can push the problem into a minimal process without much going on and `nice` it to keep your cache lines for longer, but you're still in the land of Things That Are Not Made Easier In Go, Either.
Those JVM architects are considering structs--using the CLR term for "stack allocated aggregate types" because they're already there and I've done this side-by-side comparison in that environment, which is as close a one to the JVM as exists that supports them--as a convenience and, in rare cases and in extremity, a legitimate performance improvement. A good idea to have. But it's such a corner case that even they feel comfortable pushing it, and its ramifications, to Java 10. (If you want to see why it's a corner case: again, go look at the CLR and how rarely structs are used. I'm almost as comfortable on the CLR as the JVM, and I make video games. I use structs. I've never, ever seen them in the wild in somebody else's non-library code, where you can encapsulate your perf grossness anyway.)
Go still has the heaviest performance overhead of all: having a garbage collector in the first place. The same things that cause memory pressure in Java cause memory pressure in Go. Which is what I am saying and getting downvoted for my troubles--that there is so very little daylight between the Go VM (yes, it's compiled to native code, it still has a frigging VM, go look at its bogus ART with ALWAYS CAPITALIZED INSTRUCTIONS because Rob Pike and company think not-actually-assembly programming is a "fraught endeavor" and you can see it yourself) and the JVM that claims about performance are real, real sketchy.
I've been down this road. I've looked. I don't see it. Linking to corner-case proposals (again: good ones, but marginal) from Java architects who are in the unenviable boat of trying to create bullet-point equivalence between the JVM and the CLR--that's not actually an argument.
Thanks for the tip on the Trove library. Even though I hate the JavaXML language, the JVM is really hard to beat for long running processes on a dedicated server. And the kids gotta eat, so JavaXML it is...
(have an upvote from an otherwise Java lang hater for being convincing)
Aside: I propose renaming the primary language for enterprise apps to just one word, "JavaXML" (zha VOX em el), since the two are essentially inseparable anyway. I wish the other JVM languages would get more traction in BigCo development.
Please don't mistake any of this as defense of Java, I think the Java language is an inexpressive slog (though for my money superior to Go, the lack of generics really is that much of a problem when you write modular and composable code where the HTTP server is not the IPC layer). I use Scala or JRuby when I use the JVM, except when I need to know exactly what the compiler is going to be spitting out, like when writing performance-sensitive code. This is rare, and I think the last time I wrote any Java at all was in a Google interview where they wanted me to juggle byte buffers. I use Ruby for things I don't care about or where a type system actively works against me. I use Scala for things I do care about or where a type system can help me. I use C++ for things where a garbage collector is antithetical to my purposes. (I have some hope that Rust will be a good candidate to replace both of the latter.)
Though, food for thought: I have written a fairly decent amount of Java in the past, and in what I would consider "modern practice" it has very little to do with XML. With Play, Dropwizard, and similar, you have no obligation to put up with something like Spring herpderp anymore. Or even Maven; SBT or Gradle are fine.
.
Anyway--what grinds my gears, and why I posted at all, is that I have noticed in the Go community--not, I hasten to mention, enneff, as he said I think he and I are probably more in the space place than not--a really weird unwillingness to credit other environments for anything, whether from stubbornness or ignorance. If I can speculate--and I can--I think that comes from two places. I think one is the origination of many Go advocates being Python and Ruby, which are both former new-hotness ecosystems that themselves don't encourage breadth or depth in the programming languages space; in the Ruby community at least Java is often held as this inscrutable "enterprise" thing that can't possibly have any real benefits, and I feel like that's leaked into Go. The other is the cultural origination of Go in Plan 9--Keith Wesolowski's views on the second-system effects of Plan 9 and the epistemic closure and cult-of-personality effect of its developers and community are good ones and I don't need to repeat them here.
Right now, to me, Go is a mishmash of Java 1.3 and Java 1.4, right down to the overuse of green threads and the too-simple type system that forces you to trade safety when you want code reuse. And that's totally fine for people who like it. But it's nothing special, and the breathless hype around it from people who plainly haven't gotten their hands dirty with what came before makes me want to boil my head. Or their heads. After all, I like my head.
But I really don't think it's a major thing, because there's no meaningful difference, in terms of performance, between "struct { int x; int y; } A" and "int Ax; int Ay;". I'm suspicious of claims that Go, as fundamentally a not that different language to a JVM language, is going to yield significant performance benefits. I'm not saying they aren't a nice convenience (value types are one of the things I love about C# when I'm writing code under MonoGame), I'm saying that I can't think of a reasonable way, barring bugs or short-sighted implementations, that they made for faster code.