Does anyone else feel like this is reinventing the JVM Garbage Collection technology - which has at least 20 years of calendar experience and countless man hours of engineering research in the real world?
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.
Speaking as someone who writes go code every day right now, I like the language for a number of reasons, including the fact that it can be compiled and deployed without anything like the sort of build/deploy insanity that a modern java installation comes with.
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.
What kind of insanity? Are you talking about desktop or server apps?
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:
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.
> Speaking as someone who writes go code every day right now, I like the language for a number of reasons, including the fact that it can be compiled and deployed without anything like the sort of build/deploy insanity that a modern java installation comes with.
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.
> Does anyone else feel like this is reinventing the JVM Garbage Collection technology - which has at least 20 years of calendar experience and countless man hours of engineering research in the real world?
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.
Does anyone else feel like this is reinventing the JVM Garbage Collection technology - which has at least 20 years of calendar experience and countless man hours of engineering research in the real world?
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?"
Go is a drastically different language than Java. And porting over Java's GC wouldn't make sense.
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.
Yeah, but we're not comparing apples and oranges here.
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.
What would be the point of using Go if it needed a VM ?
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.
Sure ,if you're willing to pay $3000 per seat or use something free that hasn't been updated to the latest JDK. And it doesn't come with a guarantee of a lower memory footprint.
Despite all that effort, Java GC still has a lot of problems today; long pauses still happen in heavily loaded servers unless they're tuned carefully. Sometimes taking a fresh approach is worthwhile.
That's a valid question. I think the answer is: not everybody wants a language based on a relatively heavy/large VM. E.g. Go fits in much more with the UNIX tradition than Java does.
Not every language fits on the JVM, we shouldn't only have one VM for everything. GO is natively compiled and the runtime is only for GC very different models then Java
Writing a GC is an iterative process and the Go team are taking the steps to implement a modern GC. You don't work for 2 years and then throw it all in at once.
> 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?
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.
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.