I think some of us already had that with the first Java versions. Actually, Go looks a lot like old Java versions, minus the VM, plus Goroutines/channels, and static duck typing.
I have written a fair share of Go code and ultimately it's a very boring, but predictable language. If it builds a larger ecosystem, it will not be much different than a Java that compiles to native code. Without some of the advantages of the JVM.
(What we are really seeing here on HN lately is a hype, pretty much like node.js and FP before. Go has a better chance to stick, because it has a good steward.)
I kind of agree with that, but Java really needed a reboot. It's more a cultural thing than a technological one.
But I'm actually a bit cynical about that. Pretty soon the framework peddlers will descend on Go just as they have descended on Java, JavaScript and Python. Once again a couple of switch statements will be replaced by tens of thousands of lines of framework code.
It will be called "beautiful" and "elegant" and "DRY" and those still complaining about the bloat will be told that they don't have to use the features they don't need, but not knowing all the features and all the hooks and all the optimization tricks will once again make you look incompetent and behind the times.
Yeah, it's the Java culture and the stuff bolted on top by Sun and other business software vendors in an effort to keep relevant and appeal to CIO:s.
But I don't agree with the prediction:
Python and JavaScript aren't really drowning in BS produced by architecture astronauts. It exists but it's not prevalent.
- "Write once, run everywhere." as the sibling poster mentions. I can build on my Mac, deploy on whatever the server platform is.
Snapshot and release builds of our build server are distributed via a Nexus-managed repository. So, everyone codes against exactly the same dependencies, regardless of the platform.
- Hotswapping/JRebel.
- Good interoperability with other languages. E.g. the Typesafe folks implemented Akka in Scala. Java gets it for (well, almost) free.
- Easy monitoring and instrumentation.
Obviously, there are downsides as well, such as startup times (twofold: starting the VM and Hotspot detection/compilation), preset heap size, expensive JNI (native interface), etc.
Except that Java code typically runs as fast or faster in the JVM than compiled Go code[1]. Of course, Go is still new and gc and gcc-go will be optimized further.
But Java bytecode execution is definitely not slow and usually within 2x the execution time of a C implementation, which is faster than the vast majority of other language implementations.
[1] At least in the language benchmarks game. Yes, I know that microbenchmarks are not representative, etc. etc. etc. (Until your favorite language is faster ;).)
Well-defined semantics, including for "errors" like integer overflow or null dereference.
A community that's converged on a deterministic, crossplatform way of representing library dependencies (maven).
An ABI that includes a notion of objects, which makes cross-language interoperability with objects easier (though counterbalanced by not having a cross-language notion of functions).
I think some of us already had that with the first Java versions. Actually, Go looks a lot like old Java versions, minus the VM, plus Goroutines/channels, and static duck typing.
I have written a fair share of Go code and ultimately it's a very boring, but predictable language. If it builds a larger ecosystem, it will not be much different than a Java that compiles to native code. Without some of the advantages of the JVM.
(What we are really seeing here on HN lately is a hype, pretty much like node.js and FP before. Go has a better chance to stick, because it has a good steward.)