[Styck]

This is one of the reasons I use Go in favour of pretty much anything running on the JVM stack.

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.

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

[fauigerzigerk]

I'm learning Go right now by writing a small part of my current project in it. I like it quite a lot (mostly for its concurrency features) but it is actually a surprisingly verbose language compared to Java.

First of all you have this on about every second line:

  if err != nil {
    return err
  }

Method signatures are convoluted because you have to repeat the receiver type for every single method and add (actualReturnType, error) at the end.

Go:

  func (MyType* mt) myMethod(s string, i int) (string, error)

Java:

  String myMethod(String s, int i)

For functions you want to use in expressions you need a second one that calls the first one and panics instead of returning err.

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

Java 8 (Scala is similar):

  filter((s, n) -> s.length < n)

Function names often have to be longer because there is no function overloading.

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.

[lrobb]

You can do that with Scala as well. (or groovy or clojure...)