[pron]

Sure. Go is pretty much a JVM-less Java. To me, it seems the exact wrong things to take from Java. Go takes the language (Go is a simplified Java, with some modern improvements) - which is only OK, but drops the JVM, which is awesome.

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).

[deong]

I think calling Go a simplified Java is pretty far off the mark. Aside from both aiming at the niche of being sort of "medium-level" languages, for lack of a better term, Go's approach seems very different from Java's.

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.

[pron]

Structs + interfaces in Go are a re-interpretation of Java interfaces (albeit a major one). It's a different path, but the same philosophy (dynamic dispatch over receiver type + mutable state).

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).

[deong]

I was mostly referring to the style of programming the languages encourage. Things like multiple return values instead of exceptions are extremely significant in what they imply about how you're intended to code in the languages.

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.

[wbl]

Not so! Go explicitly exposes indirection, while every Java object is a pointer. The result is that control of what is in L1 with Java is impossible, while memory locality can be forced in Go.

[pron]

Struct arrays are sorely missing from Java (hopefully they'll be included in Java 9), but other than that, an object is allocated contiguously in memory. In fact two objects allocated by the same thread one after another will be allocated contiguously, so "inner" objects allocated during objects construction will be adjacent to the original object.

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.