I don't have to change my workflow at all between working in Python, C, Go and JS. I can use vim for all of the above and none of them force me to have years of experience with an IDE in order to be productive.
It does have one advantage over the JVM, which is a much shorter startup time. But Java has better performance and far better monitoring tools (as well as dynamic linking and hot code swapping).
Objects vs structs and functions, exceptions vs multiple return values, required static vs required dynamic linking, implicit vs explicit subtyping/interfaces, etc.
Go is C with added convenience.
Exceptions vs. multiple return values are two different local decisions made by Go's designers: multiple return values and lack of exceptions. Multiple return values are handy (might find their way to Java one day), but I would call that a feature, not a different approach. As for exceptions, it is my understanding that Go's designers haven't made a final ruling on the subject.
Static vs. dynamic linking are properties of the runtime (native vs. VM) rather than the language. In principle, both Go and Java could support either without any language changes.
Go is most certainly not like C, because C's philosophy is letting the programmer work at the same level as the CPU. Go, if anything, is further removed from the hardware than Java (no explicit control over threads or scheduling, no access to memory fences).
Go's designers have said that they wanted to experiment with a more direct approach to memory in exchange for a less advanced GC.
So, you are right that in terms of memory placement issues, Go is more low-level than Java, but it's higher level when it concerns scheduling. All in all, it places them pretty much at the same level. It certainly doesn't make Go closer to C.
Go tends to be written like a low-level language with very good high-level libraries. You don't have huge class hierarchies; instead you have functions. You don't have a million custom exception types; you just return error codes. Go is obviously closer to Java with respect to some of the things you can do with those concepts (things like switch statements being very general are features of much higher level languages than C, etc.), but as a programmer, you're still writing a switch statement, not a series of polymorphic methods dispatched at runtime. That's what I mean -- Go is very, very unlike Java if you're writing idiomatic code in each.
First of all you have this on about every second line:
if err != nil {
return err
}
Go:
func (MyType* mt) myMethod(s string, i int) (string, error)
String myMethod(String s, int i)
You can't specify default values for structs, so you often need an extra function that constructs a default instance of the struct and initializes its fields.
And the lack of generics means you have to write a lot of things several times for different types.
Lambdas are very verbose as well. You get no type inference even in contexts where it would be simple to do:
Go:
filter(func(s string, n int) { return len(s) < n })
filter((s, n) -> s.length < n)
Go's simplicity is a double edged sword. Lack of verbosity is definitely not its strength.
Obviously there are many counter examples where Java is more verbose than Go. But they are very well known by now so I'm not going to repeat them here.