Early this week a group from Google released a new programming language called ‘Go’. It’s supposedly a uber version of C – a systems language that has a lot of cool features like garbage collection and concurrent programming. Being a language buff I decided to check it out.
The first interesting thing about Go is the authors. Two guys on the team, Rob Pike and Ken Thompson, are legends in software engineering. They are the kind of guys that can write complete operating systems from scratch. When guys like this develop a programming language, it’s hard not to pay attention.
If you watch Rob Pike’s technical presentation of Go, he emphasizes that it’s designed with speed and concurrency in mind. He notes that there hasn’t been much change in system languages for the past decade or so, and since then computing requirements are vastly different.
So I wrote my first Go program, eightqueens.go, which (surprisingly) solves the eight queens problem.
It was relatively painless to write, but I’d have the following suggestions for the go team.
The environment variables for building go are weird. $GOROOT points to the source, and why do you actually need to set $GOARCH and $GOOS? It’s easy to detect that.
Go uses a custom, funky build system. Most linux programs are compiled through autoconf and make. The build system has quirks, like if the $GOBIN directory isn’t added to your path, it won’t install.
The build script automatically installs go. But you have to create the installation directory manually.
The binary naming scheme is weird. For i386 you have the following program names:
If you have a different architecture, these binaries will be named differently (6a, 6g, 6l, 6c for amd64). I couldn’t find out why they use this seemingly arbitrary naming convention.
Compiling and running a go program takes three steps (it would be nice if it
was just one):
Sometimes semicolons are needed, and sometimes they’re not. Other languages seem to get around the need to use semicolons (i.e ruby and python).
The languages require braces for most control expressions, even if they only contain one inner expression.
There isn’t an exception mechanism
Ambiguous assignment. The following are identical:
A compilation error happens when a variable is declared and not used. I’m not a huge fan of this.
Weird debug statements. This happened when I had an out-of-bounds error.
HelloSIGTRAP: trace trap
Faulting address: 0x0
PC=0x804886a
main·initBoard+0x6a /home/Mike/workspace/gotest/eightqueens.go:10
main·initBoard()
main·main+0x56 /home/Mike/workspace/gotest/eightqueens.go:17
main·main()
mainstart+0xf /home/Mike/workspace/go/src/pkg/runtime/386/asm.s:81
mainstart()
goexit /home/Mike/workspace/go/src/pkg/runtime/proc.c:135
goexit()
eax 0x878fe000000008
ebx 0x878fe00809e1dc
ecx 0x878fe000000000
edx 0x878fe000000005
edi 0x878fe000878fc4
esi 0x878fe000878f9c
ebp 0x878fe000000008
esp 0x878fe000878f90
eip 0x878fe00804886a
eflags 0x878fe000200246
cs 0x878fe000000073
fs 0x878fe000000000
gs 0x878fe00000003f
Trace/breakpoint trapOverall I think go will find a good niche - a high performance language that’s suitable for most system tasks. It has a great initial library, and it seems to have attracted a large community already(the irc chat room currently has over 500 users). I’m definitely planning to use it for some some simple projects. Looking forward to seeing how go evolves :)