Wednesday, November 11, 2009

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.

5 comments:

Anonymous said...

A garbage-collected language is not "bare-metal", definitely not at the "bleeding edge" of performance. You haven't used it, seem to know little about it or the implications of its various features, yet say "the next time I'm writing a new bare-metal application, I'll be very likely to use Go." On what basis?

From a PLT perspective Go isn't that interesting. The concurrency and "goroutines" look promising for possibly being able to do what Erlang does. The type system is pretty weak.
From a practical perspective people are singing praise for how fast it compiles, but not much mention so far of how fast the resulting code is. Compare tinycc vs gcc for speed of compilation vs resulting code performace to see why I'm skeptical.

It's not bad, it's got some interesting features, the fast compilation and focus on concurrency is cool, but bare-metal? C'mon. It seems people are blindly singing it praises just because it comes from Google. I'd like you to go and try this "bare-metal" programming you speak of and see how this language fares, and *then* sing it praises if it's actually worthy of them.

Anonymous said...

In the world full of extended Cs (C++, C--, ObjectiveC, D, C#, Java, Vala...), yet another non-standard C from Google looks bleak. No type inference. Pointers and nil. Immutable strings. Untyped variables and iota. Ugly syntax. := and = seem to do the same thing. Confusing name.

Cool things and hacks: defer, coroutines (not a big deal) and channels. Is it an Erlang replacement with curly braces?

mightybyte said...

Anonymous 1,

First, I edited the post to use the phrase "performance-oriented" instead of "bare-metal".

Second, I didn't discuss the implications of language features and the basis for wanting to use Go because that wasn't the scope of my post. I wanted to briefly discuss the niche that I think Go targets as well as mention the "ecosystem" issues that I think are needed to rectify some of the problems with the C/C++ language family.

Jason said...

Good article but your dated MS bigotry is detracting from the overall quality of your post.

A quote from billg 11 years ago doesn't really add credence to your claim that MS can't be trusted to make standards-compliant programming languages.

You do know that C# is governed by ECMA, right? A lot can change in 11 years.

And while you haven't been following it, .Net has come to the XBox 360 (so 3D is more than there), along with F#, which is a much stronger functional language than Go will ever be.

mightybyte said...

Jason,

You make a good point. I guess I have to admit that the same legal tools that could be used by Google to convince me of Go's openness could just as easily be used by Microsoft. But while they may be embracing standards groups I still am not aware that they have been very open with respect to implementations. Having an open language standard doesn't do any good if the only robust, compatible implementation is closed.

In terms of innovative language features Microsoft is doing very well these days. C# (bolstered by F#) has clearly surpassed Java on the functional front. The main reason I stay away from Microsoft is because I prefer free tools.

The existence of .NET on the XBox doesn't change my point about Go. There are a class of applications for which some people don't feel .NET is fast (or low-level) enough. This is what I mean by "performance-oriented". I'm saying that Go looks like a nice improvement on the status quo for this niche. I'm not trying to argue where this niche begins and ends.

The truth is that in this argument I'd probably be standing right beside you arguing for modern languages with better abstraction power like Haskell, F#, Scala, and Clojure. But I'll save that for another day.