Being in a programming language design course (and being the sort of person who would play with it even if I weren’t) google’s new programming language, Go, is pretty intriguing. A few of the things I notice:
* There are some pretty significant people behind it. Ken Thompson (one of the great old bearded ones) lends a lot of credence to anything he touches, and Robert Griesemer and Rob Pike both have pretty distinguished records of their own.
* Really? “Go”? There is already a (very low profile) language “Go!” which is causing a bit of a stink (the suggestion of renaming Go “Issue 9” is really clever, particularly in light of the people involved; I’d support it). There is also the problem that “Go” is essentally impossible to google for, and “Go Programming Language” has the acronym “GPL” which is already pretty well populated in the computer context. Also, the game Go has Go taken in computational circles. Too many conflicts to be a good idea.
* SLICES! — OMG YES SLICES! Slices are one of those features that I miss whenever I am writing in a language that doesn’t support them. There aren’t many software languages with slice support, but Verilog and some of the other HDLs have them and they are wonderful. The implementation (slices are associated with an array which contains the values, and merely provide bounds) isn’t bad, and the “create a hidden array for a slice not associated array” feature isn’t too heinous, although perhaps it would be cognitively cleaner to restrict slices to existing arrays, or make them genuinely first class.
* Baked-in concurrency goodness. They don’t seem to be quite done with this (FAQ even says so), but having language primitives for concurrency and well-defined concurrency/atomicity behavior over the whole language is becoming really, really desirable with the advent of many-core, many-thread machines and quality generic software tools to automagically parallelize serial code looking rather unlikely (but very cool). I’ve noted that proper concurrency models are something to appreciate before, and will probably do so again.
* I’m not entirely clear on what kind of usage they are envisioning for Go. It isn’t really suitable for the OS people; it has no pointers, no explicit memory management, no existing OS with appropriate hooks to use it on… (that said a Plan9-like OS, written as much as possible in Go would be rad). The applications and web people have moved on to ;decadent languages with unbelievably gigantic standard libraries (<rant> and given up any pretense of programming for the computer that will be running the code over and over and over, it’s all about the developers who write it once and maintain it…</rant>). One environment where it would be very nice is old-style low-UI applications and services (ie. once the bindings are in place it would be nice for *nix daemons). Having spent a fair amount of time poking around inside of compilers it would be quite well suited for compiler development as well; I bet we’ll see a bootstrap compiler in a matter of months.
* I’m feeling some of the same vibe as D (which I briefly fiddled with some time ago) coming off of Go, but Go seems MUCH cleaner. D holds on to most of the ugly in C++ (which I’ve never met anyone who refutes is an ugly language, even Bjarne Stroustrup is on board with that assertion), while Go is creating a clean start, and not including all kinds of decadent features.
