Whatever your thoughts are on Java the language - would it not make sense to focus efforts on the OpenJVM project and all the languages it can support?
Genuinely curious if this seemingly "reinvent the wheel" approach is going to provide benefits.
So, I'd rather hit my head against the wall on GC problems while smart people improve it than hit my head against the wall with a MASSIVE deploy/build headache that definitely won't go away for a bunch of technical, political and historical reasons.
Once properly set up, deploying Java is usually a one click affair, not sure what insanity you are talking about.
Also, Go is compiled natively which certainly complicates the deployment mode (and expect more complications down the line once Go supports dynamic loading).
Either way, Go's deployment model doesn't have much to do with the language and it will become more complex if the language becomes more popular.
Whichever you mean, you can create apps that have self contained JREs with the javapackager tool. But most server setups don't seem to need it. If you have a broken IT environment where your admins refuse to upgrade the JVM, that can be an issue, but then you might find yourself being told to stick with an obsolete version of Go in future too in such an environment.
I'm not trying to start a religious conversation; so with that caveat, I'll respond -- By insanity, I'm referring to the need to grok stuff like this page:
http://maven.apache.org/guides/introduction/introduction-to-...
Building a large java application is not something I'm an expert at, but I have spent many hours of my life fighting with maven and ant and dependencies, happily some time ago.
By comparison, there's "go build". Or if you need auto-cross-compiling, there's goxc. While an IT manager might limit the version of go on a server, it would have no impact on most go developers; I can build a self-contained binary for linux right from my Macbook Air in under 2 seconds with a single command. Or using goxc, I can build for all binary targets in very short order.
To me reducing this sort of cognitive load on build/deployment is a HUGE benefit go provides, especially to junior developers or teams with different backgrounds.
Building in Java is also a one line command. Deploying is also often a one line command (or a one click affair).
The fact that Go is natively compiled makes this kind of deployment a bit more problematic, and it's bound to get more complicated once Go supports dynamic loading.
I'm not trying to make a judgment call between Java and Go here, just pointing out that saying that one of these language is insanely more complicated to deploy than the other doesn't make much sense.
No, because GCs optimizations are very dependent on the semantics of the programming language.
There isn't something like a general purpose GC algorithm for every type of programming language out there.
Funny, but over a decade ago, we Smalltalkers were once asking: "Does anyone else feel like this is reinventing Smalltalk GC and JIT VM technology - which has years of calendar experience and countless man hours of engineering research in the real world?"
I'm sure Lispers have similar things to say.
In Java, everything except primitive types is a pointer. In Go, on the other hand, programming "by value" is encouraged (pointers are explicit, never implicit). In Go, it's possible to actually avoid creating garbage altogether - you have a decent amount of control of where memory gets allocated.
Thus porting Java's GC, which has been highly optimized to deal with hundreds of short-lived objects whose allocation you as a Java programmer have no control over, wouldn't make sense - it's optimized in all the wrong places, for Go, basically.
The Go team have already adapted GCC to their language, for example. They could have also adapted the JVM. For instance the Java guys are adding value types at the moment, but most of the reason it's hard/slow for them is backwards compatibility with existing code. Go doesn't interop with anything except C anyway, so they could just throw that requirement out and have a customised GoVM that supports value types and so on, whilst reusing all the other technology in there.
No VM is one of the reason people use Go, along with easy concurrency backed directly in the language and not as a third party framework.
IF you find the JVM so awesome ,keep using it. I personally think the memory cost isnt worth it ,and when I say cost, I mean the actual cost in $$$. Hardware might be cheap, the cloud isn't.
Just because the option isn't part of OpenJDK, doesn't mean other commercial JVMs don't offer it on their toolchain.
That assumes everyone wants a language on the JVM.
Putting Go on the JVM would be taking a language that only has a few "great" features (fast compile/startup time, decent memory efficiency, simple static binary output) and neutering it to the point of irrelevance.