I share the sentiment. People often mention that Go is less verbose than Java like they were talking about Clojure or something. Go is just a little less verbose than Java (other than in a hello world example), and targets the same conceptual "level" (same order of abstractions, same "distance" from the metal, although Java can get closer to metal than Go). So, sure, it feels a little more modern in some respects (and less modern in others), but when considering both languages carefully, I find I really need a magnifying to tell the two apart. If Go had offered everything that Java does, I still wouldn't have had a compelling reason to switch because the differences are just too small.
But Go doesn't offer everything Java does. Like you said, Java's ecosystem dwarfs Go's. Java has dynamic linking, runtime code instrumentation, unparalleled tooling, and better performance than Go. The only advantage I see Go has over Java is a shorter startup time, which makes it a reasonable choice for writing command-line programs. As for concurrency constructs, Java is far more flexible than Go, and because goroutines and channels are easy, I've ported them to Java[1] (and Clojure).
Go sure is easy to get started with, but it would have to be 20 times better than it is to make me give up the JVM. In reality, it's just a recent, beginner-friendly Java without the awesomeness of the JVM.
(P.S. I'm not sure Java's often mocked factory-factories aren't simply a result of the huge number of multi-million LOC programs that have been written in Java. It's just experience, and Go sure doesn't have the necessary abstractions to make engineering large systems any easier. Other recent languages -- sure -- but not Go)
My too, that is what made me stop playing with Go and look forward to D and Rust.
Initially Go attracted me, mainly because of the Oberon-2 influences (method declarations) and being compiled by default to native code. Java and .NET have AOT compilers, but don't tend to be used that much.
I even tried to do some initial contributions before the 1.0 release, but with time I got a Java 1.0 feeling. The language just throws too much away in the days that the enterprise is adopting Scala, Clojure, F# into their ecosystems.
I wish all the best to Go developers, but personally I don't think the language would be all the time here, if it wasn't being done at Google.
I mean, how often was Limbo discussed here, if ever?
Yes. Rust is an entirely different beast. A truly modern C-level language is something to look for.
There's no doubt Go wouldn't have been discussed here if it hadn't been done at Google. It's a really nice language, and the tooling is nice as well (far better than other new non-corporate-sponsored languages), but it doesn't address a need like Rust, or offer a way to tackle the hardest modern software development problems like Erlang or Clojure. As a language, it's not interesting either (say, like Haskell). It's not even a modern Java (like Kotlin). It's just Java. (only severely handicapped but made a little friendlier)
Then again, all this might not matter. Go is well executed, it's easier for Python devs to adopt than Java, and it's made at Google. And Google is known for making popular Java flavors, so, if Go's particular (few) strengths appeal to some -- why the hell not? There are smart people behind it, and I'm sure we can learn from Go, too.
I don't think it's fair to say that Go doesn't address a need. I volunteer on the Rust project, and compilation time of the compiler itself is one of the biggest problems at the moment. Take a look at at the turnaround times on our automated testing bots:
That's 24 minutes spent compiling each and every pull request! Granted, this is triply exacerbated by the fact that as a self-hosted compiler we have to compile three times, but I'd kill for sub-minute turnaround times for even a single stage (on a beefy dev machine we're down to maybe four minutes per stage, so 12 minutes total). We're putting a lot of focus on reducing this burden for our next release, but that's still time that could have been spent on features.
As I understand it, Go is intended to address this need for systems at Google's scale, where compilation presents enormous time overhead. I'm not a Go user so I can't comment on how well it achieves this, but one way or the other I think it's a really fascinating thing to optimize a language for.
Rust suffers from having to compile LLVM as build dependency.
This will surely improve when Rust no longer requires it.
Go compile times are sweet, true. But Modula-2 and Pascal dialect compilers were already achieving similar compile speeds in 16 bit compilers a few decades ago.
Young developers get impressed by Go compilation times because they never experienced those systems.
Those compile times don't include building LLVM, which, on the rare occasion that a recompile is necessary, will add about five minutes on a beefy desktop and about an hour on our buildbots.
Sure, Go compiles a lot faster than C++, but unlike Rust, Go doesn't operate at the same level as C++, but at the same level as Java. How much faster does Go compile than Java?
I'm pretty sure the compilation time is less to do with the "level" that it operates. From presentations on the topic, most of the time savings were by making the syntax completely unambiguous. Apparently, in C/C++ and similar, some of the longest parts of the compilation process are lexing/parsing/AST-building, etc
Go sure is easy to get started with, but it would have to be 20 times better than it is to make me give up the JVM.
I like Rust because it gives you control (like C++) but does so carefully (unlike C++). In ten years, Go should be a great alternative to Java and Python. In ten years, Rust should be a solid alternative to C and C++. (That is, assuming they both succeed.)
A language like Rust, which is reasonably expressive and safe but fast and with little overhead, should become a very desirable language as hardware improvements become more marginal (adding more cores eventually brings diminishing returns), and as battery life becomes more important with mobile devices.
But the portability problem is solved really well by the JVM. I'm hoping Rust will make writing cross-platform, native code easier.
You mention Kilim (but perhaps not in a very good light)! Very cool.
To be honest, I was surprised what you could do with Kilim (and the awesome robustness of the system). Unfortunately, I don't think Kilim has been updated for ASM 4.0 -- your library looks interesting though, I will certainly take a look at it.
With cgo, Go can get "just as close" to the metal too. But I don't even think a cgo vs. JNI benchmark would be substantive. Most people don't use a "medium-"level programming language to write low-level code, anyway.
Like you say, Java is barely less verbose and arguably just as powerful as Go with many more times over the documentation and resources.
Oh, I would say Java is much, much more powerful than Go. Other than dynamic code loading and runtime instrumentation, even when it comes to concurrency you have your choice of schedulers and control over OS threads.
But Go doesn't offer everything Java does. Like you said, Java's ecosystem dwarfs Go's. Java has dynamic linking, runtime code instrumentation, unparalleled tooling, and better performance than Go. The only advantage I see Go has over Java is a shorter startup time, which makes it a reasonable choice for writing command-line programs. As for concurrency constructs, Java is far more flexible than Go, and because goroutines and channels are easy, I've ported them to Java[1] (and Clojure).
Go sure is easy to get started with, but it would have to be 20 times better than it is to make me give up the JVM. In reality, it's just a recent, beginner-friendly Java without the awesomeness of the JVM.
(P.S. I'm not sure Java's often mocked factory-factories aren't simply a result of the huge number of multi-million LOC programs that have been written in Java. It's just experience, and Go sure doesn't have the necessary abstractions to make engineering large systems any easier. Other recent languages -- sure -- but not Go)
[1] https://github.com/puniverse/quasar