Standardizing Go

The web is abuzz with the recent announcement of the Go Programming Language. I've put a decent bit of thought into similar issues over the years, so I thought I'd chime in on the discussion.

To start with, Go is targeting a niche which I think has been need of filling for a long time. The Go home page bills it as "a systems programming language", but I don't think that name completely reflects the niche's whole scope. My interest in this niche came from writing programs to play games like chess and other zero-sum board games. At the bleeding edge of chess programming, developers always want to milk the limits of optimization to boost their search speed. This inexorably leads to the desire to write critical code in assembly language, and has generally led to these programs being written in C or C++. You don't usually think of chess programs as "systems programs", so instead of using the name "systems" to describe this niche, I'll use the term "performance-oriented".

Performance-oriented languages are used in a large number of domains such as artificial intelligence (specifically game tree search as mentioned above), mainstream game programming (3D graphics), OS/infrastructure development, and anyone who has decided (prematurely or not) to that low-level optimization is important. So Go's niche is large and important. (As a side note, my personal preference has recently begun to shift towards languages like Haskell that give you more powerful abstractions in exchange for hiding the underlying von Neumann architecture, but I recognize that performance-oriented languages still have an important place in software development.)

The main problem with C and C++ as the canonical performance-oriented languages is that time and technological advancement have rendered them too onerous for programmers. There's much debate about precisely which characteristics are the problem, but whatever your particular favorite issue, it's hard to argue that writing good, efficient, portable C code is quite tedious. I haven't yet looked at the actual language specification, but so far it looks like Go's feature set nicely addresses the most prominent of these problems. And it's about time.

But there are some problems with the ecosystem surrounding C/C++ that contributed to the problems. First, there is the lack of a good set of standard C libraries. Good, standard libraries could have solved some of C's problems by providing de facto solutions. Languages like PHP and Java did an outstanding job of solving this issue. Go needs something similar. With the inclusion of higher-level concepts like maps as a part of the language, Go has reduced the damage that can be done by the lack of standard libraries, but this will still be an important requirement if Go is to succeed.

C's second major problem was the lack of a controlling body. This is related to the first problem because libraries that could have become good standards suffered from non-portability across different C compilers. The profusion of subtly incompatible C compilers made it very difficult to write portable C code. Here too Java provided a great solution. I think the fact that Sun was able to legally prevent Microsoft from creating their own bastardized Java implementation was crucial in allowing Java to maintain its portability. Microsoft went on to create something similar called .NET that did essentially the same thing as Java (for them). But it did not destroy Java's unity in the process. My conclusion from this is that names, and the ability for the controlling organization to legally enforce them, are important. So in some ways being closed is good.

But if you're going to have a controlling organization, it is also important that the community be able to trust them. I think Sun did a decent job in how they managed this with Java. They provided a good quality, reasonably open, reference implementation for free. But they also kept control of the brand name to ensure compatibility. Google seems like it would be a decent owning organization for Go, although I know plenty of people would probably disagree. If Google owns the trademark for Go, they should be able to open source their implementation while still enforcing standards on anyone wanting to release a Go compiler. I would feel safe enough to use the language for commercial code if I know that the implementation is open source and there is no chance of Google making the Go implementation proprietary in the future. I think ownership and enforcement of the Go trademark is orthogonal to this issue.

Now, it could be that trademark ownership and enforcement is no longer a critical issue, and that Go can do just fine without it. However, I don't think it will hurt anything to have a the legal backing of an enforceable trademark to aid in standardization.

In conclusion, the Go Programming Language looks like a great step in the right direction. The next time I'm writing a new performance-oriented application, I'll be very likely to use Go. I hope the people developing Go have given these less technical issues some thought and that we can finally have a better standard for modern performance-oriented programming.

Edit: The original post used the term "bare-metal" instead of "performance-oriented". This was a bad choice of words and caused a lot of confusion. For whatever reason, when I hear the term "systems software" I think of operating systems, filesystems, device drivers, etc. I don't tend to include things like 3D games, chess engines, or computational fluid dynamics simulations in the meaning of "systems software" because I perceive these to be applications that run on top of the systems software layer. So I tried to define the term "bare-metal" to refer to all of these. But alas, it was a horrible choice of terminology--it gave some people exactly the opposite picture from what I intended. So I changed "bare-metal" to "performance-oriented". Hopefully this makes more sense.

Edit 2: Original article include a Microsoft slam that wasn't relevant and detracted from my point, so I removed it.