Thoughts on Google's new Go Programming Language

Google's been working on a new programming language called "Go". I went through the tutorial today and here are some hasty conclusions. I'll use Java as a contrast even though Go is more similar to C/C++ because you're likelier to be familiar with Java.

The Good:

1. Functions can return multiple values. In Java, you're often creating useless new data structures just so you can return multiple objects from a method. Don't have to do that in Go.
2. The concept of goroutines -- lightweight processes that communicate via a channel -- is quite awesome. They are easy to set up and you can feed one channel easily from another channel. You can even specify what types of objects the channel will receive. Presumably, serialization takes place under the covers.
3. Things are very terse and UNIX-like. A steeper learning curve, but improved productivity. That's usually a worthwhile trade-off.
4. There are lots of existing packages, so it's a full-fledged language already. And it's all open-source, so you have tons of examples to look at.
   
5. No exceptions. Exceptions in Java have lead to a lot of crud. Go is back to basics.
6. Interfaces in Go are really cool. If a method in Java asks for an interface as a parameter and you want to pass it a class, it's got to implement that interface. Which means you probably need access to the source of the class if it doesn't already implement the interface, even if you know the class has the methods that you need. Templatized methods in C++ are nice in that regard because you can pass in any class that has the necessary parameters. Interfaces in Go share the characteristics of both Java interfaces and C++ templates. They form a type hierarchy, but you can fit a class to an interface after the fact as well.
   
   

The Bad:

1. Namespaces in Go as just as ugly as in C++. Java conventions have you naming your namespaces something like org.wdssii.polarvil so that you don't mistakenly name your packages to something someone else is using. In Go, the package is the same name as the file, so you're totally dependent on your project organization. Pretty fragile.
   
2. There are way too many optional things in Go. Semicolons at the end of statements are optional, for example. Variables can be declared without actually specifying the type. This is just asking for trouble. It's better for a programming language to be simple and consistent. Java is very nice that way.
3. There are magic variables defined globally by packages. For example, to parse command-line arguments, main() doesn't give you any parameters. Instead, you've got to use the package "flag" which magically gives you a Arg variable.
   

The Ugly:

1. I see a line import "fmt" that seems to import strings. Really? Shouldn't you only import packages? Well turns out that you are importing a file at a particular location. Sort of like a #include. Java's import and classpath idiom is much nicer for moving code around.
   
2. Functions whose names are capitalized are exported. If a function's name starts with a lower-case, it's private. Yikes. Didn't we already try this with Fortran? Variables whose names start with i, j or k are integers? Else not. Why go through that type of mess again?
3. Every C-like language puts its return type before the method name. So what does Go do? It puts the return types after the method and its parameters. Why? Just to be cute?
4. The claim is that Go programs can call C -- important because so many scientific libraries are written in Fortran/C. But it depends on using a particular compiler (gccgo) . This really ought to be built into the language. Java's Native Interface is better that way.
   

The Bleh:

1. You define variables with a keyword "var". Functions with a keyword "func". They must have been looking at studies that say new programmers can't tell variables from functions and declarations from usage. So, they decided to be helpful. But it's ridiculous. Here's a language that tries to be all terse and everything and then they have this verbose crap?
2. The distinction between reference objects and value objects is quite clear. You create reference objects with "make" and value objects with "new". You can also pass around pointers to value objects and garbage collection is automatic. This would be quite neat except that the lack of type information means that many of the advantages of this are lost when you start passing these around. People using the classes will have to just know whether they are dealing with a reference type or a value type. C++ is nicer here. The user chooses whether it's a reference type or a value type, not the creator of a class.
3. The big selling point of "Go" seems to be how fast it compiles. What I really want to know how fast it runs. No real numbers on that.
4. There is no pointer arithmetic, so Go doesn't need to support ++x. You only get x++.