The only other two languages that offer something comparable to this and have enough of an established following that I might bother to learn them are Erlang and Scala (I don’t pay much attention to the Microsoft camp of F# et al languages.) Erlang, despite CouchDB having been written it it, is rather too odd. Scala I started getting into and then got bogged down in the functional programming side of that language. Overall it’s a rather complex language with a lot of turf to cover.

Then when I came across Go – well, it was a much simpler language to learn. Having programmed a good deal in C in bygone years, there was a lot about Go that had a sort of C sensibility about it.

It is a very young language, though. The one area that grates the most (coming from a Java background) is the lack of exception handling constructs. There is no way to catch and handle exceptions like dereferencing a nil pointer, divide by zero, array index violation.

So it is not possible to write an app server in a Java-like manner where all code runs in a single process (including loaded beans). Instead, one would need to rely on the POSIX fork() system call to launch any worker code as a child process and have the parent process monitor it in watch dog fashion. If any child processes panic fault then the parent process would detect and restart the process.

So far Go only supports unix/linux/Mac-OS-X OS where fork is natively supported. Windows API doesn’t expose fork() but it is available on the Windows POSIX dll. Hence Go will probably be better suited implemented on top of one of the various Windows POSIX runtimes.

a language that compiles and links far faster than C or C++

Yes, Go does this. The benefit, however, is questionable. Is it more valuable to get a car off the assembly line 50% faster if it’s still slower than the one I waited longer for?

You really do make too much of the syntax issue by far, BTW. Adobe ActionScript3, which is used in Flex programming, has the same declaration style as Go.

My experience with teaching students from C to C++ (1995-1997) and C++ to Java (1998-2005) shows about 25% will struggle and reject the language on this basis alone. And that’s with a language that is already very similar in syntax. Forward declarations are but one aspect of Go’s different approach, and perhaps the most benign.

I don’t think your language example underscores the significance of the syntax between the two. ActionScript’s heritage is much closer to Java than Go’s is to C++. Compare these two blocks of code:

SexprParserRef := MakeRef();
ManySexprs := Action(Many(SexprParserRef, 1), new(VectAction));
ListParser := Second(Seq([]Parser { Lp, ManySexprs, Rp }));
Sexpr := Alt([]Parser{ ListParser, SymParser });
SexprParserRef.SetTarget(Sexpr);

To this one:
void main()
{ int i;
char *inp;
clrscr();
printf("enter the regular expression :");
gets(inp);
nfa(1,0,inp);
printf("\nstate input state\n");
for(i=0;i %d\n",ret[i],ret[i+1],ret[i+2]);
printf("\n");
getch();
}

As far as the goroutines go, you said:

You still need to know what you’re doing…

Which simply reiterates the point I made about the dangers of concurrent programming with Java. You still get free reign to do dumb things, like addressing local variables, because the Go language doesn’t preemptively stop you from shooting yourself, nor does it educate you why not to. If the purpose of moving away from C++ to Go is to get safety, this is a poor move. I’d love to see numbers on the goroutines you mention–an actual code example that fires those up and doesn’t bring the OS down. No one has addressed that to date.

And finally, I think you make a very compelling point: Go probably was created as a special-purpose language to run Google’s own server farms. But that is a far cry from a general purpose systems programming language, which is the argument I made above.

Secondly, the goroutines and channels will let them write concurrent/parallel software that will tend to be more correct than such software written with threads. Sure, you can pass an object pointer over a channel to another goroutine. But if one goroutine sets up the object on behalf of the next stage of processing (tiered execution pipelines), then it’s no big deal. The next tier will have exclusive use of what they’re handed over the pipeline. Yeah, you have to be more aware of what you’re doing – but it’s still preferable than trying to rendezvous on shared memory via locks. And you can always choose to send copies of data instead of pointers to data.

Another advantage of goroutines is that you can have massive numbers of them. This is something you failed completely to discuss. Your only distinction of messaging vs Java threads was the locking of shared memory of the latter. Yet goroutines are designed to be used in a single process to the order of tens of thousands. Threads of languages like Java, C#, or Scala are based on underlying native OS threads. An OS these days can have hundreds, and even a few thousand threads, but eventually performance and resource consumption causes performance to drop off precipitously. Forms of concurrency that rely on fewer OS native threads can scale much better. This is where Go looks to triumph as Google has an example program that starts 100,000 goroutines in a single process and harvest a value from each one. That much concurrency activity (within a single process) would be tough to do in other languages other than Erlang.

You really do make too much of the syntax issue by far, BTW. Adobe ActionScript3, which is used in Flex programming, has the same declaration style as Go – variable name followed by type (as does Pascal and PL/SQL). Java programmers that take up ActionScript3 programming (and gobs of them have become Flex developers in last 2 or 3 years) just about never voice this an issue.

Also, in Go, 90% of the time you just declare variable name and ‘:=’ assignment operator, which does type inference, like so:

parts := Split(“bob,jane,fred,sally”,”,”,0)

instead of:

var parts []string = Split(“bob,jane,fred,sally”,”,”,0)

and then something like:

for part := range parts {
fmt.Println(part)
}

instead of:

for var part string = range parts {…

IOW, the syntax of Go is actually very convenient, very, very easy to learn, and just not a big deal at all as you make it out to be. Tons of Java/Flex developers in enterprise development demonstrate the fact of just how utterly trivial the matter is.

Because you’re so far off on this syntax matter, and yet put a big deal of emphasis on it, it is cause to more deeply question your other analysis points. And so indeed, the fact you so missed the distinction of goroutine concurrency/parallelism relative to threading based on one-to-one native OS threads of other languages is yet another such question mark of your overall critique.

Okay, I’ve got some Go code executing 6 times slower than comparable C++ code, yet my C++ process can fire up a maybe a few thousands threads, but then brings the OS to a standstill. My Go program, in contrast, cheerfully fires up tens of thousands of goroutines. Think of the context of what Google does on those back-end data center servers. Which is truly being the most performant language in terms of solving the problem?

I really think your concluding remark to this piece is therefore flippant without having earned the right to be so. Some of your points were just too weak.