From r60 to Go 1

Go 1 is right on the doorstep, and, boy, are there a lot of changes!

Here are the big things you need to know about:

The Go command

Go has a new master command, go, which replaces or complements all of the old go commands:

Before Now
godoc go doc
gofix go fix
gofmt -l -w *.go go fmt
goinstall go get
gorun go run
gotest go test
govet go vet
make go build
make clean go clean
make install go install

(Most of the utility commands, including 6g/8g, 6l/8l, 6cov/8cov, gotype, gopprof, and 6prof/8prof are now under go tool <6g/pack/prof/...>. See go tool for a full list.)

Goodbye Makefiles

Go 1 has done away with Makefiles, which were always a temporary solution anyway. Instead, everything—how to get a package, how to compile it, and how to test it—is deduced by looking at the source files, and from a single environment variable, GOPATH.

For Go 1 to be able to build any package, that package must reside in a path listed in GOPATH. (If GOPATH is not set, go uses its own directory.)

  • All compiled binaries are stored in GOPATH/bin
  • All compiled packages are stored in GOPATH/pkg/<arch>/<import path>
  • All source code is stored in GOPATH/src/<import path>

This means that if you have a package, the source files should be stored in one of the directories listed in GOPATH under src/ When you run go install, the compiled package appears in that same GOPATH folder under pkg/<arch>/

Because of these new conventions, GOPATH is all of the configuration Go needs. No Makefiles, no custom scripts, and no worrying about naming conflicts.

Here’s an example you could use to be able to build and run all of your own projects, while at the same time avoiding cluttering your projects folder with external source code (e.g. from using go get):

In ~/.profile:

export GOPATH=$goroot:$mygo
export PATH=$PATH:$gobin

Because the Go folder is the first path listed in GOPATH, this is the default destination used by commands like go get—but since your projects already reside in the second folder, its bin and pkg folders are used to store your compiled projects.

(If you don’t have write access to the Go folder, you can just specify another folder to use as the default instead of goroot. go get will install all new third-party packages there.)

(When you build a project that imports a package, e.g., Go looks for it in all of the paths listed in GOPATH.)

To understand the thinking behind this, see Russ Cox’s message to the golang-nuts mailing list titled The Go Command.

New map delete syntax

You now use delete(map, "key") instead of map["key"] = nil, false.

Errors have their own package

Errors have moved from os to errors. Also, error is now a built-in type, so you don’t have to import anything to be able to work with it.

Before Now
os.Error error
os.NewError(text string) os.Error errors.New(text string) error
err.String() string err.Error() string

Library reorganization

See this table for a list of old and new package import paths. (All of them are fixed automatically by go fix.)

Rewritten libraries

Package Change
strconv Significantly reworked
template Replaced by text/template which has an entirely new API
time Completely redesigned
url Moved to net/url with several changes, most significantly to url.URL where URL.Raw has been removed and URL.String() should be used instead

New libraries

Package Description
database/sql A standardized interface for interacting with relational databases (drivers exist for SQLite, MySQL, PostgreSQL, and more)
html/template An XSS-safe wrapper for text/template

xdThis is by no means a comprehensive list of the changes introduced to the language and the package library in Go 1. Please see the Go 1 release notes (work in progress) and the weekly snapshot history for more details.