go.blog: add content
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/7436052
diff --git a/content/building-stathat-with-go.article b/content/building-stathat-with-go.article
new file mode 100644
index 0000000..9f47ae0
--- /dev/null
+++ b/content/building-stathat-with-go.article
@@ -0,0 +1,112 @@
+Building StatHat with Go
+19 Dec 2011
+Tags: guest, rpc
+
+Patrick Crosby
+
+* Introduction
+
+My name is Patrick Crosby and I'm the founder of a company called Numerotron. We recently released [[http://www.stathat.com][StatHat]]. This post is about why we chose to develop StatHat in [[http://golang.org][Go]], including details about how we are using Go.
+
+[[http://www.stathat.com][StatHat]] is a tool to track statistics and events in your code. Everyone from HTML designers to backend engineers can use StatHat easily, as it supports sending stats from HTML, JavaScript, Go, and twelve other languages.
+
+You send your numbers to StatHat; it generates beautiful, fully-embeddable graphs of your data. StatHat will alert you when specified triggers occur, send you daily email reports, and much more. So instead of spending time writing tracking or reporting tools for your application, you can concentrate on the code. While you do the real work, StatHat remains intensely vigilant, like an eagle in its mountaintop nest, or a babysitter on meth.
+
+Here's an example of a StatHat graph of the temperature in NYC, Chicago, and San Francisco:
+
+[[http://3.bp.blogspot.com/-tjeZA4l2b9k/Tuld_bk2MWI/AAAAAAAAAEs/gXHOPRUutuA/s1600/weather.png][.image building-stathat-with-go_weather.png
+]]
+
+(click to enlarge)
+
+* Architecture Overview
+
+StatHat consists of two main services: incoming statistic/event API calls and the web application for viewing and analyzing stats. We wanted to keep these as separate as possible to isolate the data collection from the data interaction. We did this for many reasons, but one major reason is that we anticipate handling a ton of automated incoming API HTTP requests and would thus have different optimization strategies for the API service than a web application interacting with humans.
+
+.image building-stathat-with-go_stathat_architecture.png
+
+The web application service is multi-tiered. The web server processes all requests and sends them to an interactor layer. For simple tasks, the interactor will handle generating any necessary data. For complex tasks, the interactor relies on multiple application servers to handle tasks like generating graphs or analyzing data sets. After the interactor is finished, the web server sends the result to a presenter. The presenter responds to the HTTP request with either HTML or JSON. We can horizontally scale the web, API, application servers, and databases as the demand for services grows and changes over time. There is no single point of failure as each application server has multiple copies running. The interactor layer allows us to have different interfaces to the system: http, command line, automated tests, mobile API. StatHat uses MySQL for data storage.
+
+* Choosing Go
+
+When we designed StatHat, we had the following check list for our development tools:
+
+- same programming language for backend and frontend systems
+
+- good, fast HTML templating system
+
+- fast start-up, recompilation, testing for lots of tinkering
+
+- lots of connections on one machine
+
+- language tools for handling application-level concurrency
+
+- good performance
+
+- robust RPC layer to talk between tiers
+
+- lots of libraries
+
+- open source
+
+We evaluated many popular and not-so-popular web technologies and ended up choosing to develop it in Go.
+
+When Go was released in November 2009, I immediately installed it and loved the fast compilation times, goroutines, channels, garbage collection, and all the packages that were available. I was especially pleased with how few lines of code my applications were using. I soon experimented with making a web app called [[http://langalot.com/][Langalot]] that concurrently searched through five foreign language dictionaries as you typed in a query. It was blazingly fast. I put it online and it's been running since February, 2010.
+
+The following sections detail how Go meets StatHat's requirements and our experience using Go to solve our problems.
+
+* Runtime
+
+We use the standard Go [[http://golang.org/pkg/http/][http package]] for our API and web app servers. All requests first go through Nginx and any non-file requests are proxied to the Go-powered http servers. The backend servers are all written in Go and use the [[http://golang.org/pkg/rpc/][rpc package]] to communicate with the frontend.
+
+* Templating
+
+We built a template system using the standard [[http://golang.org/pkg/template/][template package]]. Our system adds layouts, some common formatting functions, and the ability to recompile templates on-the-fly during development. We are very pleased with the performance and functionality of the Go templates.
+
+* Tinkering
+
+In a previous job, I worked on a video game called Throne of Darkness that was written in C++. We had a few header files that, when modified, required a full rebuild of the entire system, 20-30 minutes long. If anyone ever changed `Character.h`, he would be subject to the wrath of every other programmer. Besides this suffering, it also slowed down development time significantly.
+
+Since then, I've always tried to choose technologies that allowed fast, frequent tinkering. With Go, compilation time is a non-issue. We can recompile the entire system in seconds, not minutes. The development web server starts instantly, tests complete in a few seconds. As mentioned previously, templates are recompiled as they change. The result is that the StatHat system is very easy to work with, and the compiler is not a bottleneck.
+
+* RPC
+
+Since StatHat is a multi-tiered system, we wanted an RPC layer so that all communication was standard. With Go, we are using the [[http://golang.org/pkg/rpc/][rpc package]] and the [[http://golang.org/pkg/gob/][gob package]] for encoding Go objects. In Go, the RPC server just takes any Go object and registers its exported methods. There is no need for an intermediary interface description language. We've found it very easy to use and many of our core application servers are under 300 lines of code.
+
+* Libraries
+
+We don't want to spend time rewriting libraries for things like SSL, database drivers, JSON/XML parsers. Although Go is a young language, it has a lot of system packages and a growing number of user-contributed packages. With only a few exceptions, we have found Go packages for everything we have needed.
+
+* Open source
+
+In our experience, it has been invaluable to work with open source tools. If something is going awry, it is immensely helpful to be able to examine the source through every layer and not have any black boxes. Having the code for the language, web server, packages, and tools allows us to understand how every piece of the system works. Everything in Go is open source. In the Go codebase, we frequently read the tests as they often give great examples of how to use packages and language features.
+
+* Performance
+
+People rely on StatHat for up to the minute analysis of their data and we need the system to be as responsive as possible. In our tests, Go's performance blew away most of the competition. We tested it against Rails, Sinatra, OpenResty, and Node. StatHat has always monitored itself by tracking all kinds of performance metrics about requests, the duration of certain tasks, the amount of memory in use. Because of this, we were able to easily evaluate different technologies. We've also taken advantage of the benchmark performance testing features of the Go testing package.
+
+* Application-Level Concurrency
+
+In a former life, I was the CTO at OkCupid. My experience there using OKWS taught me the importance of async programming, especially when it comes to dynamic web applications. There is no reason you should ever do something like this synchronously: load a user from the database, then find their stats, then find their alerts. These should all be done concurrently, yet surprisingly, many popular frameworks have no async support. Go supports this at the language level without any callback spaghetti. StatHat uses goroutines extensively to run multiple functions concurrently and channels for sharing data between goroutines.
+
+* Hosting and Deployment
+
+StatHat runs on Amazon's EC2 servers. Our servers are divided into several types:
+
+- API
+
+- Web
+
+- Application servers
+
+- Database
+
+There are at least two of each type of server, and they are in different zones for high availability. Adding a new server to the mix takes just a couple of minutes.
+
+To deploy, we first build the entire system into a time-stamped directory. Our packaging script builds the Go applications, compresses the CSS and JS files, and copies all the scripts and configuration files. This directory is then distributed to all the servers, so they all have an identical distribution. A script on each server queries its EC2 tags and determines what it is responsible for running and starts/stops/restarts any services. We frequently only deploy to a subset of the servers.
+
+* More
+
+For more information on StatHat, please visit [[http://www.stathat.com][stathat.com]]. We are releasing some of the Go code we've written. Go to [[http://www.stathat.com/src][www.stathat.com/src]] for all of the open source StatHat projects.
+
+To learn more about Go, visit [[http://golang.org/][golang.org]].
diff --git a/content/building-stathat-with-go_stathat_architecture.png b/content/building-stathat-with-go_stathat_architecture.png
new file mode 100644
index 0000000..d07adc7
--- /dev/null
+++ b/content/building-stathat-with-go_stathat_architecture.png
Binary files differ
diff --git a/content/building-stathat-with-go_weather.png b/content/building-stathat-with-go_weather.png
new file mode 100644
index 0000000..f03f16a
--- /dev/null
+++ b/content/building-stathat-with-go_weather.png
Binary files differ
diff --git a/content/c-go-cgo.article b/content/c-go-cgo.article
new file mode 100644
index 0000000..7f2b976
--- /dev/null
+++ b/content/c-go-cgo.article
@@ -0,0 +1,109 @@
+C? Go? Cgo!
+17 Mar 2011
+Tags: cgo
+
+Andrew Gerrand
+
+* Introduction
+
+Cgo lets Go packages call C code. Given a Go source file written with some special features, cgo outputs Go and C files that can be combined into a single Go package.
+
+To lead with an example, here's a Go package that provides two functions - `Random` and `Seed` - that wrap C's `random` and `srandom` functions.
+
+ package rand
+
+ /*
+ #include <stdlib.h>
+ */
+ import "C"
+
+ func Random() int {
+ return int(C.random())
+ }
+
+ func Seed(i int) {
+ C.srandom(C.uint(i))
+ }
+
+Let's look at what's happening here, starting with the import statement.
+
+The `rand` package imports `"C"`, but you'll find there's no such package in the standard Go library. That's because `C` is a "pseudo-package", a special name interpreted by cgo as a reference to C's name space.
+
+The `rand` package contains four references to the `C` package: the calls to `C.random` and `C.srandom`, the conversion `C.uint(i)`, and the `import` statement.
+
+The `Random` function calls the standard C library's `random` function and returns the result. In C, `random` returns a value of the C type `long`, which cgo represents as the type `C.long`. It must be converted to a Go type before it can be used by Go code outside this package, using an ordinary Go type conversion:
+
+ func Random() int {
+ return int(C.random())
+ }
+
+Here's an equivalent function that uses a temporary variable to illustrate the type conversion more explicitly:
+
+ func Random() int {
+ var r C.long = C.random()
+ return int(r)
+ }
+
+The `Seed` function does the reverse, in a way. It takes a regular Go `int`, converts it to the C `unsigned`int` type, and passes it to the C function `srandom`.
+
+ func Seed(i int) {
+ C.srandom(C.uint(i))
+ }
+
+Note that cgo knows the `unsigned`int` type as `C.uint`; see the [[http://golang.org/cmd/cgo][cgo documentation]] for a complete list of these numeric type names.
+
+The one detail of this example we haven't examined yet is the comment above the `import` statement.
+
+ /*
+ #include <stdlib.h>
+ */
+ import "C"
+
+Cgo recognizes this comment. Any lines starting with `#cgo` followed by a space character are removed; these become directives for cgo. The remaining lines are used as a header when compiling the C parts of the package. In this case those lines are just a single `#include` statement, but they can be almost any C code. The `#cgo` directives are used to provide flags for the compiler and linker when building the C parts of the package.
+
+There is a limitation: if your program uses any `//export` directives, then the C code in the comment may only include declarations (`extern`int`f();`), not definitions (`int`f()`{`return`1;`}`). You can use `//export` directives to make Go functions accessible to C code.
+
+The `#cgo` and `//export` directives are documented in the [[http://golang.org/cmd/cgo/][cgo documentation]].
+
+* Strings and things
+
+Unlike Go, C doesn't have an explicit string type. Strings in C are represented by a zero-terminated array of chars.
+
+Conversion between Go and C strings is done with the `C.CString`, `C.GoString`, and `C.GoStringN` functions. These conversions make a copy of the string data.
+
+This next example implements a `Print` function that writes a string to standard output using C's `fputs` function from the `stdio` library:
+
+ package print
+
+ // #include <stdio.h>
+ // #include <stdlib.h>
+ import "C"
+ import "unsafe"
+
+ func Print(s string) {
+ cs := C.CString(s)
+ C.fputs(cs, (*C.FILE)(C.stdout))
+ C.free(unsafe.Pointer(cs))
+ }
+
+Memory allocations made by C code are not known to Go's memory manager. When you create a C string with `C.CString` (or any C memory allocation) you must remember to free the memory when you're done with it by calling `C.free`.
+
+The call to `C.CString` returns a pointer to the start of the char array, so before the function exits we convert it to an [[http://golang.org/pkg/unsafe/#Pointer][`unsafe.Pointer`]] and release the memory allocation with `C.free`. A common idiom in cgo programs is to [[http://golang.org/doc/articles/defer_panic_recover.html][`defer`]] the free immediately after allocating (especially when the code that follows is more complex than a single function call), as in this rewrite of `Print`:
+
+ func Print(s string) {
+ cs := C.CString(s)
+ defer C.free(unsafe.Pointer(cs))
+ C.fputs(cs, (*C.FILE)(C.stdout))
+ }
+
+* Building cgo packages
+
+To build cgo packages, just use [[http://golang.org/cmd/go/#Compile_packages_and_dependencies][`go`build`]] or [[http://golang.org/cmd/go/#Compile_and_install_packages_and_dependencies][`go`install`]] as usual. The go tool recognizes the special `"C"` import and automatically uses cgo for those files.
+
+* More cgo resources
+
+The [[http://golang.org/cmd/cgo/][cgo command]] documentation has more detail about the C pseudo-package and the build process. The [[http://golang.org/misc/cgo/][cgo examples]] in the Go tree demonstrate more advanced concepts.
+
+For a simple, idiomatic example of a cgo-based package, see Russ Cox's [[http://code.google.com/p/gosqlite/source/browse/sqlite/sqlite.go][gosqlite]]. Also, the Go Project Dashboard lists [[https://godashboard.appspot.com/project?tag=cgo][several other cgo packages]].
+
+Finally, if you're curious as to how all this works internally, take a look at the introductory comment of the runtime package's [[http://golang.org/src/pkg/runtime/cgocall.c][cgocall.c]].
diff --git a/content/concurrency-is-not-parallelism.article b/content/concurrency-is-not-parallelism.article
new file mode 100644
index 0000000..c3ff611
--- /dev/null
+++ b/content/concurrency-is-not-parallelism.article
@@ -0,0 +1,19 @@
+Concurrency is not parallelism
+16 Jan 2013
+Tags: concurrency, talk, video
+
+Andrew Gerrand
+
+* Introduction
+
+If there's one thing most people know about Go, is that it is designed for concurrency. No introduction to Go is complete without a demonstration of its goroutines and channels.
+
+But when people hear the word _concurrency_ they often think of _parallelism_, a related but quite distinct concept. In programming, concurrency is the _composition_ of independently executing processes, while parallelism is the simultaneous _execution_ of (possibly related) computations. Concurrency is about _dealing_with_ lots of things at once. Parallelism is about _doing_ lots of things at once.
+
+To clear up this conflation, Rob Pike gave a talk at [[http://heroku.com/][Heroku]]'s [[http://waza.heroku.com/][Waza]] conference entitled _Concurrency_is_not_parallelism_, and a video recording of the talk was released a few months ago.
+
+.iframe http://player.vimeo.com/video/49718712?badge=0 281 500
+
+The slides are available at [[http://talks.golang.org/2012/waza.slide][talks.golang.org]] (use the left and right arrow keys to navigate).
+
+To learn about Go's concurrency primitives, watch [[http://www.youtube.com/watch?v=f6kdp27TYZs][Go concurrency patterns]] ([[http://talks.golang.org/2012/concurrency.slide][slides]]).
diff --git a/content/debugging-go-code-status-report.article b/content/debugging-go-code-status-report.article
new file mode 100644
index 0000000..0706d14
--- /dev/null
+++ b/content/debugging-go-code-status-report.article
@@ -0,0 +1,34 @@
+Debugging Go code (a status report)
+2 Nov 2010
+Tags: debug, gdb
+
+Luuk van Dijk
+
+* Introduction
+
+When it comes to debugging, nothing beats a few strategic print statements to inspect variables or a well-placed panic to obtain a stack trace. However, sometimes you’re missing either the patience or the source code, and in those cases a good debugger can be invaluable. That's why over the past few releases we have been improving the support in Go’s gc linker (6l, 8l) for GDB, the GNU debugger.
+
+In the latest release (2010-11-02), the 6l and 8l linkers emit DWARF3 debugging information when writing ELF (Linux, FreeBSD) or Mach-O (Mac OS X) binaries. The DWARF code is rich enough to let you do the following:
+
+- load a Go program in GDB version 7.x,
+- list all Go, C, and assembly source files by line (parts of the Go runtime are written in C and assembly),
+- set breakpoints by line and step through the code,
+- print stack traces and inspect stack frames, and
+- find the addresses and print the contents of most variables.
+
+There are still some inconveniences:
+
+- The emitted DWARF code is unreadable by the GDB version 6.x that ships with Mac OS X. We would gladly accept patches to make the DWARF output compatible with the standard OS X GDB, but until that’s fixed you’ll need to download, build, and install GDB 7.x to use it under OS X. The source can be found at [[http://sourceware.org/gdb/download/][http://sourceware.org/gdb/download/]]. Due to the particulars of OS X you’ll need to install the binary on a local file system with `chgrp`procmod` and `chmod`g+s`.
+- Names are qualified with a package name and, as GDB doesn't understand Go packages, you must reference each item by its full name. For example, the variable named `v` in package `main` must be referred to as `'main.v'`, in single quotes. A consequence of this is that tab completion of variable and function names does not work.
+- Lexical scoping information is somewhat obfuscated. If there are multiple variables of the same name, the nth instance will have a suffix of the form ‘#n’. We plan to fix this, but it will require some changes to the data exchanged between the compiler and linker.
+- Slice and string variables are represented as their underlying structure in the runtime library. They will look something like `{data`=`0x2aaaaab3e320,`len`=`1,`cap`=`1}.` For slices, you must dereference the data pointer to inspect the elements.
+
+Some things don't work yet:
+
+- Channel, function, interface, and map variables cannot be inspected.
+- Only Go variables are annotated with type information; the runtime's C variables are not.
+- Windows and ARM binaries do not contain DWARF debugging information and, as such, cannot be inspected with GDB.
+
+Over the coming months we intend to address these issues, either by changing the compiler and linker or by using the Python extensions to GDB. In the meantime, we hope that Go programmers will benefit from having better access to this well-known debugging tool.
+
+P.S. The DWARF information can also be read by tools other than GDB. For example, on Linux you can use it with the sysprof system-wide profiler.
diff --git a/content/debugging-go-programs-with-gnu-debugger.article b/content/debugging-go-programs-with-gnu-debugger.article
new file mode 100644
index 0000000..0a9a069
--- /dev/null
+++ b/content/debugging-go-programs-with-gnu-debugger.article
@@ -0,0 +1,12 @@
+Debugging Go programs with the GNU Debugger
+30 Oct 2011
+Tags: debug, gdb
+
+Andrew Gerrand
+
+* Introduction
+
+Last year we [[http://blog.golang.org/2010/11/debugging-go-code-status-report.html][reported]] that Go's [[http://golang.org/cmd/gc/][gc]]/[[http://golang.org/cmd/6l/][ld]] toolchain produces DWARFv3 debugging information that can be read by the GNU Debugger (GDB). Since then, work has continued steadily on improving support for debugging Go code with GDB.
+Among the improvements are the ability to inspect goroutines and to print native Go data types, including structs, slices, strings, maps, interfaces, and channels.
+
+To learn more about Go and GDB, see the [[http://golang.org/doc/debugging_with_gdb.html][Debugging with GDB]] article.
diff --git a/content/defer-panic-and-recover.article b/content/defer-panic-and-recover.article
new file mode 100644
index 0000000..00f0327
--- /dev/null
+++ b/content/defer-panic-and-recover.article
@@ -0,0 +1,197 @@
+Defer, Panic, and Recover
+4 Aug 2010
+Tags: closure, defer, panic, recover
+
+Andrew Gerrand
+
+* Introduction
+
+Go has the usual mechanisms for control flow: if, for, switch, goto. It also has the go statement to run code in a separate goroutine. Here I'd like to discuss some of the less common ones: defer, panic, and recover.
+
+
+A *defer*statement* pushes a function call onto a list. The list of saved calls is executed after the surrounding function returns. Defer is commonly used to simplify functions that perform various clean-up actions.
+
+
+For example, let's look at a function that opens two files and copies the contents of one file to the other:
+
+
+ func CopyFile(dstName, srcName string) (written int64, err error) {
+ src, err := os.Open(srcName)
+ if err != nil {
+ return
+ }
+
+ dst, err := os.Create(dstName)
+ if err != nil {
+ return
+ }
+
+ written, err = io.Copy(dst, src)
+ dst.Close()
+ src.Close()
+ return
+ }
+
+This works, but there is a bug. If the call to os.Create fails, the function will return without closing the source file. This can be easily remedied by putting a call to src.Close before the second return statement, but if the function were more complex the problem might not be so easily noticed and resolved. By introducing defer statements we can ensure that the files are always closed:
+
+
+ func CopyFile(dstName, srcName string) (written int64, err error) {
+ src, err := os.Open(srcName)
+ if err != nil {
+ return
+ }
+ defer src.Close()
+
+ dst, err := os.Create(dstName)
+ if err != nil {
+ return
+ }
+ defer dst.Close()
+
+ return io.Copy(dst, src)
+ }
+
+Defer statements allow us to think about closing each file right after opening it, guaranteeing that, regardless of the number of return statements in the function, the files _will_ be closed.
+
+The behavior of defer statements is straightforward and predictable. There are three simple rules:
+
+1. _A_deferred_function's_arguments_are_evaluated_when_the_defer_statement_is_evaluated._
+
+In this example, the expression "i" is evaluated when the Println call is deferred. The deferred call will print "0" after the function returns.
+
+
+ func a() {
+ i := 0
+ defer fmt.Println(i)
+ i++
+ return
+ }
+
+2. _Deferred_function_calls_are_executed_in_Last_In_First_Out_order_after__the_surrounding_function_returns._
+
+This function prints "3210":
+
+ func b() {
+ for i := 0; i < 4; i++ {
+ defer fmt.Print(i)
+ }
+ }
+
+
+3. _Deferred_functions_may_read_and_assign_to_the_returning_function's_named_return_values._
+
+In this example, a deferred function increments the return value i _after_ the surrounding function returns. Thus, this function returns 2:
+
+ func c() (i int) {
+ defer func() { i++ }()
+ return 1
+ }
+
+
+This is convenient for modifying the error return value of a function; we will see an example of this shortly.
+
+
+*Panic* is a built-in function that stops the ordinary flow of control and begins _panicking_. When the function F calls panic, execution of F stops, any deferred functions in F are executed normally, and then F returns to its caller. To the caller, F then behaves like a call to panic. The process continues up the stack until all functions in the current goroutine have returned, at which point the program crashes. Panics can be initiated by invoking panic directly. They can also be caused by runtime errors, such as out-of-bounds array accesses.
+
+
+*Recover* is a built-in function that regains control of a panicking goroutine. Recover is only useful inside deferred functions. During normal execution, a call to recover will return nil and have no other effect. If the current goroutine is panicking, a call to recover will capture the value given to panic and resume normal execution.
+
+
+Here's an example program that demonstrates the mechanics of panic and defer:
+
+ package main
+
+ import "fmt"
+
+ func main() {
+ f()
+ fmt.Println("Returned normally from f.")
+ }
+
+ func f() {
+ defer func() {
+ if r := recover(); r != nil {
+ fmt.Println("Recovered in f", r)
+ }
+ }()
+ fmt.Println("Calling g.")
+ g(0)
+ fmt.Println("Returned normally from g.")
+ }
+
+ func g(i int) {
+ if i > 3 {
+ fmt.Println("Panicking!")
+ panic(fmt.Sprintf("%v", i))
+ }
+ defer fmt.Println("Defer in g", i)
+ fmt.Println("Printing in g", i)
+ g(i + 1)
+ }
+
+
+The function g takes the int i, and panics if i is greater than 3, or else it calls itself with the argument i+1. The function f defers a function that calls recover and prints the recovered value (if it is non-nil). Try to picture what the output of this program might be before reading on.
+
+
+The program will output:
+
+
+ Calling g.
+ Printing in g 0
+ Printing in g 1
+ Printing in g 2
+ Printing in g 3
+ Panicking!
+ Defer in g 3
+ Defer in g 2
+ Defer in g 1
+ Defer in g 0
+ Recovered in f 4
+ Returned normally from f.
+
+
+
+If we remove the deferred function from f the panic is not recovered and reaches the top of the goroutine's call stack, terminating the program. This modified program will output:
+
+
+ Calling g.
+ Printing in g 0
+ Printing in g 1
+ Printing in g 2
+ Printing in g 3
+ Panicking!
+ Defer in g 3
+ Defer in g 2
+ Defer in g 1
+ Defer in g 0
+ panic: 4
+
+ panic PC=0x2a9cd8
+ [stack trace omitted]
+
+
+
+For a real-world example of *panic* and *recover*, see the [[http://golang.org/pkg/encoding/json/][json package]] from the Go standard library. It decodes JSON-encoded data with a set of recursive functions. When malformed JSON is encountered, the parser calls panic to unwind the stack to the top-level function call, which recovers from the panic and returns an appropriate error value (see the 'error' and 'unmarshal' methods of the decodeState type in [[http://golang.org/src/pkg/encoding/json/decode.go][decode.go]]).
+
+The convention in the Go libraries is that even when a package uses panic internally, its external API still presents explicit error return values.
+
+
+Other uses of *defer* (beyond the file.Close example given earlier) include releasing a mutex:
+
+ mu.Lock()
+ defer mu.Unlock()
+
+
+
+printing a footer:
+
+
+ printHeader()
+ defer printFooter()
+
+
+
+and more.
+
+
+In summary, the defer statement (with or without panic and recover) provides an unusual and powerful mechanism for control flow. It can be used to model a number of features implemented by special-purpose structures in other programming languages. Try it out.
diff --git a/content/error-handling-and-go.article b/content/error-handling-and-go.article
new file mode 100644
index 0000000..65b2830
--- /dev/null
+++ b/content/error-handling-and-go.article
@@ -0,0 +1,242 @@
+Error handling and Go
+12 Jul 2011
+Tags: error, interface, type
+
+Andrew Gerrand
+
+* Introduction
+
+If you have written any Go code you have probably encountered the built-in `error` type. Go code uses `error` values to indicate an abnormal state. For example, the `os.Open` function returns a non-nil `error` value when it fails to open a file.
+
+ func Open(name string) (file *File, err error)
+
+The following code uses `os.Open` to open a file. If an error occurs it calls `log.Fatal` to print the error message and stop.
+
+ f, err := os.Open("filename.ext")
+ if err != nil {
+ log.Fatal(err)
+ }
+ // do something with the open *File f
+
+You can get a lot done in Go knowing just this about the `error` type, but in this article we'll take a closer look at `error` and discuss some good practices for error handling in Go.
+
+* The error type
+
+The `error` type is an interface type. An `error` variable represents any value that can describe itself as a string. Here is the interface's declaration:
+
+ type error interface {
+ Error() string
+ }
+
+The `error` type, as with all built in types, is [[http://golang.org/doc/go_spec.html#Predeclared_identifiers][predeclared]] in the [[http://golang.org/doc/go_spec.html#Blocks][universe block]].
+
+The most commonly-used `error` implementation is the [[http://golang.org/pkg/errors/][errors]] package's unexported `errorString` type.
+
+ // errorString is a trivial implementation of error.
+ type errorString struct {
+ s string
+ }
+
+ func (e *errorString) Error() string {
+ return e.s
+ }
+
+You can construct one of these values with the `errors.New` function. It takes a string that it converts to an `errors.errorString` and returns as an `error` value.
+
+ // New returns an error that formats as the given text.
+ func New(text string) error {
+ return &errorString{text}
+ }
+
+Here's how you might use `errors.New`:
+
+ func Sqrt(f float64) (float64, error) {
+ if f < 0 {
+ return 0, errors.New("math: square root of negative number")
+ }
+ // implementation
+ }
+
+A caller passing a negative argument to `Sqrt` receives a non-nil `error` value (whose concrete representation is an `errors.errorString` value). The caller can access the error string ("math: square root of...") by calling the `error`'s `Error` method, or by just printing it:
+
+ f, err := Sqrt(-1)
+ if err != nil {
+ fmt.Println(err)
+ }
+
+The [[http://golang.org/pkg/fmt/][fmt]] package formats an `error` value by calling its `Error()`string` method.
+
+It is the error implementation's responsibility to summarize the context. The error returned by `os.Open` formats as "open /etc/passwd: permission denied," not just "permission denied." The error returned by our `Sqrt` is missing information about the invalid argument.
+
+To add that information, a useful function is the `fmt` package's `Errorf`. It formats a string according to `Printf`'s rules and returns it as an `error` created by `errors.New`.
+
+ if f < 0 {
+ return 0, fmt.Errorf("math: square root of negative number %g", f)
+ }
+
+In many cases `fmt.Errorf` is good enough, but since `error` is an interface, you can use arbitrary data structures as error values, to allow callers to inspect the details of the error.
+
+For instance, our hypothetical callers might want to recover the invalid argument passed to `Sqrt`. We can enable that by defining a new error implementation instead of using `errors.errorString`:
+
+ type NegativeSqrtError float64
+
+ func (f NegativeSqrtError) Error() string {
+ return fmt.Sprintf("math: square root of negative number %g", float64(f))
+ }
+
+A sophisticated caller can then use a [[http://golang.org/doc/go_spec.html#Type_assertions][type assertion]] to check for a `NegativeSqrtError` and handle it specially, while callers that just pass the error to `fmt.Println` or `log.Fatal` will see no change in behavior.
+
+As another example, the [[http://golang.org/pkg/encoding/json/][json]] package specifies a `SyntaxError` type that the `json.Decode` function returns when it encounters a syntax error parsing a JSON blob.
+
+ type SyntaxError struct {
+ msg string // description of error
+ Offset int64 // error occurred after reading Offset bytes
+ }
+
+ func (e *SyntaxError) Error() string { return e.msg }
+
+The `Offset` field isn't even shown in the default formatting of the error, but callers can use it to add file and line information to their error messages:
+
+ if err := dec.Decode(&val); err != nil {
+ if serr, ok := err.(*json.SyntaxError); ok {
+ line, col := findLine(f, serr.Offset)
+ return fmt.Errorf("%s:%d:%d: %v", f.Name(), line, col, err)
+ }
+ return err
+ }
+
+(This is a slightly simplified version of some [[http://camlistore.org/code/?p=camlistore.git;a=blob;f=lib/go/camli/jsonconfig/eval.go#l68][actual code]] from the [[http://camlistore.org][Camlistore]] project.)
+
+The `error` interface requires only a `Error` method; specific error implementations might have additional methods. For instance, the [[http://golang.org/pkg/net/][net]] package returns errors of type `error`, following the usual convention, but some of the error implementations have additional methods defined by the `net.Error` interface:
+
+ package net
+
+ type Error interface {
+ error
+ Timeout() bool // Is the error a timeout?
+ Temporary() bool // Is the error temporary?
+ }
+
+Client code can test for a `net.Error` with a type assertion and then distinguish transient network errors from permanent ones. For instance, a web crawler might sleep and retry when it encounters a temporary error and give up otherwise.
+
+ if nerr, ok := err.(net.Error); ok && nerr.Temporary() {
+ time.Sleep(1e9)
+ continue
+ }
+ if err != nil {
+ log.Fatal(err)
+ }
+
+* Simplifying repetitive error handling
+
+In Go, error handling is important. The language's design and conventions encourage you to explicitly check for errors where they occur (as distinct from the convention in other languages of throwing exceptions and sometimes catching them). In some cases this makes Go code verbose, but fortunately there are some techniques you can use to minimize repetitive error handling.
+
+Consider an [[http://code.google.com/appengine/docs/go/][App Engine]] application with an HTTP handler that retrieves a record from the datastore and formats it with a template.
+
+ func init() {
+ http.HandleFunc("/view", viewRecord)
+ }
+
+ func viewRecord(w http.ResponseWriter, r *http.Request) {
+ c := appengine.NewContext(r)
+ key := datastore.NewKey(c, "Record", r.FormValue("id"), 0, nil)
+ record := new(Record)
+ if err := datastore.Get(c, key, record); err != nil {
+ http.Error(w, err.Error(), 500)
+ return
+ }
+ if err := viewTemplate.Execute(w, record); err != nil {
+ http.Error(w, err.Error(), 500)
+ }
+ }
+
+This function handles errors returned by the `datastore.Get` function and `viewTemplate`'s `Execute` method. In both cases, it presents a simple error message to the user with the HTTP status code 500 ("Internal Server Error"). This looks like a manageable amount of code, but add some more HTTP handlers and you quickly end up with many copies of identical error handling code.
+
+To reduce the repetition we can define our own HTTP `appHandler` type that includes an `error` return value:
+
+ type appHandler func(http.ResponseWriter, *http.Request) error
+
+Then we can change our `viewRecord` function to return errors:
+
+ func viewRecord(w http.ResponseWriter, r *http.Request) error {
+ c := appengine.NewContext(r)
+ key := datastore.NewKey(c, "Record", r.FormValue("id"), 0, nil)
+ record := new(Record)
+ if err := datastore.Get(c, key, record); err != nil {
+ return err
+ }
+ return viewTemplate.Execute(w, record)
+ }
+
+This is simpler than the original version, but the [[http://golang.org/pkg/net/http/][http]] package doesn't understand functions that return `error`. To fix this we can implement the `http.Handler` interface's `ServeHTTP` method on `appHandler`:
+
+ func (fn appHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
+ if err := fn(w, r); err != nil {
+ http.Error(w, err.Error(), 500)
+ }
+ }
+
+The `ServeHTTP` method calls the `appHandler` function and displays the returned error (if any) to the user. Notice that the method's receiver, `fn`, is a function. (Go can do that!) The method invokes the function by calling the receiver in the expression `fn(w,`r)`.
+
+Now when registering `viewRecord` with the http package we use the `Handle` function (instead of `HandleFunc`) as `appHandler` is an `http.Handler` (not an `http.HandlerFunc`).
+
+ func init() {
+ http.Handle("/view", appHandler(viewRecord))
+ }
+
+With this basic error handling infrastructure in place, we can make it more user friendly. Rather than just displaying the error string, it would be better to give the user a simple error message with an appropriate HTTP status code, while logging the full error to the App Engine developer console for debugging purposes.
+
+To do this we create an `appError` struct containing an `error` and some other fields:
+
+ type appError struct {
+ Error error
+ Message string
+ Code int
+ }
+
+Next we modify the appHandler type to return `*appError` values:
+
+ type appHandler func(http.ResponseWriter, *http.Request) *appError
+
+(It's usually a mistake to pass back the concrete type of an error rather than `error`, for reasons discussed in [[http://golang.org/doc/go_faq.html#nil_error][the Go FAQ]], but it's the right thing to do here because `ServeHTTP` is the only place that sees the value and uses its contents.)
+
+And make `appHandler`'s `ServeHTTP` method display the `appError`'s `Message` to the user with the correct HTTP status `Code` and log the full `Error` to the developer console:
+
+ func (fn appHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
+ if e := fn(w, r); e != nil { // e is *appError, not os.Error.
+ c := appengine.NewContext(r)
+ c.Errorf("%v", e.Error)
+ http.Error(w, e.Message, e.Code)
+ }
+ }
+
+Finally, we update `viewRecord` to the new function signature and have it return more context when it encounters an error:
+
+ func viewRecord(w http.ResponseWriter, r *http.Request) *appError {
+ c := appengine.NewContext(r)
+ key := datastore.NewKey(c, "Record", r.FormValue("id"), 0, nil)
+ record := new(Record)
+ if err := datastore.Get(c, key, record); err != nil {
+ return &appError{err, "Record not found", 404}
+ }
+ if err := viewTemplate.Execute(w, record); err != nil {
+ return &appError{err, "Can't display record", 500}
+ }
+ return nil
+ }
+
+This version of `viewRecord` is the same length as the original, but now each of those lines has specific meaning and we are providing a friendlier user experience.
+
+It doesn't end there; we can further improve the error handling in our application. Some ideas:
+
+- give the error handler a pretty HTML template,
+
+- make debugging easier by writing the stack trace to the HTTP response when the user is an administrator,
+
+- write a constructor function for `appError` that stores the stack trace for easier debugging,
+
+- recover from panics inside the `appHandler`, logging the error to the console as "Critical," while telling the user "a serious error has occurred." This is a nice touch to avoid exposing the user to inscrutable error messages caused by programming errors. See the [[http://golang.org/doc/articles/defer_panic_recover.html][Defer, Panic, and Recover]] article for more details.
+
+* Conclusion
+
+Proper error handling is an essential requirement of good software. By employing the techniques described in this post you should be able to write more reliable and succinct Go code.
diff --git a/content/first-class-functions-in-go-and-new-go.article b/content/first-class-functions-in-go-and-new-go.article
new file mode 100644
index 0000000..b3b3852
--- /dev/null
+++ b/content/first-class-functions-in-go-and-new-go.article
@@ -0,0 +1,15 @@
+"First Class Functions in Go" and new Go course notes
+30 Jun 2011
+Tags: codewalk, function
+
+Andrew Gerrand
+
+* Introduction
+
+We would like to announce some new and revised Go learning materials.
+
+Programmers new to Go are often surprised by its support for function types, functions as values, and closures. The [[http://golang.org/doc/codewalk/functions/][First Class Functions in Go]] code walk demonstrates these features with a simulation of the dice game [[http://en.wikipedia.org/wiki/Pig_(dice)][Pig]]. It is a pretty program that uses the language to great effect, and a fun read for Go beginners and veterans alike.
+
+The [[http://golang.org/doc/docs.html#course_notes][Go course]] is a [[http://golang.org/doc/GoCourseDay1.pdf][three]] [[http://golang.org/doc/GoCourseDay2.pdf][part]] [[http://golang.org/doc/GoCourseDay3.pdf][series]] that describes the language in detail, including the basic syntax, type system, and concurrency primitives. These notes were available at launch in 2009, but since then the language has changed a bit and the course notes had become an outdated and unreliable resource. We recently revised all three slide decks in their entirety, updating them to match contemporary Go syntax and semantics. The course is ideal for those who want to get the full picture and a great resource for teaching the language to others.
+
+These resources and many more are available at [[http://golang.org/doc/docs.html][golang.org]].
diff --git a/content/from-zero-to-go-launching-on-google.article b/content/from-zero-to-go-launching-on-google.article
new file mode 100644
index 0000000..045f626
--- /dev/null
+++ b/content/from-zero-to-go-launching-on-google.article
@@ -0,0 +1,204 @@
+From zero to Go: launching on the Google homepage in 24 hours
+13 Dec 2011
+Tags: appengine, google, guest
+
+Reinaldo Aguiar
+
+* Introduction
+
+_This_article_was_written_by_Reinaldo_Aguiar,_a_software_engineer_from_the_Search_team_at_Google._He_shares_his_experience_developing_his_first_Go_program_and_launching_it_to_an_audience_of_millions_-_all_in_one_day!_
+
+I was recently given the opportunity to collaborate on a small but highly visible "20% project": the [[http://www.google.com/logos/2011/thanksgiving.html][Thanksgiving 2011 Google Doodle]]. The doodle features a turkey produced by randomly combining different styles of head, wings, feathers and legs. The user can customize it by clicking on the different parts of the turkey. This interactivity is implemented in the browser by a combination of JavaScript, CSS and of course HTML, creating turkeys on the fly.
+
+.image from-zero-to-go-launching-on-google_image00.png
+
+Once the user has created a personalized turkey it can be shared with friends and family by posting to Google+. Clicking a "Share" button (not pictured here) creates in the user's Google+ stream a post containing a snapshot of the turkey. The snapshot is a single image that matches the turkey the user created.
+
+With 13 alternatives for each of 8 parts of the turkey (heads, pairs of legs, distinct feathers, etc.) there are more than than 800 million possible snapshot images that could be generated. To pre-compute them all is clearly infeasible. Instead, we must generate the snapshots on the fly. Combining that problem with a need for immediate scalability and high availability, the choice of platform is obvious: Google App Engine!
+
+The next thing we needed to decide was which App Engine runtime to use. Image manipulation tasks are CPU-bound, so performance is the deciding factor in this case.
+
+To make an informed decision we ran a test. We quickly prepared a couple of equivalent demo apps for the new [[http://code.google.com/appengine/docs/python/python27/newin27.html][Python 2.7 runtime]] (which provides [[http://www.pythonware.com/products/pil/][PIL]], a C-based imaging library) and the Go runtime. Each app generates an image composed of several small images, encodes the image as a JPEG, and sends the JPEG data as the HTTP response. The Python 2.7 app served requests with a median latency of 65 milliseconds, while the Go app ran with a median latency of just 32 milliseconds.
+
+This problem therefore seemed the perfect opportunity to try the experimental Go runtime.
+
+I had no previous experience with Go and the timeline was tight: two days to be production ready. This was intimidating, but I saw it as an opportunity to test Go from a different, often overlooked angle: development velocity. How fast can a person with no Go experience pick it up and build something that performs and scales?
+
+* Design
+
+The approach was to encode the state of the turkey in the URL, drawing and encoding the snapshot on the fly.
+
+The base for every doodle is the background:
+
+.image from-zero-to-go-launching-on-google_image01.jpg
+
+A valid request URL might look like this: [[http://google-turkey.appspot.com/thumb/20332620][http://google-turkey.appspot.com/thumb/20332620]]
+
+The alphanumeric string that follows "/thumb/" indicates (in hexadecimal) which choice to draw for each layout element, as illustrated by this image:
+
+.image from-zero-to-go-launching-on-google_image03.png
+
+The program's request handler parses the URL to determine which element is selected for each component, draws the appropriate images on top of the background image, and serves the result as a JPEG.
+
+If an error occurs, a default image is served. There's no point serving an error page because the user will never see it - the browser is almost certainly loading this URL into an image tag.
+
+* Implementation
+
+In the package scope we declare some data structures to describe the elements of the turkey, the location of the corresponding images, and where they should be drawn on the background image.
+
+ var (
+ // dirs maps each layout element to its location on disk.
+ dirs = map[string]string{
+ "h": "img/heads",
+ "b": "img/eyes_beak",
+ "i": "img/index_feathers",
+ "m": "img/middle_feathers",
+ "r": "img/ring_feathers",
+ "p": "img/pinky_feathers",
+ "f": "img/feet",
+ "w": "img/wing",
+ }
+
+ // urlMap maps each URL character position to
+ // its corresponding layout element.
+ urlMap = [...]string{"b", "h", "i", "m", "r", "p", "f", "w"}
+
+ // layoutMap maps each layout element to its position
+ // on the background image.
+ layoutMap = map[string]image.Rectangle{
+ "h": {image.Pt(109, 50), image.Pt(166, 152)},
+ "i": {image.Pt(136, 21), image.Pt(180, 131)},
+ "m": {image.Pt(159, 7), image.Pt(201, 126)},
+ "r": {image.Pt(188, 20), image.Pt(230, 125)},
+ "p": {image.Pt(216, 48), image.Pt(258, 134)},
+ "f": {image.Pt(155, 176), image.Pt(243, 213)},
+ "w": {image.Pt(169, 118), image.Pt(250, 197)},
+ "b": {image.Pt(105, 104), image.Pt(145, 148)},
+ }
+ )
+
+The geometry of the points above was calculated by measuring the actual location and size of each layout element within the image.
+
+Loading the images from disk on each request would be wasteful repetition, so we load all 106 images (13 * 8 elements + 1 background + 1 default) into global variables upon receipt of the first request.
+
+ var (
+ // elements maps each layout element to its images.
+ elements = make(map[string][]*image.RGBA)
+
+ // backgroundImage contains the background image data.
+ backgroundImage *image.RGBA
+
+ // defaultImage is the image that is served if an error occurs.
+ defaultImage *image.RGBA
+
+ // loadOnce is used to call the load function only on the first request.
+ loadOnce [[http://golang.org/pkg/sync/#Once][sync.Once]]
+ )
+
+ // load reads the various PNG images from disk and stores them in their
+ // corresponding global variables.
+ func load() {
+ defaultImage = loadPNG(defaultImageFile)
+ backgroundImage = loadPNG(backgroundImageFile)
+ for dirKey, dir := range dirs {
+ paths, err := filepath.Glob(dir + "/*.png")
+ if err != nil {
+ panic(err)
+ }
+ for _, p := range paths {
+ elements[dirKey] = append(elements[dirKey], loadPNG(p))
+ }
+ }
+ }
+
+Requests are handled in a straightforward sequence:
+
+- Parse the request URL, decoding the decimal value of each character in the path.
+
+- Make a copy of the background image as the base for the final image.
+
+- Draw each image element onto the background image using the layoutMap to determine where they should be drawn.
+
+- Encode the image as a JPEG
+
+- Return the image to user by writing the JPEG directly to the HTTP response writer.
+
+Should any error occur, we serve the defaultImage to the user and log the error to the App Engine dashboard for later analysis.
+
+Here's the code for the request handler with explanatory comments:
+
+ func handler(w http.ResponseWriter, r *http.Request) {
+ // [[http://blog.golang.org/2010/08/defer-panic-and-recover.html][Defer]] a function to recover from any panics.
+ // When recovering from a panic, log the error condition to
+ // the App Engine dashboard and send the default image to the user.
+ defer func() {
+ if err := recover(); err != nil {
+ c := appengine.NewContext(r)
+ c.Errorf("%s", err)
+ c.Errorf("%s", "Traceback: %s", r.RawURL)
+ if defaultImage != nil {
+ w.Header().Set("Content-type", "image/jpeg")
+ jpeg.Encode(w, defaultImage, &imageQuality)
+ }
+ }
+ }()
+
+ // Load images from disk on the first request.
+ loadOnce.Do(load)
+
+ // Make a copy of the background to draw into.
+ bgRect := backgroundImage.Bounds()
+ m := image.NewRGBA(bgRect.Dx(), bgRect.Dy())
+ draw.Draw(m, m.Bounds(), backgroundImage, image.ZP, draw.Over)
+
+ // Process each character of the request string.
+ code := strings.ToLower(r.URL.Path[len(prefix):])
+ for i, p := range code {
+ // Decode hex character p in place.
+ if p < 'a' {
+ // it's a digit
+ p = p - '0'
+ } else {
+ // it's a letter
+ p = p - 'a' + 10
+ }
+
+ t := urlMap[i] // element type by index
+ em := elements[t] // element images by type
+ if p >= len(em) {
+ panic(fmt.Sprintf("element index out of range %s: "+
+ "%d >= %d", t, p, len(em)))
+ }
+
+ // Draw the element to m,
+ // using the layoutMap to specify its position.
+ draw.Draw(m, layoutMap[t], em[p], image.ZP, draw.Over)
+ }
+
+ // Encode JPEG image and write it as the response.
+ w.Header().Set("Content-type", "image/jpeg")
+ w.Header().Set("Cache-control", "public, max-age=259200")
+ jpeg.Encode(w, m, &imageQuality)
+ }
+
+For brevity, I've omitted several helper functions from these code listings. See the [[http://code.google.com/p/go-thanksgiving/source/browse/][source code]] for the full scoop.
+
+* Performance
+
+[[http://3.bp.blogspot.com/-3dpdQWv1nzQ/TufkFj0bS-I/AAAAAAAAAEg/hONAssh_D9c/s1600/image02.png][.image from-zero-to-go-launching-on-google_image02.png ]]
+
+This chart - taken directly from the App Engine dashboard - shows average request latency during launch. As you can see, even under load it never exceeds 60 ms, with a median latency of 32 milliseconds. This is wicked fast, considering that our request handler is doing image manipulation and encoding on the fly.
+
+* Conclusions
+
+I found Go's syntax to be intuitive, simple and clean. I have worked a lot with interpreted languages in the past, and although Go is instead a statically typed and compiled language, writing this app felt more like working with a dynamic, interpreted language.
+
+The development server provided with the [[http://code.google.com/appengine/downloads.html#Google_App_Engine_SDK_for_Go][SDK]] quickly recompiles the program after any change, so I could iterate as fast as I would with an interpreted language. It's dead simple, too - it took less than a minute to set up my development environment.
+
+Go's great documentation also helped me put this together fast. The docs are generated from the source code, so each function's documentation links directly to the associated source code. This not only allows the developer to understand very quickly what a particular function does but also encourages the developer to dig into the package implementation, making it easier to learn good style and conventions.
+
+In writing this application I used just three resources: App Engine's [[http://code.google.com/appengine/docs/go/gettingstarted/helloworld.html][Hello World Go example]], [[http://golang.org/pkg/][the Go packages documentation]], and [[http://blog.golang.org/2011/09/go-imagedraw-package.html][a blog post showcasing the Draw package]]. Thanks to the rapid iteration made possible by the development server and the language itself, I was able to pick up the language and build a super fast, production ready, doodle generator in less than 24 hours.
+
+Download the full app source code (including images) at [[http://code.google.com/p/go-thanksgiving/source/browse/][the Google Code project]].
+
+Special thanks go to Guillermo Real and Ryan Germick who designed the doodle.
diff --git a/content/from-zero-to-go-launching-on-google_image00.png b/content/from-zero-to-go-launching-on-google_image00.png
new file mode 100644
index 0000000..d84e976
--- /dev/null
+++ b/content/from-zero-to-go-launching-on-google_image00.png
Binary files differ
diff --git a/content/from-zero-to-go-launching-on-google_image01.jpg b/content/from-zero-to-go-launching-on-google_image01.jpg
new file mode 100644
index 0000000..a3e3e0c
--- /dev/null
+++ b/content/from-zero-to-go-launching-on-google_image01.jpg
Binary files differ
diff --git a/content/from-zero-to-go-launching-on-google_image02.png b/content/from-zero-to-go-launching-on-google_image02.png
new file mode 100644
index 0000000..7bf1893
--- /dev/null
+++ b/content/from-zero-to-go-launching-on-google_image02.png
Binary files differ
diff --git a/content/from-zero-to-go-launching-on-google_image03.png b/content/from-zero-to-go-launching-on-google_image03.png
new file mode 100644
index 0000000..8a92079
--- /dev/null
+++ b/content/from-zero-to-go-launching-on-google_image03.png
Binary files differ
diff --git a/content/gccgo-in-gcc-471.article b/content/gccgo-in-gcc-471.article
new file mode 100644
index 0000000..f47aea2
--- /dev/null
+++ b/content/gccgo-in-gcc-471.article
@@ -0,0 +1,22 @@
+Gccgo in GCC 4.7.1
+11 Jul 2012
+
+Ian Lance Taylor
+
+* Introduction
+
+The Go language has always been defined by a [[http://golang.org/ref/spec][spec]], not an implementation. The Go team has written two different compilers that implement that spec: gc and gccgo. Having two different implementations helps ensure that the spec is complete and correct: when the compilers disagree, we fix the spec, and change one or both compilers accordingly. Gc is the original compiler, and the go tool uses it by default. Gccgo is a different implementation with a different focus, and in this post we’ll take a closer look at it.
+
+Gccgo is distributed as part of GCC, the GNU Compiler Collection. GCC supports several different frontends for different languages; gccgo is a Go frontend connected to the GCC backend. The Go frontend is separate from the GCC project and is designed to be able to connect to other compiler backends, but currently only supports GCC.
+
+Compared to gc, gccgo is slower to compile code but supports more powerful optimizations, so a CPU-bound program built by gccgo will usually run faster. All the optimizations implemented in GCC over the years are available, including inlining, loop optimizations, vectorization, instruction scheduling, and more. While it does not always produce better code, in some cases programs compiled with gccgo can run 30% faster.
+
+The gc compiler supports only the most popular processors: x86 (32-bit and 64-bit) and ARM. Gccgo, however, supports all the processors that GCC supports. Not all those processors have been thoroughly tested for gccgo, but many have, including x86 (32-bit and 64-bit), SPARC, MIPS, PowerPC and even Alpha. Gccgo has also been tested on operating systems that the gc compiler does not support, notably Solaris.
+
+Gccgo provides the standard, complete Go library. Many of the core features of the Go runtime are the same in both gccgo and gc, including the goroutine scheduler, channels, the memory allocator, and the garbage collector. Gccgo supports splitting goroutine stacks as the gc compiler does, but currently only on x86 (32-bit or 64-bit) and only when using the gold linker (on other processors, each goroutine will have a large stack, and a deep series of function calls may run past the end of the stack and crash the program).
+
+Gccgo distributions do not yet include a version of the go command. However, if you install the go command from a standard Go release, it already supports gccgo via the `-compiler` option: go build `-compiler`gccgo`myprog`. The tools used for calls between Go and C/C++, cgo and SWIG, also support gccgo.
+
+We have put the Go frontend under the same BSD license as the rest of the Go tools. You can download the source code for the frontend at the [[http://code.google.com/p/gofrontend][gofrontend Google Code project]]. Note that when the Go frontend is linked with the GCC backend to make gccgo, GCC’s GPL license takes precedence.
+
+The latest release of GCC, 4.7.1, includes gccgo with support for Go 1. If you need better performance for CPU-bound Go programs, or you need to support processors or operating systems that the gc compiler does not support, gccgo might be the answer.
diff --git a/content/getthee-to-go-meetup.article b/content/getthee-to-go-meetup.article
new file mode 100644
index 0000000..4435cbd
--- /dev/null
+++ b/content/getthee-to-go-meetup.article
@@ -0,0 +1,14 @@
+Get thee to a Go meetup
+27 Feb 2013
+
+Andrew Gerrand
+
+* Introduction
+
+Last week, David Symonds and I each gave talks at Sydney's Go meetup, [[http://www.meetup.com/golang-syd/][golang-syd]]. Dave spoke about [[http://talks.godoc.org/github.com/dsymonds/talks/2013-feb-golang-syd/golang-syd.slide][Go API design in the context of Protocol Buffers]], and I discussed some neat tricks in the construction of [[http://talks.godoc.org/github.com/nf/streak/talk.slide][a small command-line program]]. The presentations were short but provoked some good questions and interesting discussion. Of the 50-odd attendees, most were regular Go programmers and a fair chunk write Go code professionally. It was a fun night.
+
+It would have been great to see you there but, statistically, you're not from Sydney. Despair not, however, as there are likely some people in your area who either run a Go meetup or want to start one.
+
+The Go wiki lists [[http://code.google.com/p/go-wiki/wiki/GoUserGroups][Go user groups]] around the world, so if there's one nearby you should consider going along to the next event.
+
+If not, why not start your own? To gauge interest, ask around in the [[https://plus.google.com/communities/114112804251407510571][Go+ Community]] and the [[http://groups.google.com/group/golang-nuts][golang-nuts mailing list]], and take a look at this [[http://golang.meetup.com/all/][list of people]] waiting for a Go meetup in their area. Once you have a few people interested - and at least one person willing to present something - pick a venue and set a date. If you build it, they will come.
diff --git a/content/getting-to-know-go-community.article b/content/getting-to-know-go-community.article
new file mode 100644
index 0000000..c55c8fd
--- /dev/null
+++ b/content/getting-to-know-go-community.article
@@ -0,0 +1,16 @@
+Getting to know the Go community
+21 Dec 2011
+
+Andrew Gerrand
+
+* Introduction
+
+Over the past couple of years Go has attracted a lot of users and contributors, and I've had a great time meeting and talking with many of you. However, for every Gopher I know there are dozens I know nothing about. In order to address this imbalance I've prepared a survey for Go users everywhere.
+
+The survey is short. It asks about you, your involvement with Go, and and your interest in Go-related events. Among other things, this data will help myself and the rest of the Go team plan future Go events and schedule conference appearances.
+
+Please take a minute to [[https://docs.google.com/spreadsheet/viewform?hl=en_US&formkey=dFdxOTU1Mm92VFA3eHdkekFPamJjUnc6MQ#gid=0][complete the survey now]].
+
+Thanks!
+
+Andrew
diff --git a/content/gif-decoder-exercise-in-go-interfaces.article b/content/gif-decoder-exercise-in-go-interfaces.article
new file mode 100644
index 0000000..367c5c1
--- /dev/null
+++ b/content/gif-decoder-exercise-in-go-interfaces.article
@@ -0,0 +1,120 @@
+A GIF decoder: an exercise in Go interfaces
+25 May 2011
+Tags: gif, gopher, image, interface, lagomorph, lzw, moustache, rodent
+
+Rob Pike
+
+* Introduction
+
+At the Google I/O conference in San Francisco on May 10, 2011, we announced that the Go language is now available on Google App Engine. Go is the first language to be made available on App Engine that compiles directly to machine code, which makes it a good choice for CPU-intensive tasks such as image manipulation.
+
+In that vein, we demonstrated a program called [[http://moustach-io.appspot.com/][Moustachio]] that makes it easy to improve a picture such as this one:
+
+.image gif-decoder-exercise-in-go-interfaces_image00.jpg
+
+by adding a moustache and sharing the result:
+
+.image gif-decoder-exercise-in-go-interfaces_image02.jpg
+
+All the graphical processing, including rendering the antialiased moustache, is done by a Go program running on App Engine. (The source is available at [[http://code.google.com/p/appengine-go/source/browse/example/moustachio/][the appengine-go project]].)
+
+Although most images on the web—at least those likely to be moustachioed—are JPEGs, there are countless other formats floating around, and it seemed reasonable for Moustachio to accept uploaded images in a few of them. JPEG and PNG decoders already existed in the Go image library, but the venerable GIF format was not represented, so we decided to write a GIF decoder in time for the announcement. That decoder contains a few pieces that demonstrate how Go's interfaces make some problems easier to solve. The rest of this blog post describes a couple of instances.
+
+* The GIF format
+
+First, a quick tour of the GIF format. A GIF image file is _paletted_, that is, each pixel value is an index into a fixed color map that is included in the file. The GIF format dates from a time when there were usually no more than 8 bits per pixel on the display, and a color map was used to convert the limited set of values into the RGB (red, green, blue) triples needed to light the screen. (This is in contrast to a JPEG, for example, which has no color map because the encoding represents the distinct color signals separately.)
+
+A GIF image can contain anywhere from 1 to 8 bits per pixel, inclusive, but 8 bits per pixel is the most common.
+
+Simplifying somewhat, a GIF file contains a header defining the pixel depth and image dimensions, a color map (256 RGB triples for an 8-bit image), and then the pixel data. The pixel data is stored as a one-dimensional bit stream, compressed using the LZW algorithm, which is quite effective for computer-generated graphics although not so good for photographic imagery. The compressed data is then broken into length-delimited blocks with a one-byte count (0-255) followed by that many bytes:
+
+.image gif-decoder-exercise-in-go-interfaces_image03.gif
+
+* Deblocking the pixel data
+
+To decode GIF pixel data in Go, we can use the LZW decompressor from the `compress/lzw` package. It has a NewReader function that returns an object that, as [[http://golang.org/pkg/compress/lzw/#NewReader][the documentation]] says, "satisfies reads by decompressing the data read from r":
+
+ func NewReader(r io.Reader, order Order, litWidth int) io.ReadCloser
+
+Here `order` defines the bit-packing order and `litWidth` is the word size in bits, which for a GIF file corresponds to the pixel depth, typically 8.
+
+But we can't just give `NewReader` the input file as its first argument because the decompressor needs a stream of bytes but the GIF data is a stream of blocks that must be unpacked. To address this problem, we can wrap the input `io.Reader` with some code to deblock it, and make that code again implement `Reader`. In other words, we put the deblocking code into the `Read` method of a new type, which we call `blockReader`.
+
+Here's the data structure for a `blockReader`.
+
+ type blockReader struct {
+ r reader // Input source; implements io.Reader and io.ByteReader.
+ slice []byte // Buffer of unread data.
+ tmp [256]byte // Storage for slice.
+ }
+
+The reader, `r`, will be the source of the image data, perhaps a file or HTTP connection. The `slice` and `tmp` fields will be used to manage the deblocking. Here's the `Read` method in its entirety. It's a nice example of the use of slices and arrays in Go.
+
+ 1 func (b *blockReader) Read(p []byte) (int, os.Error) {
+ 2 if len(p) == 0 {
+ 3 return 0, nil
+ 4 }
+ 5 if len(b.slice) == 0 {
+ 6 blockLen, err := b.r.ReadByte()
+ 7 if err != nil {
+ 8 return 0, err
+ 9 }
+ 10 if blockLen == 0 {
+ 11 return 0, os.EOF
+ 12 }
+ 13 b.slice = b.tmp[0:blockLen]
+ 14 if _, err = io.ReadFull(b.r, b.slice); err != nil {
+ 15 return 0, err
+ 16 }
+ 17 }
+ 18 n := copy(p, b.slice)
+ 19 b.slice = b.slice[n:]
+ 20 return n, nil
+ 21 }
+
+Lines 2-4 are just a sanity check: if there's no place to put data, return zero. That should never happen, but it's good to be safe.
+
+Line 5 asks if there's data left over from a previous call by checking the length of `b.slice`. If there isn't, the slice will have length zero and we need to read the next block from `r`.
+
+A GIF block starts with a byte count, read on line 6. If the count is zero, GIF defines this to be a terminating block, so we return `EOF` on line 11.
+
+Now we know we should read `blockLen` bytes, so we point `b.slice` to the first `blockLen` bytes of `b.tmp` and then use the helper function `io.ReadFull` to read that many bytes. That function will return an error if it can't read exactly that many bytes, which should never happen. Otherwise we have `blockLen` bytes ready to read.
+
+Lines 18-19 copy the data from `b.slice` to the caller's buffer. We are implementing `Read`, not `ReadFull`, so we are allowed to return fewer than the requested number of bytes. That makes it easy: we just copy the data from `b.slice` to the caller's buffer (`p`), and the return value from copy is the number of bytes transferred. Then we reslice `b.slice` to drop the first `n` bytes, ready for the next call.
+
+It's a nice technique in Go programming to couple a slice (`b.slice`) to an array (`b.tmp`). In this case, it means `blockReader` type's `Read` method never does any allocations. It also means we don't need to keep a count around (it's implicit in the slice length), and the built-in `copy` function guarantees we never copy more than we should. (For more about slices, see [[http://blog.golang.org/2011/01/go-slices-usage-and-internals.html][this post from the Go Blog]].)
+
+Given the `blockReader` type, we can unblock the image data stream just by wrapping the input reader, say a file, like this:
+
+ deblockingReader := &blockReader{r: imageFile}
+
+This wrapping turns a block-delimited GIF image stream into a simple stream of bytes accessible by calls to the `Read` method of the `blockReader`.
+
+* Connecting the pieces
+
+With `blockReader` implemented and the LZW compressor available from the library, we have all the pieces we need to decode the image data stream. We stitch them together with this thunderclap, straight from the code:
+
+ lzwr := lzw.NewReader(&blockReader{r: d.r}, lzw.LSB, int(litWidth))
+ if _, err = io.ReadFull(lzwr, m.Pix); err != nil {
+ break
+ }
+
+That's it.
+
+The first line creates a `blockReader` and passes it to `lzw.NewReader` to create a decompressor. Here `d.r` is the `io.Reader` holding the image data, `lzw.LSB` defines the byte order in the LZW decompressor, and `litWidth` is the pixel depth.
+
+Given the decompressor, the second line calls `io.ReadFull` to decompress the data and store it in the image, `m.Pix`. When `ReadFull` returns, the image data is decompressed and stored in the image, `m`, ready to be displayed.
+
+This code worked first time. Really.
+
+We could avoid the temporary variable `lzwr` by placing the `NewReader` call into the argument list for `ReadFull`, just as we built the `blockReader` inside the call to `NewReader`, but that might be packing too much into a single line of code.
+
+* Conclusion
+
+Go's interfaces make it easy to construct software by assembling piece parts like this to restructure data. In this example, we implemented GIF decoding by chaining together a deblocker and a decompressor using the `io.Reader` interface, analogous to a type-safe Unix pipeline. Also, we wrote the deblocker as an (implicit) implementation of a `Reader` interface, which then required no extra declaration or boilerplate to fit it into the processing pipeline. It's hard to implement this decoder so compactly yet cleanly and safely in most languages, but the interface mechanism plus a few conventions make it almost natural in Go.
+
+That deserves another picture, a GIF this time:
+
+.image gif-decoder-exercise-in-go-interfaces_image01.gif
+
+The GIF format is defined at [[http://www.w3.org/Graphics/GIF/spec-gif89a.txt][http://www.w3.org/Graphics/GIF/spec-gif89a.txt]].
diff --git a/content/gif-decoder-exercise-in-go-interfaces_image00.jpg b/content/gif-decoder-exercise-in-go-interfaces_image00.jpg
new file mode 100644
index 0000000..aa0974e
--- /dev/null
+++ b/content/gif-decoder-exercise-in-go-interfaces_image00.jpg
Binary files differ
diff --git a/content/gif-decoder-exercise-in-go-interfaces_image01.gif b/content/gif-decoder-exercise-in-go-interfaces_image01.gif
new file mode 100644
index 0000000..060544a
--- /dev/null
+++ b/content/gif-decoder-exercise-in-go-interfaces_image01.gif
Binary files differ
diff --git a/content/gif-decoder-exercise-in-go-interfaces_image02.jpg b/content/gif-decoder-exercise-in-go-interfaces_image02.jpg
new file mode 100644
index 0000000..864d07c
--- /dev/null
+++ b/content/gif-decoder-exercise-in-go-interfaces_image02.jpg
Binary files differ
diff --git a/content/gif-decoder-exercise-in-go-interfaces_image03.gif b/content/gif-decoder-exercise-in-go-interfaces_image03.gif
new file mode 100644
index 0000000..2d6321b
--- /dev/null
+++ b/content/gif-decoder-exercise-in-go-interfaces_image03.gif
Binary files differ
diff --git a/content/go-and-google-app-engine.article b/content/go-and-google-app-engine.article
new file mode 100644
index 0000000..9f51540
--- /dev/null
+++ b/content/go-and-google-app-engine.article
@@ -0,0 +1,29 @@
+Go and Google App Engine
+10 May 2011
+Tags: appengine
+
+David Symonds
+
+Nigel Tao
+
+Andrew Gerrand
+
+* Introduction
+
+Google’s App Engine provides a reliable, scalable, easy way to build and deploy applications for the web. Over a hundred thousand apps are hosted at appspot.com and custom domains using the App Engine infrastructure. Originally written for Python apps, in 2009 the system added a Java runtime. And today, at Google I/O, we’re thrilled to announce that Go will be next. It’s marked as an experimental App Engine feature for now, because it’s early days, but both the App Engine and Go teams are very excited about this milestone.
+
+By early days, we mean that it’s still rolling out. As of today, the App Engine SDK for Go is [[http://code.google.com/p/googleappengine/downloads/list][available for download]], and we will soon enable deployment of Go apps into the App Engine hosting infrastructure. Today, through the SDK, you’ll be able to write web apps, learn about the APIs (and the language, if it’s new to you), and run your web app locally. Once full deployment is enabled, it’ll be easy to push your app to Google’s cloud.
+
+One of the cool but less obvious things about this news is that it provides a very easy way to play with Go. You don’t even need to have Go installed beforehand because the SDK is fully self-contained. Just download the SDK, unzip it, and start coding. Moreover, the SDK’s “dev app server” means you don’t even need to run the compiler yourself; everything is delightfully automatic.
+
+What you’ll find in the SDK is many of the standard App Engine APIs, custom designed in good Go style, including Datastore, Blobstore, URL Fetch, Mail, Users, and so on. More APIs will be added as the environment develops. The runtime provides the full Go language and almost all the standard libraries, except for a few things that don’t make sense in the App Engine environment. For instance, there is no `unsafe` package and the `syscall` package is trimmed. (The implementation uses an expanded version of the setup in the [[http://golang.org/doc/play/][Go Playground]] on [[http://golang.org/][golang.org]].)
+
+Also, although goroutines and channels are present, when a Go app runs on App Engine only one thread is run in a given instance. That is, all goroutines run in a single operating system thread, so there is no CPU parallelism available for a given client request. We expect this restriction will be lifted at some point.
+
+Despite these minor restrictions, it’s the real language: Code is deployed in source form and compiled in the cloud using the 64-bit x86 compiler (6g), making it the first true compiled language that runs on App Engine. Go on App Engine makes it possible to deploy efficient, CPU-intensive web applications.
+
+If you want to know more, read the [[http://code.google.com/appengine/docs/go/][documentation]] (start with “[[http://code.google.com/appengine/docs/go/gettingstarted/][Getting Started]]”). The libraries and SDK are open source, hosted at [[http://code.google.com/p/appengine-go/][http://code.google.com/p/appengine-go/]]. We’ve created a new [[http://groups.google.com/group/google-appengine-go][google-appengine-go]] mailing list; feel free to contact us there with App Engine-specific questions. The [[http://code.google.com/p/googleappengine/issues/list][issue tracker for App Engine]] is the place for reporting issues related to the new Go SDK.
+
+The Go App Engine SDK is [[http://code.google.com/p/googleappengine/downloads/list][available]] for Linux and Mac OS X (10.5 or greater); we hope a Windows version will also be available soon.
+
+We’d like to offer our thanks for all the help and enthusiasm we received from Google’s App Engine team in making this happen.
diff --git a/content/go-app-engine-sdk-155-released.article b/content/go-app-engine-sdk-155-released.article
new file mode 100644
index 0000000..0249ba0
--- /dev/null
+++ b/content/go-app-engine-sdk-155-released.article
@@ -0,0 +1,25 @@
+Go App Engine SDK 1.5.5 released
+11 Oct 2011
+Tags: appengine, gofix, release
+
+Andrew Gerrand
+
+* Introduction
+
+Today we released version 1.5.5 the Go App Engine SDK. You can download it from the [[http://code.google.com/appengine/downloads.html][App Engine downloads page]].
+
+This release includes changes and improvements to the App Engine APIs and brings the supporting Go tool chain to [[http://golang.org/doc/devel/release.html#r60][release.r60.2]] (the current stable release). Also included in this release are the [[http://golang.org/cmd/godoc/][godoc]], [[http://golang.org/cmd/gofmt/][gofmt]], and [[http://golang.org/cmd/gofix/][gofix]] tools from the Go tool chain. They can be found in the root directory of the SDK.
+
+Some changes made in this release are backwards-incompatible, so we have incremented the SDK `api_version` to 3. Existing apps will require code changes when migrating to `api_version` 3.
+
+The gofix tool that ships with the SDK has been customized with App Engine-specific modules. It can be used to automatically update Go apps to work with the latest appengine packages and the updated Go standard library. To update your apps, run:
+
+ /path/to/sdk/gofix /path/to/your/app
+
+The SDK now includes the appengine package source code, so you can use the local godoc to read App Engine API documentation:
+
+ /path/to/sdk/godoc appengine/datastore Get
+
+*Important*note:* We have deprecated `api_version` 2. Go apps that use `api_version` 2 will stop working after 16 December 2011. Please update your apps to use api_version 3 before then.
+
+See the [[http://code.google.com/p/googleappengine/wiki/SdkForGoReleaseNotes][release notes]] for a full list of changes. Please direct any questions about the new SDK to the [[http://groups.google.com/group/google-appengine-go][Go App Engine discussion group]].
diff --git a/content/go-at-google-io-2011-videos.article b/content/go-at-google-io-2011-videos.article
new file mode 100644
index 0000000..bc2aacd
--- /dev/null
+++ b/content/go-at-google-io-2011-videos.article
@@ -0,0 +1,42 @@
+Go at Google I/O 2011: videos
+23 May 2011
+Tags: appengine, gopher, talk, video
+
+Andrew Gerrand
+
+* Introduction
+
+The Go team had a great time at Google I/O 2011. It was a pleasure to meet so many programmers who share our enthusiasm for Go, and to share our work of the past few months. For those of you that couldn’t be there in person, you can now watch videos of our two Go presentations on YouTube.
+
+* Writing Web Apps in Go
+
+In “[[http://www.youtube.com/watch?v=-i0hat7pdpk][Writing Web Apps in Go]]” we announce the [[http://blog.golang.org/2011/05/go-and-google-app-engine.html][Go runtime for Google App Engine]] and walk through the development and deployment of [[http://moustach-io.appspot.com/][Moustachio]], the first Go App Engine app.
+
+.iframe http://www.youtube.com/embed/-i0hat7pdpk 349 560
+
+(See the [[http://golang.org/doc/talks/io2011/Writing_Web_Apps_in_Go.pdf][presentation slides]].)
+
+The [[https://code.google.com/p/appengine-go/source/browse/example/moustachio][source code]] for Moustachio is available as part of [[http://code.google.com/appengine/downloads.html#Google_App_Engine_SDK_for_Go][the SDK]] along with some other examples, such as this [[http://mandelbrot-tiles.appspot.com/][Mandelbrot demo]].
+
+Most important, this talk features the debut of the plush gopher.
+
+.image go-at-google-io-2011-videos_gopher.jpg
+
+For those that didn’t get one at the conference, we hope to make him available for purchase online soon.
+
+* Real World Go
+
+“[[http://www.youtube.com/watch?v=7QDVRowyUQA][Real World Go]]”, presented at [[http://io-bootcamp.com][I/O Bootcamp]], gives a brief introduction to Go and four case studies of its use in solving real problems:
+- [[http://heroku.com][Heroku]] with [[https://github.com/ha/doozerd][Doozer]], a highly available consistent data store,
+
+- [[http://mroffice.org/telephony.html][MROffice Dialer]], a VOIP system for call centers,
+
+- [[http://www.atlassian.com][Atlassian]]’s virtual machine cluster management system,
+
+- [[http://www.camlistore.org][Camlistore]], a content addressable storage system.
+
+.iframe http://www.youtube.com/embed/7QDVRowyUQA 349 560
+
+(See the [[http://golang.org/doc/talks/io2011/Real_World_Go.pdf ][presentation slides]].)
+
+Thanks to everyone who attended our talks and workshops. We look forward to seeing you again soon!
diff --git a/content/go-at-google-io-2011-videos_gopher.jpg b/content/go-at-google-io-2011-videos_gopher.jpg
new file mode 100644
index 0000000..aff98d4
--- /dev/null
+++ b/content/go-at-google-io-2011-videos_gopher.jpg
Binary files differ
diff --git a/content/go-at-heroku.article b/content/go-at-heroku.article
new file mode 100644
index 0000000..5e227ce
--- /dev/null
+++ b/content/go-at-heroku.article
@@ -0,0 +1,27 @@
+Go at Heroku
+21 Apr 2011
+Tags: concurrency, gofmt, guest, heroku, websocket
+
+Keith Rarick
+
+Blake Mizerany
+
+* Introduction
+
+_This_week’s_blog_post_is_written_by_ [[http://xph.us/][_Keith_Rarick_]] _and_ [[http://itsbonus.heroku.com/][_Blake_Mizerany_]], _systems_engineers_at_ [[http://www.heroku.com/][Heroku]]. _In_their_own_words,_they_"eat,_drink,_and_sleep_distributed_systems."_Here_they_discuss_their_experiences_using_Go._
+
+A big problem that comes with building distributed systems is the coordination of physical servers. Each server needs to know various facts about the system as a whole. This critical data includes locks, configuration data, and so on, and it must be consistent and available even during data store failures, so we need a data store with solid consistency guarantees. Our solution to this problem is [[http://xph.us/2011/04/13/introducing-doozer.html][Doozer]], a new, consistent, highly-available data store written in Go.
+
+At Doozer's core is [[http://en.wikipedia.org/wiki/Paxos_(computer_science)][Paxos]], a family of protocols for solving consensus in an unreliable network of unreliable nodes. While Paxos is essential to running a fault-tolerant system, it is notorious for being difficult to implement. Even example implementations that can be found online are complex and hard to follow, despite being simplified for educational purposes. Existing production systems have a reputation for being worse.
+
+Fortunately, Go's concurrency primitives made the task much easier. Paxos is defined in terms of independent, concurrent processes that communicate via passing messages. In Doozer, these processes are implemented as goroutines, and their communications as channel operations. In the same way that garbage collectors improve upon malloc and free, we found that [[http://blog.golang.org/2010/07/share-memory-by-communicating.html][goroutines and channels]] improve upon the lock-based approach to concurrency. These tools let us avoid complex bookkeeping and stay focused on the problem at hand. We are still amazed at how few lines of code it took to achieve something renowned for being difficult.
+
+The standard packages in Go were another big win for Doozer. The Go team is very pragmatic about what goes into them. For instance, a package we quickly found useful was [[http://golang.org/pkg/websocket/][websocket]]. Once we had a working data store, we needed an easy way to introspect it and visualize activity. Using the websocket package, Keith was able to add the web viewer on his train ride home and without requiring external dependencies. This is a real testament to how well Go mixes systems and application programming.
+
+One of our favorite productivity gains was provided by Go's source formatter: [[http://golang.org/cmd/gofmt/][gofmt]]. We never argued over where to put a curly-brace, tabs vs. spaces, or if we should align assignments. We simply agreed that the buck stopped at the default output from gofmt.
+
+Deploying Doozer was satisfyingly simple. Go builds statically linked binaries which means Doozer has no external dependencies; it's a single file that can be copied to any machine and immediately launched to join a cluster of running Doozers.
+
+Finally, Go's maniacal focus on simplicity and orthogonality aligns with our view of software engineering. Like the Go team, we are pragmatic about what features go into Doozer. We sweat the details, preferring to change an existing feature instead of introducing a new one. In this sense, Go is a perfect match for Doozer.
+
+We already have future projects in mind for Go. Doozer is just the start of much bigger system.
diff --git a/content/go-at-io-frequently-asked-questions.article b/content/go-at-io-frequently-asked-questions.article
new file mode 100644
index 0000000..5a2b7f7
--- /dev/null
+++ b/content/go-at-io-frequently-asked-questions.article
@@ -0,0 +1,32 @@
+Go at I/O: Frequently Asked Questions
+27 May 2010
+
+Andrew Gerrand
+
+* Introduction
+
+Among the high-profile product launches at Google I/O last week, our small team gave presentations to packed rooms and met many present and future Go programmers. It was especially gratifying to meet with so many people who, after learning a bit about Go, were excited by the potential benefits (both immediate and long-term) they could gain from using it.
+
+We were asked a lot of good questions during I/O, and in this post I'd like to recap and expand upon some of them.
+
+How suitable is Go for production systems?
+Go is ready and stable now. We are pleased to report that Google is using Go for some production systems, and they are performing well. Of course there is still room for improvement - that's why we're continuing to work on the language, libraries, tools, and runtime.
+
+Do you have plans to implement generics?
+Many proposals for generics-like features have been mooted both publicly and internally, but as yet we haven't found a proposal that is consistent with the rest of the language. We think that one of Go's key strengths is its simplicity, so we are wary of introducing new features that might make the language more difficult to understand. Additionally, the more Go code we write (and thus the better we learn how to write Go code ourselves), the less we feel the need for such a language feature.
+
+Do you have any plans to support GPU programming?
+We don't have any immediate plans to do this, but as Go is architecture-agnostic it's quite possible. The ability to launch a goroutine that runs on a different processor architecture, and to use channels to communicate between goroutines running on separate architectures, seem like good ideas.
+
+Are there plans to support Go under App Engine?
+Both the Go and App Engine teams would like to see this happen. As always, it is a question of resources and priorities as to if and when it will become a reality.
+
+Are there plans to support Go under Android?
+Both Go compilers support ARM code generation, so it is possible. While we think Go would be a great language for writing mobile applications, Android support is not something that's being actively worked on.
+
+What can I use Go for?
+Go was designed with systems programming in mind. Servers, clients, databases, caches, balancers, distributors - these are applications Go is obviously useful for, and this is how we have begun to use it within Google. However, since Go's open-source release, the community has found a diverse range of applications for the language. From web apps to games to graphics tools, Go promises to shine as a general-purpose programming language. The potential is only limited by library support, which is improving at a tremendous rate. Additionally, educators have expressed interest in using Go to teach programming, citing its succinct syntax and consistency as well-suited to the task.
+
+Thanks to everyone who attended our presentations, or came to talk with us at Office Hours. We hope to see you again at future events.
+
+The video of [[http://code.google.com/events/io/2010/sessions/go-programming.html][Rob and Russ' talk]] will be uploaded to YouTube within the next week, and will then be posted on this blog.
diff --git a/content/go-becomes-more-stable.article b/content/go-becomes-more-stable.article
new file mode 100644
index 0000000..e33d2c5
--- /dev/null
+++ b/content/go-becomes-more-stable.article
@@ -0,0 +1,21 @@
+Go becomes more stable
+16 Mar 2011
+Tags: release
+
+Andrew Gerrand
+
+* Introduction
+
+The Go project is moving fast. As we learn more about Go we are compelled to change our tools, libraries, and occasionally even the language itself. We permit backward-incompatible changes so that we can learn from, rather than immortalize, our mistakes. We believe flexibility at this stage of Go’s development is essential to the project’s development and, ultimately, its longevity.
+
+Since Go's launch we have been making releases approximately once a week. Accompanying each release are [[http://golang.org/doc/devel/release.html][notes describing what changed]], with any backwards-incompatible changes signposted. Questions I hear often are "Is Go stable? How can I be sure that I won’t have to update my Go code every week?" The answer to those questions are now "Yes," and "You won't."
+
+With this week’s release we’re introducing a new release tagging scheme. We intend to continue with our weekly releases, but have renamed the existing tags from `release` to `weekly`. The `release` tag will now be applied to one hand-picked stable release each month or two. This more relaxed release schedule should make life easier for the average Go programmer.
+
+Users will still need to update their code periodically (this is the cost of using a young language) but with less frequency. An additional benefit is that by tagging stable releases less often we can put more effort into automating updates. To this end we have introduced gofix, a tool that will help you update your code.
+
+The revision formerly tagged `release.2011-03-07.1` (now `weekly.2011-03-07.1`) has been nominated our first stable release, and has been given the tag `release.r56`. As we tag each stable release we will post an announcement to the new [[http://groups.google.com/group/golang-announce][golang-announce]] mailing list. (Why not [[http://groups.google.com/group/golang-announce/subscribe][subscribe now]]?)
+
+What’s the upshot of all this? You can continue to keep your Go installation updated using `hg`update`release`, but now you should only need to update when we tag a new stable release. If you wish to stay at the leading edge, you should switch to the weekly tag with `hg`update`weekly`.
+
+Happy coding!
diff --git a/content/go-concurrency-patterns-timing-out-and.article b/content/go-concurrency-patterns-timing-out-and.article
new file mode 100644
index 0000000..16949fe
--- /dev/null
+++ b/content/go-concurrency-patterns-timing-out-and.article
@@ -0,0 +1,51 @@
+Go Concurrency Patterns: Timing out, moving on
+23 Sep 2010
+Tags: channel, concurrency, goroutine
+
+Andrew Gerrand
+
+* Introduction
+
+Concurrent programming has its own idioms. A good example is timeouts. Although Go's channels do not support them directly, they are easy to implement. Say we want to receive from the channel `ch`, but want to wait at most one second for the value to arrive. We would start by creating a signalling channel and launching a goroutine that sleeps before sending on the channel:
+
+ timeout := make(chan bool, 1)
+ go func() {
+ time.Sleep(1 * time.Second)
+ timeout <- true
+ }()
+
+We can then use a `select` statement to receive from either `ch` or `timeout`. If nothing arrives on `ch` after one second, the timeout case is selected and the attempt to read from ch is abandoned.
+
+ select {
+ case <-ch:
+ // a read from ch has occurred
+ case <-timeout:
+ // the read from ch has timed out
+ }
+
+The `timeout` channel is buffered with space for 1 value, allowing the timeout goroutine to send to the channel and then exit. The goroutine doesn't know (or care) whether the value is received. This means the goroutine won't hang around forever if the `ch` receive happens before the timeout is reached. The `timeout` channel will eventually be deallocated by the garbage collector.
+
+(In this example we used `time.Sleep` to demonstrate the mechanics of goroutines and channels. In real programs you should use ` [[http://golang.org/pkg/time/#After][time.After]]`, a function that returns a channel and sends on that channel after the specified duration.)
+
+Let's look at another variation of this pattern. In this example we have a program that reads from multiple replicated databases simultaneously. The program needs only one of the answers, and it should accept the answer that arrives first.
+
+The function `Query` takes a slice of database connections and a `query` string. It queries each of the databases in parallel and returns the first response it receives:
+
+ func Query(conns []Conn, query string) Result {
+ ch := make(chan Result, 1)
+ for _, conn := range conns {
+ go func(c Conn) {
+ select {
+ case ch <- c.DoQuery(query):
+ default:
+ }
+ }(conn)
+ }
+ return <-ch
+ }
+
+In this example, the closure does a non-blocking send, which it achieves by using the send operation in `select` statement with a `default` case. If the send cannot go through immediately the default case will be selected. Making the send non-blocking guarantees that none of the goroutines launched in the loop will hang around. However, if the result arrives before the main function has made it to the receive, the send could fail since no one is ready.
+
+This problem is a textbook example of what is known as a [[https://en.wikipedia.org/wiki/Race_condition][race condition]], but the fix is trivial. We just make sure to buffer the channel `ch` (by adding the buffer length as the second argument to [[http://golang.org/pkg/builtin/#make][make]]), guaranteeing that the first send has a place to put the value. This ensures the send will always succeed, and the first value to arrive will be retrieved regardless of the order of execution.
+
+These two examples demonstrate the simplicity with which Go can express complex interactions between goroutines.
diff --git a/content/go-fmt-your-code.article b/content/go-fmt-your-code.article
new file mode 100644
index 0000000..b5def3a
--- /dev/null
+++ b/content/go-fmt-your-code.article
@@ -0,0 +1,62 @@
+go fmt your code
+23 Jan 2013
+Tags: gofix, gofmt
+
+Andrew Gerrand
+
+* Introduction
+
+[[http://golang.org/cmd/gofmt/][Gofmt]] is a tool that automatically formats Go source code.
+
+Gofmt'd code is:
+
+- easier to *write*: never worry about minor formatting concerns while hacking away,
+
+- easier to *read*: when all code looks the same you need not mentally convert others' formatting style into something you can understand.
+
+- easier to *maintain*: mechanical changes to the source don't cause unrelated changes to the file's formatting; diffs show only the real changes.
+
+- *uncontroversial*: never have a debate about spacing or brace position ever again!
+
+* Format your code
+
+We recently conducted a survey of Go packages in the wild and found that about 70% of them are formatted according to gofmt's rules. This was more than expected - and thanks to everyone who uses gofmt - but it would be great to close the gap.
+
+To format your code, you can use the gofmt tool directly:
+
+ gofmt -w yourcode.go
+
+Or you can use the "[[http://golang.org/cmd/go/#hdr-Run_gofmt_on_package_sources][go fmt]]" command:
+
+ go fmt path/to/your/package
+
+To help keep your code in the canonical style, the Go repository contains hooks for editors and version control systems that make it easy to run gofmt on your code.
+
+For Vim users, the [[http://tip.golang.org/misc/vim/readme.txt][Vim plugin for Go]] includes the [[http://tip.golang.org/misc/vim/ftplugin/go/fmt.vim][:Fmt command]] that runs gofmt on the current buffer.
+
+For emacs users, [[http://tip.golang.org/misc/emacs/go-mode.el][go-mode.el]] provides a gofmt-before-save hook that can be installed by adding this line to your .emacs file:
+
+ (add-hook 'before-save-hook #'gofmt-before-save)
+
+For Eclipse or Sublime Text users, the [[http://code.google.com/p/goclipse/][GoClipse]] and [[https://github.com/DisposaBoy/GoSublime][GoSublime]] projects add a gofmt facility to those editors.
+
+And for Git aficionados, the [[http://tip.golang.org/misc/git/pre-commit][misc/git/pre-commit script]] is a pre-commit hook that prevents incorrectly-formatted Go code from being committed. If you use Mercurial, the [[https://bitbucket.org/fhs/hgstyle/overview][hgstyle plugin]] provides a gofmt pre-commit hook.
+
+* Mechanical source transformation
+
+One of the greatest virtues of machine-formatted code is that it can be transformed mechanically without generating unrelated formatting noise in the diffs. Mechanical transformation is invaluable when working with large code bases, as it is both more comprehensive and less error prone than making wide-sweeping changes by hand. Indeed, when working at scale (like we do at Google) it often isn't practical to make these kinds of changes manually.
+
+The easiest way to mechanically manipulate Go code is with gofmt's -r flag. The flag specifies a rewrite rule of the form
+
+ pattern -> replacement
+
+where both pattern and replacement are valid Go expressions. In the pattern, single-character lowercase identifiers serve as wildcards matching arbitrary sub-expressions, and those expressions are substituted for the same identifiers in the replacement.
+
+For example, this[[https://code.google.com/p/go/source/detail?r=ae4e014e0b77][ recent change]] to the Go core rewrote some uses of [[http://golang.org/pkg/bytes/#Compare][bytes.Compare]] to use the more efficient [[http://golang.org/pkg/bytes/#Equal][bytes.Equal]]. The contributor made the change using just two gofmt invocations:
+
+ gofmt -r 'bytes.Compare(a, b) == 0 -> bytes.Equal(a, b)'
+ gofmt -r 'bytes.Compare(a, b) != 0 -> !bytes.Equal(a, b)'
+
+Gofmt also enables [[http://golang.org/cmd/fix/][gofix]], which can make arbitrarily complex source transformations. Gofix was an invaluable tool during the early days when we regularly made breaking changes to the language and libraries. For example, before Go 1 the built-in error interface didn't exist and the convention was to use the os.Error type. When we [[http://golang.org/doc/go1.html#errors][introduced error]], we provided a gofix module that rewrote all references to os.Error and its associated helper functions to use error and the new [[http://golang.org/pkg/errors/][errors package]]. It would have been daunting to attempt by hand, but with the code in a standard format it was relatively easy to prepare, execute, and review this change which touched almost all Go code in existence.
+
+For more about gofix, see [[http://blog.golang.org/2011/04/introducing-gofix.html][this article]].
diff --git a/content/go-for-app-engine-is-now-generally.article b/content/go-for-app-engine-is-now-generally.article
new file mode 100644
index 0000000..21d1c59
--- /dev/null
+++ b/content/go-for-app-engine-is-now-generally.article
@@ -0,0 +1,19 @@
+Go for App Engine is now generally available
+21 Jul 2011
+Tags: appengine, release
+
+Andrew Gerrand
+
+* Introduction
+
+The Go and App Engine teams are excited to announce that the Go runtime for App Engine is now generally available. This means you can take that Go app you've been working on (or meaning to work on) and deploy it to App Engine right now with the new [[http://code.google.com/appengine/downloads.html][1.5.2 SDK]].
+
+Since we announced the Go runtime at Google I/O we have continued to [[http://code.google.com/p/googleappengine/wiki/SdkForGoReleaseNotes][improve and extend]] Go support for the App Engine APIs and have added the Channels API. The Go Datastore API now supports transactions and ancestor queries, too. See the [[https://code.google.com/appengine/docs/go/][Go App Engine documentation]] for all the details.
+
+For those who have been using the Go SDK already, please note that the 1.5.2 release introduces `api_version` 2. This is because the new SDK is based on Go `release.r58.1` (the current stable version of Go) and is not backwards compatible with the previous release. Existing apps may require changes as per the [[http://golang.org/doc/devel/release.html#r58][r58 release notes]]. Once you've updated your code, you should redeploy your app with the line `api_version:`2` in its `app.yaml` file. Apps written against `api_version` 1 will stop working after the 18th of August.
+
+Finally, we owe a huge thanks to our trusted testers and their many bug reports. Their help was invaluable in reaching this important milestone.
+
+_The_fastest_way_to_get_started_with_Go_on_App_Engine_is_with_the_ [[http://code.google.com/appengine/docs/go/gettingstarted/][_Getting_Started_guide_]].
+
+_Note_that_the_Go_runtime_is_still_considered_experimental;_it_is_not_as_well-supported_as_the_Python_and_Java_runtimes._
diff --git a/content/go-image-package.article b/content/go-image-package.article
new file mode 100644
index 0000000..c10875e
--- /dev/null
+++ b/content/go-image-package.article
@@ -0,0 +1,194 @@
+The Go image package
+21 Sep 2011
+Tags: image, libraries
+
+Nigel Tao
+
+* Introduction
+
+The [[http://golang.org/pkg/image/][image]] and [[http://golang.org/pkg/image/color/][image/color]] packages define a number of types: `color.Color` and `color.Model` describe colors, `image.Point` and `image.Rectangle` describe basic 2-D geometry, and `image.Image` brings the two concepts together to represent a rectangular grid of colors. A [[http://golang.org/doc/articles/image_draw.html][separate article]] covers image composition with the [[http://golang.org/pkg/image/draw/][image/draw]] package.
+
+* Colors and Color Models
+
+[[http://golang.org/pkg/image/color/#Color][Color]] is an interface that defines the minimal method set of any type that can be considered a color: one that can be converted to red, green, blue and alpha values. The conversion may be lossy, such as converting from CMYK or YCbCr color spaces.
+
+ type Color interface {
+ // RGBA returns the alpha-premultiplied red, green, blue and alpha values
+ // for the color. Each value ranges within [0, 0xFFFF], but is represented
+ // by a uint32 so that multiplying by a blend factor up to 0xFFFF will not
+ // overflow.
+ RGBA() (r, g, b, a uint32)
+ }
+
+There are three important subtleties about the return values. First, the red, green and blue are alpha-premultiplied: a fully saturated red that is also 25% transparent is represented by RGBA returning a 75% r. Second, the channels have a 16-bit effective range: 100% red is represented by RGBA returning an r of 65535, not 255, so that converting from CMYK or YCbCr is not as lossy. Third, the type returned is `uint32`, even though the maximum value is 65535, to guarantee that multiplying two values together won't overflow. Such multiplications occur when blending two colors according to an alpha mask from a third color, in the style of [[https://en.wikipedia.org/wiki/Alpha_compositing][Porter and Duff's]] classic algebra:
+
+ dstr, dstg, dstb, dsta := dst.RGBA()
+ srcr, srcg, srcb, srca := src.RGBA()
+ _, _, _, m := mask.RGBA()
+ const M = 1<<16 - 1
+ // The resultant red value is a blend of dstr and srcr, and ranges in [0, M].
+ // The calculation for green, blue and alpha is similar.
+ dstr = (dstr*(M-m) + srcr*m) / M
+
+The last line of that code snippet would have been more complicated if we worked with non-alpha-premultiplied colors, which is why `Color` uses alpha-premultiplied values.
+
+The image/color package also defines a number of concrete types that implement the `Color` interface. For example, [[http://golang.org/pkg/image/color/#RGBA][`RGBA`]] is a struct that represents the classic "8 bits per channel" color.
+
+ type RGBA struct {
+ R, G, B, A uint8
+ }
+
+Note that the `R` field of an `RGBA` is an 8-bit alpha-premultiplied color in the range [0, 255]. `RGBA` satisfies the `Color` interface by multiplying that value by 0x101 to generate a 16-bit alpha-premultiplied color in the range [0, 65535]. Similarly, the [[http://golang.org/pkg/image/color/#NRGBA][`NRGBA`]] struct type represents an 8-bit non-alpha-premultiplied color, as used by the PNG image format. When manipulating an `NRGBA`'s fields directly, the values are non-alpha-premultiplied, but when calling the `RGBA` method, the return values are alpha-premultiplied.
+
+A [[http://golang.org/pkg/image/color/#Model][`Model`]] is simply something that can convert `Color`s to other `Color`s, possibly lossily. For example, the `GrayModel` can convert any `Color` to a desaturated [[http://golang.org/pkg/image/color/#Gray][`Gray`]]. A `Palette` can convert any `Color` to one from a limited palette.
+
+ type Model interface {
+ Convert(c Color) Color
+ }
+
+ type Palette []Color
+
+* Points and Rectangles
+
+A [[http://golang.org/pkg/image/#Point][`Point`]] is an (x, y) co-ordinate on the integer grid, with axes increasing right and down. It is neither a pixel nor a grid square. A `Point` has no intrinsic width, height or color, but the visualizations below use a small colored square.
+
+ type Point struct {
+ X, Y int
+ }
+
+.image go-image-package_image-package-01.png
+
+ p := image.Point{2, 1}
+
+A [[http://golang.org/pkg/image/#Rectangle][`Rectangle`]] is an axis-aligned rectangle on the integer grid, defined by its top-left and bottom-right `Point`. A `Rectangle` also has no intrinsic color, but the visualizations below outline rectangles with a thin colored line, and call out their `Min` and `Max` `Point`s.
+
+ type Rectangle struct {
+ Min, Max Point
+ }
+
+For convenience, `image.Rect(x0,`y0,`x1,`y1)` is equivalent to `image.Rectangle{image.Point{x0,`y0},`image.Point{x1,`y1}}`, but is much easier to type.
+
+A `Rectangle` is inclusive at the top-left and exclusive at the bottom-right. For a `Point`p` and a `Rectangle`r`, `p.In(r)` if and only if `r.Min.X`<=`p.X`&&`p.X`<`r.Max.X`, and similarly for `Y`. This is analagous to how a slice `s[i0:i1]` is inclusive at the low end and exclusive at the high end. (Unlike arrays and slices, a `Rectangle` often has a non-zero origin.)
+
+.image go-image-package_image-package-02.png
+
+ r := image.Rect(2, 1, 5, 5)
+ // Dx and Dy return a rectangle's width and height.
+ fmt.Println(r.Dx(), r.Dy(), image.Pt(0, 0).In(r)) // prints 3 4 false
+
+Adding a `Point` to a `Rectangle` translates the `Rectangle`. Points and Rectangles are not restricted to be in the bottom-right quadrant.
+
+.image go-image-package_image-package-03.png
+
+ r := image.Rect(2, 1, 5, 5).Add(image.Pt(-4, -2))
+ fmt.Println(r.Dx(), r.Dy(), image.Pt(0, 0).In(r)) // prints 3 4 true
+
+Intersecting two Rectangles yields another Rectangle, which may be empty.
+
+.image go-image-package_image-package-04.png
+
+ r := image.Rect(0, 0, 4, 3).Intersect(image.Rect(2, 2, 5, 5))
+ // Size returns a rectangle's width and height, as a Point.
+ fmt.Printf("%#v\n", r.Size()) // prints image.Point{X:2, Y:1}
+
+Points and Rectangles are passed and returned by value. A function that takes a `Rectangle` argument will be as efficient as a function that takes two `Point` arguments, or four `int` arguments.
+
+* Images
+
+An [[http://golang.org/pkg/image/#Image][Image]] maps every grid square in a `Rectangle` to a `Color` from a `Model`. "The pixel at (x, y)" refers to the color of the grid square defined by the points (x, y), (x+1, y), (x+1, y+1) and (x, y+1).
+
+ type Image interface {
+ // ColorModel returns the Image's color model.
+ ColorModel() color.Model
+ // Bounds returns the domain for which At can return non-zero color.
+ // The bounds do not necessarily contain the point (0, 0).
+ Bounds() Rectangle
+ // At returns the color of the pixel at (x, y).
+ // At(Bounds().Min.X, Bounds().Min.Y) returns the upper-left pixel of the grid.
+ // At(Bounds().Max.X-1, Bounds().Max.Y-1) returns the lower-right one.
+ At(x, y int) color.Color
+ }
+
+A common mistake is assuming that an `Image`'s bounds start at (0, 0). For example, an animated GIF contains a sequence of Images, and each `Image` after the first typically only holds pixel data for the area that changed, and that area doesn't necessarily start at (0, 0). The correct way to iterate over an `Image` m's pixels looks like:
+
+ b := m.Bounds()
+ for y := b.Min.Y; y < b.Max.Y; y++ {
+ for x := b.Min.X; y < b.Max.X; x++ {
+ doStuffWith(m.At(x, y))
+ }
+ }
+
+`Image` implementations do not have to be based on an in-memory slice of pixel data. For example, a [[http://golang.org/pkg/image/#Uniform][`Uniform`]] is an `Image` of enormous bounds and uniform color, whose in-memory representation is simply that color.
+
+ type Uniform struct {
+ C color.Color
+ }
+
+Typically, though, programs will want an image based on a slice. Struct types like [[http://golang.org/pkg/image/#RGBA][`RGBA`]] and [[http://golang.org/pkg/image/#Gray][`Gray`]] (which other packages refer to as `image.RGBA` and `image.Gray`) hold slices of pixel data and implement the `Image` interface.
+
+ type RGBA struct {
+ // Pix holds the image's pixels, in R, G, B, A order. The pixel at
+ // (x, y) starts at Pix[(y-Rect.Min.Y)*Stride + (x-Rect.Min.X)*4].
+ Pix []uint8
+ // Stride is the Pix stride (in bytes) between vertically adjacent pixels.
+ Stride int
+ // Rect is the image's bounds.
+ Rect Rectangle
+ }
+
+These types also provide a `Set(x,`y`int,`c`color.Color)` method that allows modifying the image one pixel at a time.
+
+ m := image.NewRGBA(image.Rect(0, 0, 640, 480))
+ m.Set(5, 5, color.RGBA{255, 0, 0, 255})
+
+If you're reading or writing a lot of pixel data, it can be more efficient, but more complicated, to access these struct type's `Pix` field directly.
+
+The slice-based `Image` implementations also provide a `SubImage` method, which returns an `Image` backed by the same array. Modifying the pixels of a sub-image will affect the pixels of the original image, analagous to how modifying the contents of a sub-slice `s[i0:i1]` will affect the contents of the original slice `s`.
+
+.image go-image-package_image-package-05.png
+
+ m0 := image.NewRGBA(image.Rect(0, 0, 8, 5))
+ m1 := m0.SubImage(image.Rect(1, 2, 5, 5)).(*image.RGBA)
+ fmt.Println(m0.Bounds().Dx(), m1.Bounds().Dx()) // prints 8, 4
+ fmt.Println(m0.Stride == m1.Stride) // prints true
+
+For low-level code that works on an image's `Pix` field, be aware that ranging over `Pix` can affect pixels outside an image's bounds. In the example above, the pixels covered by `m1.Pix` are shaded in blue. Higher-level code, such as the `At` and `Set` methods or the [[http://golang.org/pkg/image/draw/][image/draw package]], will clip their operations to the image's bounds.
+
+* Image Formats
+
+The standard package library supports a number of common image formats, such as GIF, JPEG and PNG. If you know the format of a source image file, you can decode from an [[http://golang.org/pkg/io/#Reader][`io.Reader`]] directly.
+
+ import (
+ "image/jpeg"
+ "image/png"
+ "io"
+ )
+
+ // convertJPEGToPNG converts from JPEG to PNG.
+ func convertJPEGToPNG(w io.Writer, r io.Reader) error {
+ img, err := jpeg.Decode(r)
+ if err != nil {
+ return err
+ }
+ return png.Encode(w, img)
+ }
+
+If you have image data of unknown format, the [[http://golang.org/pkg/image/#Decode][`image.Decode`]] function can detect the format. The set of recognized formats is constructed at run time and is not limited to those in the standard package library. An image format package typically registers its format in an init function, and the main package will "underscore import" such a package solely for the side effect of format registration.
+
+ import (
+ "image"
+ "image/png"
+ "io"
+
+ _ "code.google.com/p/vp8-go/webp"
+ _ "image/jpeg"
+ )
+
+ // convertToPNG converts from any recognized format to PNG.
+ func convertToPNG(w io.Writer, r io.Reader) error {
+ img, _, err := image.Decode(r)
+ if err != nil {
+ return err
+ }
+ return png.Encode(w, img)
+ }
diff --git a/content/go-image-package_image-package-01.png b/content/go-image-package_image-package-01.png
new file mode 100644
index 0000000..aad9b12
--- /dev/null
+++ b/content/go-image-package_image-package-01.png
Binary files differ
diff --git a/content/go-image-package_image-package-02.png b/content/go-image-package_image-package-02.png
new file mode 100644
index 0000000..3dd4692
--- /dev/null
+++ b/content/go-image-package_image-package-02.png
Binary files differ
diff --git a/content/go-image-package_image-package-03.png b/content/go-image-package_image-package-03.png
new file mode 100644
index 0000000..5bc0bf7
--- /dev/null
+++ b/content/go-image-package_image-package-03.png
Binary files differ
diff --git a/content/go-image-package_image-package-04.png b/content/go-image-package_image-package-04.png
new file mode 100644
index 0000000..393dc12
--- /dev/null
+++ b/content/go-image-package_image-package-04.png
Binary files differ
diff --git a/content/go-image-package_image-package-05.png b/content/go-image-package_image-package-05.png
new file mode 100644
index 0000000..54c47b6
--- /dev/null
+++ b/content/go-image-package_image-package-05.png
Binary files differ
diff --git a/content/go-imagedraw-package.article b/content/go-imagedraw-package.article
new file mode 100644
index 0000000..e89ec6e
--- /dev/null
+++ b/content/go-imagedraw-package.article
@@ -0,0 +1,147 @@
+The Go image/draw package
+29 Sep 2011
+Tags: draw, image, libraries
+
+Nigel Tao
+
+* Introduction
+
+[[http://golang.org/pkg/image/draw/][Package image/draw]] defines only one operation: drawing a source image onto a destination image, through an optional mask image. This one operation is surprisingly versatile and can perform a number of common image manipulation tasks elegantly and efficiently.
+
+Composition is performed pixel by pixel in the style of the Plan 9 graphics library and the X Render extension. The model is based on the classic "Compositing Digital Images" paper by Porter and Duff, with an additional mask parameter: `dst`=`(src`IN`mask)`OP`dst`. For a fully opaque mask, this reduces to the original Porter-Duff formula: `dst`=`src`OP`dst`. In Go, a nil mask image is equivalent to an infinitely sized, fully opaque mask image.
+
+The Porter-Duff paper presented [[http://www.w3.org/TR/SVGCompositing/examples/compop-porterduff-examples.png][12 different composition operators]], but with an explicit mask, only 2 of these are needed in practice: source-over-destination and source. In Go, these operators are represented by the `Over` and `Src` constants. The `Over` operator performs the natural layering of a source image over a destination image: the change to the destination image is smaller where the source (after masking) is more transparent (that is, has lower alpha). The `Src` operator merely copies the source (after masking) with no regard for the destination image's original content. For fully opaque source and mask images, the two operators produce the same output, but the `Src` operator is usually faster.
+
+* Geometric Alignment
+
+Composition requires associating destination pixels with source and mask pixels. Obviously, this requires destination, source and mask images, and a composition operator, but it also requires specifying what rectangle of each image to use. Not every drawing should write to the entire destination: when updating an animating image, it is more efficient to only draw the parts of the image that have changed. Not every drawing should read from the entire source: when using a sprite that combines many small images into one large one, only a part of the image is needed. Not every drawing should read from the entire mask: a mask image that collects a font's glyphs is similar to a sprite. Thus, drawing also needs to know three rectangles, one for each image. Since each rectangle has the same width and height, it suffices to pass a destination rectangle `r` and two points `sp` and `mp`: the source rectangle is equal to `r` translated so that `r.Min` in the destination image aligns with `sp` in the source image, and similarly for `mp`. The effective rectangle is also clipped to each image's bounds in their respective co-ordinate space.
+
+.image go-imagedraw-package_20.png
+
+The [[http://golang.org/pkg/image/draw/#DrawMask][`DrawMask`]] function takes seven arguments, but an explicit mask and mask-point are usually unnecessary, so the [[http://golang.org/pkg/image/draw/#Draw][`Draw`]] function takes five:
+
+ // Draw calls DrawMask with a nil mask.
+ func Draw(dst Image, r image.Rectangle, src image.Image, sp image.Point, op Op)
+ func DrawMask(dst Image, r image.Rectangle, src image.Image, sp image.Point,
+ mask image.Image, mp image.Point, op Op)
+
+The destination image must be mutable, so the image/draw package defines a [[http://golang.org/pkg/image/draw/#Image][`draw.Image`]] interface which has a `Set` method.
+
+ type Image interface {
+ image.Image
+ Set(x, y int, c color.Color)
+ }
+
+
+* Filling a Rectangle
+
+To fill a rectangle with a solid color, use an `image.Uniform` source. The `ColorImage` type re-interprets a `Color` as a practically infinite-sized `Image` of that color. For those familiar with the design of Plan 9's draw library, there is no need for an explicit "repeat bit" in Go's slice-based image types; the concept is subsumed by `Uniform`.
+
+ // image.ZP is the zero point -- the origin.
+ draw.Draw(dst, r, &image.Uniform{c}, image.ZP, draw.Src)
+
+To initialize a new image to all-blue:
+
+ m := image.NewRGBA(image.Rect(0, 0, 640, 480))
+ blue := color.RGBA{0, 0, 255, 255}
+ draw.Draw(m, m.Bounds(), &image.Uniform{blue}, image.ZP, draw.Src)
+
+To reset an image to transparent (or black, if the destination image's color model cannot represent transparency), use `image.Transparent`, which is an `image.Uniform`:
+
+ draw.Draw(m, m.Bounds(), image.Transparent, image.ZP, draw.Src)
+
+
+.image go-imagedraw-package_2a.png
+
+
+* Copying an Image
+
+To copy from a rectangle `sr` in the source image to a rectangle starting at a point `dp` in the destination, convert the source rectangle into the destination image's co-ordinate space:
+
+ r := image.Rectangle{dp, dp.Add(sr.Size())}
+ draw.Draw(dst, r, src, sr.Min, draw.Src)
+
+
+Alternatively:
+
+ r := sr.Sub(sr.Min).Add(dp)
+ draw.Draw(dst, r, src, sr.Min, draw.Src)
+
+
+To copy the entire source image, use `sr`=`src.Bounds()`.
+
+
+.image go-imagedraw-package_2b.png
+
+
+* Scrolling an Image
+
+Scrolling an image is just copying an image to itself, with different destination and source rectangles. Overlapping destination and source images are perfectly valid, just as Go's built-in copy function can handle overlapping destination and source slices. To scroll an image m by 20 pixels:
+
+ b := m.Bounds()
+ p := image.Pt(0, 20)
+ // Note that even though the second argument is b,
+ // the effective rectangle is smaller due to clipping.
+ draw.Draw(m, b, m, b.Min.Add(p), draw.Src)
+ dirtyRect := b.Intersect(image.Rect(b.Min.X, b.Max.Y-20, b.Max.X, b.Max.Y))
+
+
+.image go-imagedraw-package_2c.png
+
+
+* Converting an Image to RGBA
+
+The result of decoding an image format might not be an `image.RGBA`: decoding a GIF results in an `image.Paletted`, decoding a JPEG results in a `ycbcr.YCbCr`, and the result of decoding a PNG depends on the image data. To convert any image to an `image.RGBA`:
+
+ b := src.Bounds()
+ m := image.NewRGBA(image.Rect(0, 0, b.Dx(), b.Dy()))
+ draw.Draw(m, m.Bounds(), src, b.Min, draw.Src)
+
+
+.image go-imagedraw-package_2d.png
+
+* Drawing Through a Mask
+
+To draw an image through a circular mask with center `p` and radius `r`:
+
+ type circle struct {
+ p image.Point
+ r int
+ }
+
+ func (c *circle) ColorModel() color.Model {
+ return color.AlphaModel
+ }
+
+ func (c *circle) Bounds() image.Rectangle {
+ return image.Rect(c.p.X-c.r, c.p.Y-c.r, c.p.X+c.r, c.p.Y+c.r)
+ }
+
+ func (c *circle) At(x, y int) color.Color {
+ xx, yy, rr := float64(x-c.p.X)+0.5, float64(y-c.p.Y)+0.5, float64(c.r)
+ if xx*xx+yy*yy < rr*rr {
+ return color.Alpha{255}
+ }
+ return color.Alpha{0}
+ }
+
+ draw.DrawMask(dst, dst.Bounds(), src, image.ZP, &circle{p, r}, image.ZP, draw.Over)
+
+
+.image go-imagedraw-package_2e.png
+
+* Drawing Font Glyphs
+
+To draw a font glyph in blue starting from a point `p`, draw with an `image.ColorImage` source and an `image.Alpha`mask`. For simplicity, we aren't performing any sub-pixel positioning or rendering, or correcting for a font's height above a baseline.
+
+ src := &image.Uniform{color.RGBA{0, 0, 255, 255}}
+ mask := theGlyphImageForAFont()
+ mr := theBoundsFor(glyphIndex)
+ draw.DrawMask(dst, mr.Sub(mr.Min).Add(p), src, image.ZP, mask, mr.Min, draw.Over)
+
+.image go-imagedraw-package_2f.png
+
+
+* Performance
+
+The image/draw package implementation demonstrates how to provide an image manipulation function that is both general purpose, yet efficient for common cases. The `DrawMask` function takes arguments of interface types, but immediately makes type assertions that its arguments are of specific struct types, corresponding to common operations like drawing one `image.RGBA` image onto another, or drawing an `image.Alpha` mask (such as a font glyph) onto an `image.RGBA` image. If a type assertion succeeds, that type information is used to run a specialized implementation of the general algorithm. If the assertions fail, the fallback code path uses the generic `At` and `Set` methods. The fast-paths are purely a performance optimization; the resultant destination image is the same either way. In practice, only a small number of special cases are necessary to support typical applications.
diff --git a/content/go-imagedraw-package_20.png b/content/go-imagedraw-package_20.png
new file mode 100644
index 0000000..063e430
--- /dev/null
+++ b/content/go-imagedraw-package_20.png
Binary files differ
diff --git a/content/go-imagedraw-package_2a.png b/content/go-imagedraw-package_2a.png
new file mode 100644
index 0000000..3f1c0af
--- /dev/null
+++ b/content/go-imagedraw-package_2a.png
Binary files differ
diff --git a/content/go-imagedraw-package_2b.png b/content/go-imagedraw-package_2b.png
new file mode 100644
index 0000000..32b2470
--- /dev/null
+++ b/content/go-imagedraw-package_2b.png
Binary files differ
diff --git a/content/go-imagedraw-package_2c.png b/content/go-imagedraw-package_2c.png
new file mode 100644
index 0000000..f9abce5
--- /dev/null
+++ b/content/go-imagedraw-package_2c.png
Binary files differ
diff --git a/content/go-imagedraw-package_2d.png b/content/go-imagedraw-package_2d.png
new file mode 100644
index 0000000..ed0a9f9
--- /dev/null
+++ b/content/go-imagedraw-package_2d.png
Binary files differ
diff --git a/content/go-imagedraw-package_2e.png b/content/go-imagedraw-package_2e.png
new file mode 100644
index 0000000..483b208
--- /dev/null
+++ b/content/go-imagedraw-package_2e.png
Binary files differ
diff --git a/content/go-imagedraw-package_2f.png b/content/go-imagedraw-package_2f.png
new file mode 100644
index 0000000..3dce02d
--- /dev/null
+++ b/content/go-imagedraw-package_2f.png
Binary files differ
diff --git a/content/go-maps-in-action.article b/content/go-maps-in-action.article
new file mode 100644
index 0000000..0066ed6
--- /dev/null
+++ b/content/go-maps-in-action.article
@@ -0,0 +1,211 @@
+Go maps in action
+6 Feb 2013
+
+Andrew Gerrand
+
+* Introduction
+
+One of the most useful data structures in computer science is the hash table. Many hash table implementations exist with varying properties, but in general they offer fast lookups, adds, and deletes. Go provides a built-in map type that implements a hash table.
+
+* Declaration and initialization
+
+A Go map type looks like this:
+
+ map[KeyType]ValueType
+
+where `KeyType` may be any type that is [[http://golang.org/ref/spec#Comparison_operators][comparable]] (more on this later), and `ValueType` may be any type at all, including another map!
+
+This variable `m` is a map of string keys to int values:
+
+ var m map[string]int
+
+Map types are reference types, like pointers or slices, and so the value of `m` above is `nil`; it doesn't point to an initialized map. A nil map behaves like an empty map when reading, but attempts to write to a nil map will cause a runtime panic; don't do that. To initialize a map, use the built in `make` function:
+
+ m = make(map[string]int)
+
+The `make` function allocates and initializes a hash map data structure and returns a map value that points to it. The specifics of that data structure are an implementation detail of the runtime and are not specified by the language itself. In this article we will focus on the _use_ of maps, not their implementation.
+
+* Working with maps
+
+Go provides a familiar syntax for working with maps. This statement sets the key `"route"` to the value `66`:
+
+ m["route"] = 66
+
+This statement retrieves the value stored under the key `"route"` and assigns it to a new variable i:
+
+ i := m["route"]
+
+If the requested key doesn't exist, we get the value type's _zero_value_. In this case the value type is `int`, so the zero value is `0`:
+
+ j := m["root"]
+ // j == 0
+
+The built in `len` function returns on the number of items in a map:
+
+ n := len(m)
+
+The built in `delete` function removes an entry from the map:
+
+ delete(m, "route")
+
+The `delete` function doesn't return anything, and will do nothing if the specified key doesn't exist.
+
+A two-value assignment tests for the existence of a key:
+
+ i, ok := m["route"]
+
+In this statement, the first value (`i`) is assigned the value stored under the key `"route"`. If that key doesn't exist, `i` is the value type's zero value (`0`). The second value (`ok`) is a `bool` that is `true` if the key exists in the map, and `false` if not.
+
+To test for a key without retrieving the value, use an underscore in place of the first value:
+
+ _, ok := m["route"]
+
+To iterate over the contents of a map, use the `range` keyword:
+
+ for key, value := range m {
+ fmt.Println("Key:", key, "Value:", value)
+ }
+
+To initialize a map with some data, use a map literal:
+
+ commits := map[string]int{
+ "rsc": 3711,
+ "r": 2138,
+ "gri": 1908,
+ "adg": 912,
+ }
+
+The same syntax may be used to initialize an empty map, which is functionally identical to using the `make` function:
+
+ m = map[string]int{}
+
+* Exploiting zero values
+
+It can be convenient that a map retrieval yields a zero value when the key is not present.
+
+For instance, a map of boolean values can be used as a set-like data structure (recall that the zero value for the boolean type is false). This example traverses a linked list of `Nodes` and prints their values. It uses a map of `Node` pointers to detect cycles in the list.
+
+ type Node struct {
+ Next *Node
+ Value interface{}
+ }
+ var first *Node
+
+ *visited*:=*make(map[*Node]bool)*
+ for n := first; n != nil; n = n.Next {
+ if *visited[n]* {
+ fmt.Println("cycle detected")
+ break
+ }
+ *visited[n]*=*true*
+ fmt.Println(n.Value)
+ }
+
+The expression `visited[n]` is `true` if `n` has been visited, or `false` if `n` is not present. There's no need to use the two-value form to test for the presence of `n` in the map; the zero value default does it for us.
+
+Another instance of helpful zero values is a map of slices. Appending to a nil slice just allocates a new slice, so it's a one-liner to append a value to a map of slices; there's no need to check if the key exists. In the following example, the slice people is populated with `Person` values. Each `Person` has a `Name` and a slice of Likes. The example creates a map to associate each like with a slice of people that like it.
+
+ type Person struct {
+ Name string
+ Likes []string
+ }
+ var people []*Person
+
+ *likes*:=*make(map[string][]*Person)*
+ for _, p := range people {
+ for _, l := range p.Likes {
+ *likes[l]*=*append(likes[l],*p)*
+ }
+ }
+
+To print a list of people who like cheese:
+
+ for _, p := range likes["cheese"] {
+ fmt.Println(p.Name, "likes cheese.")
+ }
+
+To print the number of people who like bacon:
+
+ fmt.Println("People that like bacon:", len(likes["bacon"]))
+
+Note that since both range and len treat a nil slice as a zero-length slice, these last two examples will work even if nobody likes cheese or bacon (however unlikely that may be).
+
+* Key types
+
+As mentioned earlier, map keys may be of any type that is comparable. The [[http://golang.org/ref/spec#Comparison_operators][language spec]] defines this precisely, but in short, comparable types are boolean, numeric, string, pointer, channel, and interface types, and structs or arrays that contain only those types. Notably absent from the list are slices, maps, and functions; these types cannot be compared using `==`, and may not be used as map keys.
+
+It's obvious that strings, ints, and other basic types should be available as map keys, but perhaps unexpected are struct keys. Struct can be used to key data by multiple dimensions. For example, this map of maps could be used to tally web page hits by country:
+
+ hits := make(map[string]map[string]int)
+
+This is map of string to (map of `string` to `int`). Each key of the outer map is the path to a web page with its own inner map. Each inner map key is a two-letter country code. This expression retrieves the number of times an Australian has loaded the documentation page:
+
+ n := hits["/doc/"]["au"]
+
+Unfortunately, this approach becomes unwieldy when adding data, as for any given outer key you must check if the inner map exists, and create it if needed:
+
+ func add(m map[string]map[string]int, path, country string) {
+ mm, ok := m[path]
+ if !ok {
+ mm = make(map[string]int)
+ m[path] = mm
+ }
+ mm[country]++
+ }
+ add(hits, "/doc/", "au")
+
+On the other hand, a design that uses a single map with a struct key does away with all that complexity:
+
+ type Key struct {
+ Path, Country string
+ }
+ hits := make(map[Key]int)
+
+When an Vietnamese person visits the home page, incrementing (and possibly creating) the appropriate counter is a one-liner:
+
+ hits[Key{"/", "vn"}]++
+
+And it's similarly straightforward to see how many Swiss people have read the spec:
+
+ n := hits[Key{"/ref/spec", "ch"}]
+
+* Concurrency
+
+[[http://golang.org/doc/faq#atomic_maps][Maps are not safe for concurrent use]]: it's not defined what happens when you read and write to them simultaneously. If you need to read from and write to a map from concurrently executing goroutines, the accesses must be mediated by some kind of synchronization mechanism. One common way to protect maps is with [[http://golang.org/pkg/sync/#RWMutex][sync.RWMutex]].
+
+This statement declares a `counter` variable that is an anonymous struct containing a map and an embedded `sync.RWMutex`.
+
+ var counter = struct{
+ sync.RWMutex
+ m map[string]int
+ }{m: make(map[string]int)}
+
+To read from the counter, take the read lock:
+
+
+ counter.RLock()
+ n := counter.m["some_key"]
+ counter.RUnlock()
+ fmt.Println("some_key:", n)
+
+To write to the counter, take the write lock:
+
+ counter.Lock()
+ counter.m["some_key"]++
+ counter.Unlock()
+
+* Iteration order
+
+When iterating over a map with a range loop, the iteration order is not specified and is not guaranteed to be the same from one iteration to the next. Since Go 1 the runtime randomizes map iteration order, as programmers relied on the stable iteration order of the previous implementation. If you require a stable iteration order you must maintain a separate data structure that specifies that order. This example uses a separate sorted slice of keys to print a `map[int]string` in key order:
+
+ import "sort"
+
+ var m map[int]string
+ var keys []int
+ for k := range m {
+ keys = append(keys, k)
+ }
+ sort.Ints(keys)
+ for _, k := range keys {
+ fmt.Println("Key:", k, "Value:", m[k])
+ }
diff --git a/content/go-one-year-ago-today.article b/content/go-one-year-ago-today.article
new file mode 100644
index 0000000..d29d3d3
--- /dev/null
+++ b/content/go-one-year-ago-today.article
@@ -0,0 +1,41 @@
+Go: one year ago today
+10 Nov 2010
+Tags: release
+
+Andrew Gerrand
+
+* Introduction
+
+On the 10th of November 2009 we launched the Go project: an open-source programming language with a focus on simplicity and efficiency. The intervening year has seen a great many developments both in the Go project itself and in its community.
+
+We set out to build a language for systems programming - the kinds of programs one might typically write in C or C++ - and we were surprised by Go’s utility as a general purpose language. We had anticipated interest from C, C++, and Java programmers, but the flurry of interest from users of dynamically-typed languages like Python and JavaScript was unexpected. Go’s combination of native compilation, static typing, memory management, and lightweight syntax seemed to strike a chord with a broad cross-section of the programming community.
+
+That cross-section grew to become a dedicated community of enthusiastic Go coders. Our [[http://groups.google.com/group/golang-nuts][mailing list]] has over 3,800 members, with around 1,500 posts each month. The project has over 130 [[http://golang.org/CONTRIBUTORS][contributors]] (people who have submitted code or documentation), and of the 2,800 commits since launch almost one third were contributed by programmers outside the core team. To get all that code into shape, nearly 14,000 emails were exchanged on our [[http://groups.google.com/group/golang-dev][development mailing list]].
+
+Those numbers reflect a labor whose fruits are evident in the project’s code base. The compilers have improved substantially, with faster and more efficient code generation, more than one hundred reported bugs fixed, and support for a widening range of operating systems and architectures. The Windows port is approaching completion thanks to a dedicated group of contributors (one of whom became our first non-Google committer to the project). The ARM port has also made great progress, recently reaching the milestone of passing all tests.
+
+The Go tool set has been expanded and improved. The Go documentation tool, [[http://golang.org/cmd/godoc/][godoc]], now supports the documentation of other source trees (you can browse and search your own code) and provides a [[http://golang.org/doc/codewalk/]["code walk"]] interface for presenting tutorial materials (among many more improvements). [[http://golang.org/cmd/goinstall/][Goinstall]] , a new package management tool, allows users to install and update external packages with a single command. [[http://golang.org/cmd/gofmt/][Gofmt]], the Go pretty-printer, now makes syntactic simplifications where possible. [[http://golang.org/misc/goplay/][Goplay]], a web-based “compile-as-you-type” tool, is a convenient way to experiment with Go for those times when you don’t have access to the [[http://golang.org/doc/play/][Go Playground]].
+
+The standard library has grown by over 42,000 lines of code and includes 20 new [[http://golang.org/pkg/][packages]]. Among the additions are the [[http://golang.org/pkg/image/jpeg/][jpeg]], [[http://golang.org/pkg/rpc/jsonrpc/][jsonrpc]], [[http://golang.org/pkg/mime/][mime]], [[http://golang.org/pkg/netchan/][netchan]], and [[http://golang.org/pkg/smtp/][smtp]] packages, as well as a slew of new [[http://golang.org/pkg/crypto/][cryptography]] packages. More generally, the standard library has been continuously refined and revised as our understanding of Go’s idioms deepens.
+
+The debugging story has gotten better, too. Recent improvements to the DWARF output of the gc compilers make the GNU debugger, GDB, useful for Go binaries, and we’re actively working on making that debugging information more complete. (See the [[http://blog.golang.org/2010/11/debugging-go-code-status-report.html][ recent blog post]] for details.)
+
+It’s now easier than ever to link against existing libraries written in languages other than Go. Go support is in the most recent [[http://www.swig.org/][SWIG]] release, version 2.0.1, making it easier to link against C and C++ code, and our [[http://golang.org/cmd/cgo/][cgo]] tool has seen many fixes and improvements.
+
+[[http://golang.org/doc/gccgo_install.html][Gccgo]], the Go front end for the GNU C Compiler, has kept pace with the gc compiler as a parallel Go implementation. It now has a working garbage collector, and has been accepted into the GCC core. We’re now working toward making [[http://code.google.com/p/gofrontend/][gofrontend]] available as a BSD-licensed Go compiler front end, fully decoupled from GCC.
+
+Outside the Go project itself Go is starting to be used to build real software. There are more than 200 Go programs and libraries listed on our [[http://godashboard.appspot.com/project][Project dashboard]], and hundreds more on [[http://code.google.com/hosting/search?q=label:Go][Google Code]] and [[https://github.com/search?q=language:Go][Github]]. On our mailing list and IRC channel you can find coders from around the world who use Go for their programming projects. (See our [[http://blog.golang.org/2010/10/real-go-projects-smarttwitter-and-webgo.html][guest blog post]] from last month for a real-world example.) Internally at Google there are several teams that choose Go for building production software, and we have received reports from other companies that are developing sizable systems in Go. We have also been in touch with several educators who are using Go as a teaching language.
+
+The language itself has grown and matured, too. In the past year we have received many feature requests. But Go is a small language, and we’ve worked hard to ensure that any new feature strikes the right compromise between simplicity and utility. Since the launch we have made a number of language changes, many of which were driven by feedback from the community.
+
+- Semicolons are now optional in almost all instances. [[http://golang.org/doc/go_spec.html#Semicolons][spec]]
+- The new built-in functions `copy` and `append` make management of slices more efficient and straightforward. [[http://golang.org/doc/go_spec.html#Appending_and_copying_slices][spec]]
+- The upper and lower bounds may be omitted when making a sub-slice. This means that `s[:]` is shorthand for `s[0:len(s)]`. [[http://golang.org/doc/go_spec.html#Slices][spec]]
+- The new built-in function `recover` complements `panic` and `defer` as an error handling mechanism. [[http://blog.golang.org/2010/08/defer-panic-and-recover.html][blog]], [[http://golang.org/doc/go_spec.html#Handling_panics][spec]]
+- The new complex number types (`complex`, `complex64`, and `complex128`) simplify certain mathematical operations. [[http://golang.org/doc/go_spec.html#Complex_numbers][spec]], [[http://golang.org/doc/go_spec.html#Imaginary_literals][spec]]
+- The composite literal syntax permits the omission of redundant type information (when specifying two-dimensional arrays, for example). [[http://golang.org/doc/devel/release.html#2010-10-27][release.2010-10-27]], [[http://golang.org/doc/go_spec.html#Composite_literals][spec]]
+- A general syntax for variable function arguments (`...T`) and their propagation (`v...`) is now specified. [[http://golang.org/doc/go_spec.html#Function_Types][spec]], [[http://golang.org/doc/go_spec.html#Passing_arguments_to_..._parameters][ spec]], [[http://golang.org/doc/devel/release.html#2010-09-29][release.2010-09-29]]
+
+Go is certainly ready for production use, but there is still room for improvement. Our focus for the immediate future is making Go programs faster and more efficient in the context of high performance systems. This means improving the garbage collector, optimizing generated code, and improving the core libraries. We’re also exploring some further additions to the type system to make generic programming easier. A lot has happened in a year; it’s been both thrilling and satisfying. We hope that this coming year will be even more fruitful than the last.
+
+_If_you’ve_been_meaning_to_get_[back]_into_Go,_now_is_a_great_time_to_do_so!_Check_out_the_ [[http://golang.org/doc/docs.html][_Documentation_]] _and_ [[http://golang.org/doc/install.html][_Getting_Started_]] _pages_for_more_information,_or_just_go_nuts_in_the_ [[http://golang.org/doc/play/][_Go_Playground_]].
diff --git a/content/go-programming-language-turns-two.article b/content/go-programming-language-turns-two.article
new file mode 100644
index 0000000..c835ec1
--- /dev/null
+++ b/content/go-programming-language-turns-two.article
@@ -0,0 +1,28 @@
+The Go Programming Language turns two
+10 Nov 2011
+Tags: appengine, community, gopher
+
+Andrew Gerrand
+
+* Introduction
+
+Two years ago a small team at Google went public with their fledgling project - the Go Programming Language. They presented a language spec, two compilers, a modest standard library, some novel tools, and plenty of accurate (albeit succinct) documentation. They watched with excitement as programmers around the world began to play with Go. The team continued to iterate and improve on what they had built, and were gradually joined by dozens - and then hundreds - of programmers from the open source community.
+The Go Authors went on to produce lots of libraries, new tools, and reams of [[http://golang.org/doc/docs.html][documentation]]. They celebrated a successful year in the public eye with a [[http://blog.golang.org/2010/11/go-one-year-ago-today.html][blog post]] last November that concluded "Go is certainly ready for production use, but there is still room for improvement. Our focus for the immediate future is making Go programs faster and more efficient in the context of high performance systems."
+
+Today is the second anniversary of Go's release, and Go is faster and more stable than ever. Careful tuning of Go's code generators, concurrency primitives, garbage collector, and core libraries have increased the performance of Go programs, and native support for [[http://blog.golang.org/2011/06/profiling-go-programs.html][profiling]] and [[http://blog.golang.org/2011/10/debugging-go-programs-with-gnu-debugger.html][debugging]] makes it easier to detect and remove performance issues in user code. Go is also now easier to learn with [[http://tour.golang.org/][A Tour of Go]], an interactive tutorial you can take from the comfort of your web browser.
+
+This year we introduced the experimental [[http://code.google.com/appengine/docs/go/][Go runtime]] for Google's App Engine platform, and we have been steadily increasing the Go runtime's support for App Engine's APIs. Just this week we released [[http://code.google.com/appengine/downloads.html][version 1.6.0]] of the Go App Engine SDK, which includes support for [[http://code.google.com/appengine/docs/go/backends/overview.html][backends]] (long-running processes), finer control over datastore indexes, and various other improvements. Today, the Go runtime is near feature parity with - and is a viable alternative to - the Python and Java runtimes. In fact, we now serve [[http://golang.org/][golang.org]] by running a version of [[http://golang.org/cmd/godoc/][godoc]] on the App Engine service.
+
+While 2010 was a year of discovery and experimentation, 2011 was a year of fine tuning and planning for the future. This year we issued several "[[http://golang.org/doc/devel/release.html][release]]" versions of Go that were more reliable and better supported than weekly snapshots. We also introduced [[http://golang.org/cmd/gofix/][gofix]] to take the pain out of migrating to newer releases. Furthermore, last month we announced a [[http://blog.golang.org/2011/10/preview-of-go-version-1.html][plan for Go version 1]] - a release that will be supported for years to come. Work toward Go 1 is already underway and you can observe our progress by the latest weekly snapshot at [[http://weekly.golang.org/pkg/][weekly.golang.org]].
+
+The plan is to launch Go 1 in early 2012. We hope to bring the Go App Engine runtime out of "experimental" status at the same time.
+
+But that's not all. 2011 was an exciting year for the gopher, too. He has manifested himself as a plush toy (a highly prized gift at Google I/O and other Go talks) and in vinyl form (received by every attendee at OSCON and now available at the [[http://www.googlestore.com/Fun/Go+Gopher+Figurine.axd][Google Store]]).
+
+.image go-programming-language-turns-two_gophers.jpg
+
+And, most surprisingly, at Halloween he made an appearance with his gopher girlfriend!
+
+.image go-programming-language-turns-two_costume.jpg
+
+Photograph by [[https://plus.google.com/106640494112897458359/posts][Chris Nokleberg]].
diff --git a/content/go-programming-language-turns-two_costume.jpg b/content/go-programming-language-turns-two_costume.jpg
new file mode 100644
index 0000000..aa86a6c
--- /dev/null
+++ b/content/go-programming-language-turns-two_costume.jpg
Binary files differ
diff --git a/content/go-programming-language-turns-two_gophers.jpg b/content/go-programming-language-turns-two_gophers.jpg
new file mode 100644
index 0000000..72075da
--- /dev/null
+++ b/content/go-programming-language-turns-two_gophers.jpg
Binary files differ
diff --git a/content/go-programming-session-video-from.article b/content/go-programming-session-video-from.article
new file mode 100644
index 0000000..deaea6c
--- /dev/null
+++ b/content/go-programming-session-video-from.article
@@ -0,0 +1,11 @@
+Go Programming session video from Google I/O
+6 Jun 2010
+Tags: video
+
+Andrew Gerrand
+
+* Introduction
+
+Below is the video of the talk given by Rob Pike and Russ Cox at Google I/O 2010.
+
+.iframe http://www.youtube.com/embed/jgVhBThJdXc 304 540
diff --git a/content/go-slices-usage-and-internals.article b/content/go-slices-usage-and-internals.article
new file mode 100644
index 0000000..6c6e616
--- /dev/null
+++ b/content/go-slices-usage-and-internals.article
@@ -0,0 +1,233 @@
+Go Slices: usage and internals
+5 Jan 2011
+Tags: slice
+
+Andrew Gerrand
+
+* Introduction
+
+Go's slice type provides a convenient and efficient means of working with sequences of typed data. Slices are analogous to arrays in other languages, but have some unusual properties. This article will look at what slices are and how they are used.
+
+* Arrays
+
+The slice type is an abstraction built on top of Go's array type, and so to understand slices we must first understand arrays.
+
+An array type definition specifies a length and an element type. For example, the type `[4]int` represents an array of four integers. An array's size is fixed; its length is part of its type (`[4]int` and `[5]int` are distinct, incompatible types). Arrays can be indexed in the usual way, so the expression `s[n]` accesses the nth element:
+
+ var a [4]int
+ a[0] = 1
+ i := a[0]
+ // i == 1
+
+Arrays do not need to be initialized explicitly; the zero value of an array is a ready-to-use array whose elements are themselves zeroed:
+
+ // a[2] == 0, the zero value of the int type
+
+The in-memory representation of `[4]int` is just four integer values laid out sequentially:
+
+.image go-slices-usage-and-internals_slice-array.png
+
+Go's arrays are values. An array variable denotes the entire array; it is not a pointer to the first array element (as would be the case in C). This means that when you assign or pass around an array value you will make a copy of its contents. (To avoid the copy you could pass a _pointer_ to the array, but then that's a pointer to an array, not an array.) One way to think about arrays is as a sort of struct but with indexed rather than named fields: a fixed-size composite value.
+
+An array literal can be specified like so:
+
+ b := [2]string{"Penn", "Teller"}
+
+Or, you can have the compiler count the array elements for you:
+
+ b := [...]string{"Penn", "Teller"}
+
+In both cases, the type of `b` is `[2]string`.
+
+* Slices
+
+Arrays have their place, but they're a bit inflexible, so you don't see them too often in Go code. Slices, though, are everywhere. They build on arrays to provide great power and convenience.
+
+The type specification for a slice is `[]T`, where `T` is the type of the elements of the slice. Unlike an array type, a slice type has no specified length.
+
+A slice literal is declared just like an array literal, except you leave out the element count:
+
+ letters := []string{"a", "b", "c", "d"}
+
+A slice can be created with the built-in function called `make`, which has the signature,
+
+ func make([]T, len, cap) []T
+
+where T stands for the element type of the slice to be created. The `make` function takes a type, a length, and an optional capacity. When called, `make` allocates an array and returns a slice that refers to that array.
+
+ var s []byte
+ s = make([]byte, 5, 5)
+ // s == []byte{0, 0, 0, 0, 0}
+
+When the capacity argument is omitted, it defaults to the specified length. Here's a more succinct version of the same code:
+
+ s := make([]byte, 5)
+
+The length and capacity of a slice can be inspected using the built-in `len` and `cap` functions.
+
+ len(s) == 5
+ cap(s) == 5
+
+The next two sections discuss the relationship between length and capacity.
+
+The zero value of a slice is `nil`. The `len` and `cap` functions will both return 0 for a nil slice.
+
+A slice can also be formed by "slicing" an existing slice or array. Slicing is done by specifying a half-open range with two indices separated by a colon. For example, the expression `b[1:4]` creates a slice including elements 1 through 3 of `b` (the indices of the resulting slice will be 0 through 2).
+
+ b := []byte{'g', 'o', 'l', 'a', 'n', 'g'}
+ // b[1:4] == []byte{'o', 'l', 'a'}, sharing the same storage as b
+
+The start and end indices of a slice expression are optional; they default to zero and the slice's length respectively:
+
+ // b[:2] == []byte{'g', 'o'}
+ // b[2:] == []byte{'l', 'a', 'n', 'g'}
+ // b[:] == b
+
+This is also the syntax to create a slice given an array:
+
+ x := [3]string{"Лайка", "Белка", "Стрелка"}
+ s := x[:] // a slice referencing the storage of x
+
+* Slice internals
+
+A slice is a descriptor of an array segment. It consists of a pointer to the array, the length of the segment, and its capacity (the maximum length of the segment).
+
+.image go-slices-usage-and-internals_slice-struct.png
+
+Our variable `s`, created earlier by `make([]byte,`5)`, is structured like this:
+
+.image go-slices-usage-and-internals_slice-1.png
+
+The length is the number of elements referred to by the slice. The capacity is the number of elements in the underlying array (beginning at the element referred to by the slice pointer). The distinction between length and capacity will be made clear as we walk through the next few examples.
+
+As we slice `s`, observe the changes in the slice data structure and their relation to the underlying array:
+
+ s = s[2:4]
+
+.image go-slices-usage-and-internals_slice-2.png
+
+Slicing does not copy the slice's data. It creates a new slice value that points to the original array. This makes slice operations as efficient as manipulating array indices. Therefore, modifying the _elements_ (not the slice itself) of a re-slice modifies the elements of the original slice:
+
+ d := []byte{'r', 'o', 'a', 'd'}
+ e := d[2:]
+ // e == []byte{'a', 'd'}
+ e[1] == 'm'
+ // e == []byte{'a', 'm'}
+ // d == []byte{'r', 'o', 'a', 'm'}
+
+Earlier we sliced `s` to a length shorter than its capacity. We can grow s to its capacity by slicing it again:
+
+ s = s[:cap(s)]
+
+.image go-slices-usage-and-internals_slice-3.png
+
+A slice cannot be grown beyond its capacity. Attempting to do so will cause a runtime panic, just as when indexing outside the bounds of a slice or array. Similarly, slices cannot be re-sliced below zero to access earlier elements in the array.
+
+* Growing slices (the copy and append functions)
+
+To increase the capacity of a slice one must create a new, larger slice and copy the contents of the original slice into it. This technique is how dynamic array implementations from other languages work behind the scenes. The next example doubles the capacity of `s` by making a new slice, `t`, copying the contents of `s` into `t`, and then assigning the slice value `t` to `s`:
+
+ t := make([]byte, len(s), (cap(s)+1)*2) // +1 in case cap(s) == 0
+ for i := range s {
+ t[i] = s[i]
+ }
+ s = t
+
+The looping piece of this common operation is made easier by the built-in copy function. As the name suggests, copy copies data from a source slice to a destination slice. It returns the number of elements copied.
+
+ func copy(dst, src []T) int
+
+The `copy` function supports copying between slices of different lengths (it will copy only up to the smaller number of elements). In addition, `copy` can handle source and destination slices that share the same underlying array, handling overlapping slices correctly.
+
+Using `copy`, we can simplify the code snippet above:
+
+ t := make([]byte, len(s), (cap(s)+1)*2)
+ copy(t, s)
+ s = t
+
+A common operation is to append data to the end of a slice. This function appends byte elements to a slice of bytes, growing the slice if necessary, and returns the updated slice value:
+
+ func AppendByte(slice []byte, data ...byte) []byte {
+ m := len(slice)
+ n := m + len(data)
+ if n > cap(slice) { // if necessary, reallocate
+ // allocate double what's needed, for future growth.
+ newSlice := make([]byte, (n+1)*2)
+ copy(newSlice, slice)
+ slice = newSlice
+ }
+ slice = slice[0:n]
+ copy(slice[m:n], data)
+ return slice
+ }
+
+One could use `AppendByte` like this:
+
+ p := []byte{2, 3, 5}
+ p = AppendByte(p, 7, 11, 13)
+ // p == []byte{2, 3, 5, 7, 11, 13}
+
+Functions like `AppendByte` are useful because they offer complete control over the way the slice is grown. Depending on the characteristics of the program, it may be desirable to allocate in smaller or larger chunks, or to put a ceiling on the size of a reallocation.
+
+But most programs don't need complete control, so Go provides a built-in `append` function that's good for most purposes; it has the signature
+
+ func append(s []T, x ...T) []T
+
+The `append` function appends the elements `x` to the end of the slice `s`, and grows the slice if a greater capacity is needed.
+
+ a := make([]int, 1)
+ // a == []int{0}
+ a = append(a, 1, 2, 3)
+ // a == []int{0, 1, 2, 3}
+
+To append one slice to another, use `...` to expand the second argument to a list of arguments.
+
+ a := []string{"John", "Paul"}
+ b := []string{"George", "Ringo", "Pete"}
+ a = append(a, b...) // equivalent to "append(a, b[0], b[1], b[2])"
+ // a == []string{"John", "Paul", "George", "Ringo", "Pete"}
+
+Since the zero value of a slice (`nil`) acts like a zero-length slice, you can declare a slice variable and then append to it in a loop:
+
+ // Filter returns a new slice holding only
+ // the elements of s that satisfy f()
+ func Filter(s []int, fn func(int) bool) []int {
+ var p []int // == nil
+ for _, i := range s {
+ if fn(i) {
+ p = append(p, i)
+ }
+ }
+ return p
+ }
+
+* A possible "gotcha"
+
+As mentioned earlier, re-slicing a slice doesn't make a copy of the underlying array. The full array will be kept in memory until it is no longer referenced. Occasionally this can cause the program to hold all the data in memory when only a small piece of it is needed.
+
+For example, this `FindDigits` function loads a file into memory and searches it for the first group of consecutive numeric digits, returning them as a new slice.
+
+ var digitRegexp = regexp.MustCompile("[0-9]+")
+
+ func FindDigits(filename string) []byte {
+ b, _ := ioutil.ReadFile(filename)
+ return digitRegexp.Find(b)
+ }
+
+This code behaves as advertised, but the returned `[]byte` points into an array containing the entire file. Since the slice references the original array, as long as the slice is kept around the garbage collector can't release the array; the few useful bytes of the file keep the entire contents in memory.
+
+To fix this problem one can copy the interesting data to a new slice before returning it:
+
+ func CopyDigits(filename string) []byte {
+ b, _ := ioutil.ReadFile(filename)
+ b = digitRegexp.Find(b)
+ c := make([]byte, len(b))
+ copy(c, b)
+ return c
+ }
+
+A more concise version of this function could be constructed by using `append`. This is left as an exercise for the reader.
+
+* Further Reading
+
+[[http://golang.org/doc/effective_go.html][Effective Go]] contains an in-depth treatment of [[http://golang.org/doc/effective_go.html#slices][slices]] and [[http://golang.org/doc/effective_go.html#arrays][arrays]], and the Go [[http://golang.org/doc/go_spec.html][language specification]] defines [[http://golang.org/doc/go_spec.html#Slice_types][slices]] and their [[http://golang.org/doc/go_spec.html#Length_and_capacity][associated]] [[http://golang.org/doc/go_spec.html#Making_slices_maps_and_channels][helper]] [[http://golang.org/doc/go_spec.html#Appending_and_copying_slices][functions]].
diff --git a/content/go-slices-usage-and-internals_slice-1.png b/content/go-slices-usage-and-internals_slice-1.png
new file mode 100644
index 0000000..ba465cf
--- /dev/null
+++ b/content/go-slices-usage-and-internals_slice-1.png
Binary files differ
diff --git a/content/go-slices-usage-and-internals_slice-2.png b/content/go-slices-usage-and-internals_slice-2.png
new file mode 100644
index 0000000..a57581e
--- /dev/null
+++ b/content/go-slices-usage-and-internals_slice-2.png
Binary files differ
diff --git a/content/go-slices-usage-and-internals_slice-3.png b/content/go-slices-usage-and-internals_slice-3.png
new file mode 100644
index 0000000..64ece5e
--- /dev/null
+++ b/content/go-slices-usage-and-internals_slice-3.png
Binary files differ
diff --git a/content/go-slices-usage-and-internals_slice-array.png b/content/go-slices-usage-and-internals_slice-array.png
new file mode 100644
index 0000000..a533702
--- /dev/null
+++ b/content/go-slices-usage-and-internals_slice-array.png
Binary files differ
diff --git a/content/go-slices-usage-and-internals_slice-struct.png b/content/go-slices-usage-and-internals_slice-struct.png
new file mode 100644
index 0000000..f9141fc
--- /dev/null
+++ b/content/go-slices-usage-and-internals_slice-struct.png
Binary files differ
diff --git a/content/go-turns-three.article b/content/go-turns-three.article
new file mode 100644
index 0000000..97fd3a6
--- /dev/null
+++ b/content/go-turns-three.article
@@ -0,0 +1,76 @@
+Go turns three
+10 Nov 2012
+Tags: community
+
+Russ Cox
+
+* Introduction
+
+The Go open source project is
+[[http://google-opensource.blogspot.com/2009/11/hey-ho-lets-go.html][three years old today]].
+
+It's great to look at how far Go has come in those three years.
+When we launched, Go was an idea backed by two implementations that worked on Linux and OS X.
+The syntax, semantics, and libraries changed regularly as we reacted to feedback from users
+and experience with the language.
+
+Since the open source launch,
+we've been joined by
+[[http://tip.golang.org/CONTRIBUTORS][hundreds of external contributors]],
+who have extended and improved Go in myriad ways,
+including writing a Windows port from scratch.
+We added a package management system
+[[https://groups.google.com/d/msg/golang-nuts/8JFwR3ESjjI/cy7qZzN7Lw4J][goinstall]],
+which eventually became the
+[[http://golang.org/cmd/go/][go command]].
+We also added
+[[http://blog.golang.org/2011/07/go-for-app-engine-is-now-generally.html][support for Go on App Engine]].
+Over the past year we've also given [[http://golang.org/doc/#talks][many talks]], created an [[http://tour.golang.org/][interactive introductory tour]]
+and recently we added support for [[http://golang.org/pkg/strings/#pkg-examples][executable examples in package documentation]].
+
+Perhaps the most important development in the past year
+was the launch of the first stable version,
+[[http://blog.golang.org/2012/03/go-version-1-is-released.html][Go 1]].
+People who write Go 1 programs can now be confident that their programs will
+continue to compile and run without change, in many environments,
+on a time scale of years.
+As part of the Go 1 launch we spent months cleaning up the
+[[http://golang.org/doc/go1.html][language and libraries]]
+to make it something that will age well.
+
+We're working now toward the release of Go 1.1 in 2013. There will be some
+new functionality, but that release will focus primarily on making Go perform
+even better than it does today.
+
+We're especially happy about the community that has grown around Go:
+the mailing list and IRC channels seem like they are overflowing with discussion,
+and a handful of Go books were published this year. The community is thriving.
+Use of Go in production environments has also taken off, especially since Go 1.
+
+We use Go at Google in a variety of ways, many of them invisible to the outside world.
+A few visible ones include
+[[https://groups.google.com/d/msg/golang-nuts/BNUNbKSypE0/E4qSfpx9qI8J][serving Chrome and other downloads]],
+[[http://code.google.com/p/vitess/][scaling MySQL database at YouTube]],
+and of course running the
+[[http://golang.org/][Go home page]]
+on [[https://developers.google.com/appengine/docs/go/overview][App Engine]].
+Last year's
+[[http://blog.golang.org/2011/12/from-zero-to-go-launching-on-google.html][Thanksgiving Doodle]]
+and the recent
+[[http://www.jamwithchrome.com/technology][Jam with Chrome]]
+site are also served by Go programs.
+
+Other companies and projects are using Go too, including
+[[http://www.quora.com/Go-programming-language/Is-Google-Go-ready-for-production-use/answer/Kunal-Anand][BBC Worldwide]],
+[[http://dave.cheney.net/wp-content/uploads/2012/08/august-go-meetup.pdf][Canonical]],
+[[http://blog.cloudflare.com/go-at-cloudflare][CloudFlare]],
+[[http://blog.golang.org/2011/04/go-at-heroku.html][Heroku]],
+[[https://plus.google.com/114945221884326152379/posts/d1SVaqkRyTL][Novartis]],
+[[http://backstage.soundcloud.com/2012/07/go-at-soundcloud/][SoundCloud]],
+[[http://sorcery.smugmug.com/2012/04/06/deriving-json-types-in-go/][SmugMug]],
+[[http://blog.golang.org/2011/12/building-stathat-with-go.html][StatHat]],
+[[https://tinkercad.com/about/jobs][Tinkercad]],
+and
+[[http://code.google.com/p/go-wiki/wiki/GoUsers][many others]].
+
+Here's to many more years of productive programming in Go.
diff --git a/content/go-updates-in-app-engine-171.article b/content/go-updates-in-app-engine-171.article
new file mode 100644
index 0000000..24482e2
--- /dev/null
+++ b/content/go-updates-in-app-engine-171.article
@@ -0,0 +1,21 @@
+Go updates in App Engine 1.7.1
+22 Aug 2012
+Tags: appengine, release
+
+Andrew Gerrand
+
+* Introduction
+
+This week we released version 1.7.1 of the App Engine SDK. It includes some significant updates specific to the App Engine runtime for Go.
+
+The [[https://developers.google.com/appengine/docs/go/memcache/reference][memcache package]] has had some additions to its [[https://developers.google.com/appengine/docs/go/memcache/reference#Codec][Codec]] convenience type. The SetMulti, AddMulti, CompareAndSwap, and CompareAndSwapMulti methods make it easier to store and update encoded data in the [[https://developers.google.com/appengine/docs/go/memcache/overview][Memcache Service]].
+
+The [[https://developers.google.com/appengine/docs/go/tools/uploadingdata][bulkloader tool]] can now be used with Go apps, allowing users to upload and download datastore records in bulk. This is useful for backups and offline processing, and a great help when migrating Python or Java apps to the Go runtime.
+
+The [[https://developers.google.com/appengine/docs/go/images/overview][Images Service]] is now available to Go users. The new [[https://developers.google.com/appengine/docs/go/images/reference][appengine/image package]] supports serving images directly from Blobstore and resizing or cropping those images on the fly. Note that this is not the full image service as provided by the Python and Java SDKs, as much of the equivalent functionality is available in the [[http://golang.org/pkg/image/][standard Go image package]] and external packages such as [[http://code.google.com/p/graphics-go/][graphics-go]].
+
+The new [[https://developers.google.com/appengine/docs/go/backends/runtime#RunInBackground][runtime.RunInBackground]] function allows backend requests to spawn a new request independent of the initial request. These can run in the background as long as the backend stays alive.
+
+Finally, we have filled in some missing functionality: the [[https://developers.google.com/appengine/docs/go/xmpp/reference][xmpp package]] now supports sending presence updates and chat invitations and retrieving the presence state of another user, and the [[https://developers.google.com/appengine/docs/go/users/reference][user package]] supports authenticating clients with OAuth.
+
+You can grab the new SDK from the [[https://developers.google.com/appengine/downloads#Google_App_Engine_SDK_for_Go][App Engine downloads page]] and browse the [[https://developers.google.com/appengine/docs/go][updated documentation]].
diff --git a/content/go-version-1-is-released.article b/content/go-version-1-is-released.article
new file mode 100644
index 0000000..c30ee42
--- /dev/null
+++ b/content/go-version-1-is-released.article
@@ -0,0 +1,27 @@
+Go version 1 is released
+28 Mar 2012
+
+Andrew Gerrand
+
+* Introduction
+
+.image go-version-1-is-released_gophermega.jpg
+Today marks a major milestone in the development of the Go programming language. We're announcing Go version 1, or Go 1 for short, which defines a language and a set of core libraries to provide a stable foundation for creating reliable products, projects, and publications.
+
+Go 1 is the first release of Go that is available in supported binary distributions. They are available for Linux, FreeBSD, Mac OS X and, we are thrilled to announce, Windows.
+
+The driving motivation for Go 1 is stability for its users. People who write Go 1 programs can be confident that those programs will continue to compile and run without change, in many environments, on a time scale of years. Similarly, authors who write books about Go 1 can be sure that their examples and explanations will be helpful to readers today and into the future.
+
+Forward compatibility is part of stability. Code that compiles in Go 1 should, with few exceptions, continue to compile and run throughout the lifetime of that version, even as we issue updates and bug fixes such as Go version 1.1, 1.2, and so on. The [[http://golang.org/doc/go1compat.html][Go 1 compatibility document]] explains the compatibility guidelines in more detail.
+
+Go 1 is a representation of Go as it is used today, not a major redesign. In its planning, we focused on cleaning up problems and inconsistencies and improving portability. There had long been many changes to Go that we had designed and prototyped but not released because they were backwards-incompatible. Go 1 incorporates these changes, which provide significant improvements to the language and libraries but sometimes introduce incompatibilities for old programs. Fortunately, the [[http://golang.org/cmd/go/#Run_go_tool_fix_on_packages][go fix]] tool can automate much of the work needed to bring programs up to the Go 1 standard.
+
+Go 1 introduces changes to the language (such as new types for [[http://golang.org/doc/go1.html#rune][Unicode characters]] and [[http://golang.org/doc/go1.html#errors][errors]]) and the standard library (such as the new [[http://golang.org/doc/go1.html#time][time package]] and renamings in the [[http://golang.org/doc/go1.html#strconv][strconv package]]). Also, the package hierarchy has been rearranged to group related items together, such as moving the networking facilities, for instance the [[http://golang.org/pkg/net/rpc/][rpc package]], into subdirectories of net. A complete list of changes is documented in the [[http://golang.org/doc/go1.html][Go 1 release notes]]. That document is an essential reference for programmers migrating code from earlier versions of Go.
+
+We also restructured the Go tool suite around the new [[http://golang.org/doc/go1.html#cmd_go][go command]], a program for fetching, building, installing and maintaining Go code. The go command eliminates the need for Makefiles to write Go code because it uses the Go program source itself to derive the build instructions. No more build scripts!
+
+Finally, the release of Go 1 triggers a new release of the [[https://developers.google.com/appengine/docs/go][Google App Engine SDK]]. A similar process of revision and stabilization has been applied to the App Engine libraries, providing a base for developers to build programs for App Engine that will run for years.
+
+Go 1 is the result of a major effort by the core Go team and our many contributors from the open source community. We thank everyone who helped make this happen.
+
+There has never been a better time to be a Go programmer. Everything you need to get started is at [[http://golang.org/][golang.org]].
diff --git a/content/go-version-1-is-released_gophermega.jpg b/content/go-version-1-is-released_gophermega.jpg
new file mode 100644
index 0000000..7f07bbd
--- /dev/null
+++ b/content/go-version-1-is-released_gophermega.jpg
Binary files differ
diff --git a/content/go-videos-from-google-io-2012.article b/content/go-videos-from-google-io-2012.article
new file mode 100644
index 0000000..08195e6
--- /dev/null
+++ b/content/go-videos-from-google-io-2012.article
@@ -0,0 +1,34 @@
+Go videos from Google I/O 2012
+2 Jul 2012
+
+Andrew Gerrand
+
+* Introduction
+
+Phew! Google I/O is over for another year, and what an event it was. Thanks to our guest speakers and everyone who attended the four Go sessions. It was a lot of fun.
+
+Here are the session videos:
+
+*Go*concurrency*patterns* by Rob Pike
+
+_Concurrency_is_the_key_to_designing_high_performance_network_services._Go's_concurrency_primitives_(goroutines_and_channels)_provide_a_simple_and_efficient_means_of_expressing_concurrent_execution._In_this_talk_we_see_how_tricky_concurrency_problems_can_be_solved_gracefully_with_simple_Go_code._
+
+.iframe http://www.youtube.com/embed/f6kdp27TYZs 304 540
+
+* Go in production
+
+_Since_Go's_release_in_2009_many_companies_(besides_Google,_of_course)_have_used_the_language_to_build_cool_stuff._In_this_session_Gustavo_Niemeyer_(Canonical),_Keith_Rarick_(Heroku),_Evan_Shaw_(Iron.io),_and_Patrick_Crosby_(StatHat)_share_their_first-hand_experience_using_Go_in_production_environments._
+
+.iframe http://www.youtube.com/embed/kKQLhGZVN4A 304 540
+
+* Meet the Go team
+
+_A_panel_discussion_with_David_Symonds,_Robert_Griesemer,_Rob_Pike,_Ken_Thompson,_Andrew_Gerrand,_and_Brad_Fitzpatrick._
+
+.iframe http://www.youtube.com/embed/sln-gJaURzk 304 540
+
+*Computing*Map*Tiles*with*Go*on*App*Engine* by Chris Broadfoot and Andrew Gerrand
+
+_In_this_talk_we_use_the_Maps_API_and_Go_on_App_Engine_to_build_an_app_to_build_custom_tile_sets_for_Google_Maps._The_app_demonstrates_using_Go's_suitability_for_computation_in_the_cloud_and_App_Engine's_key_scalability_features,_such_as_Task_Queues_and_Backends._
+
+.iframe http://www.youtube.com/embed/sPagpg0b7no 304 540
diff --git a/content/go-whats-new-in-march-2010.article b/content/go-whats-new-in-march-2010.article
new file mode 100644
index 0000000..858660d
--- /dev/null
+++ b/content/go-whats-new-in-march-2010.article
@@ -0,0 +1,24 @@
+Go: What's New in March 2010
+18 Mar 2010
+
+Andrew Gerrand
+
+* Introduction
+
+Welcome to the official Go Blog. We, the Go team, hope to use this blog to keep the world up-to-date on the development of the Go programming language and the growing ecosystem of libraries and applications surrounding it.
+
+It's been a few months since we launched (November last year), so let's talk about what's been happening in Go World since then.
+
+The core team at Google has continued to develop the language, compilers, packages, tools, and documentation. The compilers now produce code that is in some cases between 2x and an order of magnitude faster than at release. We have put together some graphs of a selection of [[http://godashboard.appspot.com/benchmarks][Benchmarks]], and the the [[http://godashboard.appspot.com/][Build Status]] page tracks the reliability of each changeset submitted to the repository.
+
+We have made syntax changes to make the language more concise, regular, and flexible. Semicolons have been [[http://groups.google.com/group/golang-nuts/t/5ee32b588d10f2e9][almost entirely removed]] from the language. The [[http://golang.org/doc/go_spec.html#Function_types][...T syntax]] makes it simpler to handle an arbitrary number of typed function parameters. The syntax x[lo:] is now shorthand for x[lo:len(x)]. Go also now natively supports complex numbers. See the [[http://golang.org/doc/devel/release.html][release notes]] for more.
+
+[[http://golang.org/cmd/godoc/][Godoc]] now provides better support for third-party libraries, and a new tool - [[http://golang.org/cmd/goinstall][goinstall]] - has been released to make it easy to install them. Additionally, we've started working on a package tracking system to make it easier to find what you need. You can view the beginnings of this on the [[http://godashboard.appspot.com/package][Packages page]].
+
+More than 40,000 lines of code have been added to [[http://golang.org/pkg/][the standard library]], including many entirely new packages, a sizable portion written by external contributors.
+
+Speaking of third parties, since launch a vibrant community has flourished on our [[http://groups.google.com/group/golang-nuts/][mailing list]] and irc channel (#go-nuts on freenode). We have officially added [[http://golang.org/CONTRIBUTORS][more than 50 people]] to the project. Their contributions range from bug fixes and documentation corrections to core packages and support for additional operating systems (Go is now supported under FreeBSD, and a [[http://code.google.com/p/go/wiki/WindowsPort][Windows port]] is underway). We regard these community contributions our greatest success so far.
+
+We've received some good reviews, too. This [[http://www.pcworld.idg.com.au/article/337773/google_go_captures_developers_imaginations/][recent article in PC World]] summarized the enthusiasm surrounding the project. Several bloggers have begun documenting their experiences in the language (see [[http://golang.tumblr.com/][here]], [[http://www.infi.nl/blog/view/id/47][here]], and [[http://freecella.blogspot.com/2010/01/gospecify-basic-setup-of-projects.html][here]] for example) The general reaction of our users has been very positive; one first-timer remarked [[https://groups.google.com/group/golang-nuts/browse_thread/thread/5fabdd59f8562ed2]["I came away extremely impressed. Go walks an elegant line between simplicity and power."]]
+
+As to the future: we have listened to the myriad voices telling us what they need, and are now focused on getting Go ready for the prime time. We are improving the garbage collector, runtime scheduler, tools, and standard libraries, as well as exploring new language features. 2010 will be an exciting year for Go, and we look forward to collaborating with the community to make it a successful one.
diff --git a/content/go-wins-2010-bossie-award.article b/content/go-wins-2010-bossie-award.article
new file mode 100644
index 0000000..a48fb1c
--- /dev/null
+++ b/content/go-wins-2010-bossie-award.article
@@ -0,0 +1,10 @@
+Go Wins 2010 Bossie Award
+6 Sep 2010
+
+Andrew Gerrand
+
+* Introduction
+
+The Go project has been awarded a [[http://www.infoworld.com/d/open-source/bossie-awards-2010-the-best-open-source-application-development-software-140¤t=2&last=1][Bossie Award]] for "best open source application development software." The [[http://www.infoworld.com/d/open-source/bossie-awards-2010-the-best-open-source-software-the-year-115][Bossie Awards]] have been given each year since 2007 by [[http://infoworld.com/][InfoWorld]] to recognize the best Open Source projects. Their citation reads:
+
+Google's Go language tries to restore simplicity to programming. It does away with numerous constructs that have crept into all OO languages by re-imagining how to simplify and improve the conversation between a developer and the code. Go provides garbage collection, type safety, memory safety, and built-in support for concurrency and for Unicode characters. In addition, it compiles (fast!) to binaries for multiple platforms. Go is still in development (new features are being added) and it has limitations, notably poor support for Windows. But it shows a new, exciting direction in programming languages.The Go team are pleased to accept this award. It reflects not only our hard work, but also the efforts of the growing community of Go developers to whom we must extend our sincere thanks.
diff --git a/content/gobs-of-data.article b/content/gobs-of-data.article
new file mode 100644
index 0000000..2f64ecc
--- /dev/null
+++ b/content/gobs-of-data.article
@@ -0,0 +1,140 @@
+Gobs of data
+24 Mar 2011
+Tags: gob, json, protobuf, xml
+
+Rob Pike
+
+* Introduction
+
+To transmit a data structure across a network or to store it in a file, it must be encoded and then decoded again. There are many encodings available, of course: [[http://www.json.org/][JSON]], [[http://www.w3.org/XML/][XML]], Google's [[http://code.google.com/p/protobuf][protocol buffers]], and more. And now there's another, provided by Go's [[http://golang.org/pkg/encoding/gob/][gob]] package.
+
+Why define a new encoding? It's a lot of work and redundant at that. Why not just use one of the existing formats? Well, for one thing, we do! Go has [[http://golang.org/pkg/][packages]] supporting all the encodings just mentioned (the [[http://code.google.com/p/goprotobuf][protocol buffer package]] is in a separate repository but it's one of the most frequently downloaded). And for many purposes, including communicating with tools and systems written in other languages, they're the right choice.
+
+But for a Go-specific environment, such as communicating between two servers written in Go, there's an opportunity to build something much easier to use and possibly more efficient.
+
+Gobs work with the language in a way that an externally-defined, language-independent encoding cannot. At the same time, there are lessons to be learned from the existing systems.
+
+* Goals
+
+The gob package was designed with a number of goals in mind.
+
+First, and most obvious, it had to be very easy to use. First, because Go has reflection, there is no need for a separate interface definition language or "protocol compiler". The data structure itself is all the package should need to figure out how to encode and decode it. On the other hand, this approach means that gobs will never work as well with other languages, but that's OK: gobs are unashamedly Go-centric.
+
+Efficiency is also important. Textual representations, exemplified by XML and JSON, are too slow to put at the center of an efficient communications network. A binary encoding is necessary.
+
+Gob streams must be self-describing. Each gob stream, read from the beginning, contains sufficient information that the entire stream can be parsed by an agent that knows nothing a priori about its contents. This property means that you will always be able to decode a gob stream stored in a file, even long after you've forgotten what data it represents.
+
+There were also some things to learn from our experiences with Google protocol buffers.
+
+* Protocol buffer misfeatures
+
+Protocol buffers had a major effect on the design of gobs, but have three features that were deliberately avoided. (Leaving aside the property that protocol buffers aren't self-describing: if you don't know the data definition used to encode a protocol buffer, you might not be able to parse it.)
+
+First, protocol buffers only work on the data type we call a struct in Go. You can't encode an integer or array at the top level, only a struct with fields inside it. That seems a pointless restriction, at least in Go. If all you want to send is an array of integers, why should you have to put it into a struct first?
+
+Next, a protocol buffer definition may specify that fields `T.x` and `T.y` are required to be present whenever a value of type `T` is encoded or decoded. Although such required fields may seem like a good idea, they are costly to implement because the codec must maintain a separate data structure while encoding and decoding, to be able to report when required fields are missing. They're also a maintenance problem. Over time, one may want to modify the data definition to remove a required field, but that may cause existing clients of the data to crash. It's better not to have them in the encoding at all. (Protocol buffers also have optional fields. But if we don't have required fields, all fields are optional and that's that. There will be more to say about optional fields a little later.)
+
+The third protocol buffer misfeature is default values. If a protocol buffer omits the value for a "defaulted" field, then the decoded structure behaves as if the field were set to that value. This idea works nicely when you have getter and setter methods to control access to the field, but is harder to handle cleanly when the container is just a plain idiomatic struct. Required fields are also tricky to implement: where does one define the default values, what types do they have (is text UTF-8? uninterpreted bytes? how many bits in a float?) and despite the apparent simplicity, there were a number of complications in their design and implementation for protocol buffers. We decided to leave them out of gobs and fall back to Go's trivial but effective defaulting rule: unless you set something otherwise, it has the "zero value" for that type - and it doesn't need to be transmitted.
+
+So gobs end up looking like a sort of generalized, simplified protocol buffer. How do they work?
+
+* Values
+
+The encoded gob data isn't about types like `int8` and `uint16`. Instead, somewhat analogous to constants in Go, its integer values are abstract, sizeless numbers, either signed or unsigned. When you encode an `int8`, its value is transmitted as an unsized, variable-length integer. When you encode an `int64`, its value is also transmitted as an unsized, variable-length integer. (Signed and unsigned are treated distinctly, but the same unsized-ness applies to unsigned values too.) If both have the value 7, the bits sent on the wire will be identical. When the receiver decodes that value, it puts it into the receiver's variable, which may be of arbitrary integer type. Thus an encoder may send a 7 that came from an `int8`, but the receiver may store it in an `int64`. This is fine: the value is an integer and as a long as it fits, everything works. (If it doesn't fit, an error results.) This decoupling from the size of the variable gives some flexibility to the encoding: we can expand the type of the integer variable as the software evolves, but still be able to decode old data.
+
+This flexibility also applies to pointers. Before transmission, all pointers are flattened. Values of type `int8`, `*int8`, `**int8`, `****int8`, etc. are all transmitted as an integer value, which may then be stored in `int` of any size, or `*int`, or `******int`, etc. Again, this allows for flexibility.
+
+Flexibility also happens because, when decoding a struct, only those fields that are sent by the encoder are stored in the destination. Given the value
+
+ type T struct{ X, Y, Z int } // Only exported fields are encoded and decoded.
+ var t = T{X: 7, Y: 0, Z: 8}
+
+the encoding of `t` sends only the 7 and 8. Because it's zero, the value of `Y` isn't even sent; there's no need to send a zero value.
+
+The receiver could instead decode the value into this structure:
+
+ type U struct{ X, Y *int8 } // Note: pointers to int8s
+ var u U
+
+and acquire a value of `u` with only `X` set (to the address of an `int8` variable set to 7); the `Z` field is ignored - where would you put it? When decoding structs, fields are matched by name and compatible type, and only fields that exist in both are affected. This simple approach finesses the "optional field" problem: as the type `T` evolves by adding fields, out of date receivers will still function with the part of the type they recognize. Thus gobs provide the important result of optional fields - extensibility - without any additional mechanism or notation.
+
+From integers we can build all the other types: bytes, strings, arrays, slices, maps, even floats. Floating-point values are represented by their IEEE 754 floating-point bit pattern, stored as an integer, which works fine as long as you know their type, which we always do. By the way, that integer is sent in byte-reversed order because common values of floating-point numbers, such as small integers, have a lot of zeros at the low end that we can avoid transmitting.
+
+One nice feature of gobs that Go makes possible is that they allow you to define your own encoding by having your type satisfy the [[http://golang.org/pkg/encoding/gob/#GobEncoder][GobEncoder]] and [[http://golang.org/pkg/encoding/gob/#GobDecoder][GobDecoder]] interfaces, in a manner analogous to the [[http://golang.org/pkg/encoding/json/][JSON]] package's [[http://golang.org/pkg/encoding/json/#Marshaler][Marshaler]] and [[http://golang.org/pkg/encoding/json/#Unmarshaler][Unmarshaler]] and also to the [[http://golang.org/pkg/fmt/#Stringer][Stringer]] interface from [[http://golang.org/pkg/fmt/][package fmt]]. This facility makes it possible to represent special features, enforce constraints, or hide secrets when you transmit data. See the [[http://golang.org/pkg/encoding/gob/][documentation]] for details.
+
+* Types on the wire
+
+The first time you send a given type, the gob package includes in the data stream a description of that type. In fact, what happens is that the encoder is used to encode, in the standard gob encoding format, an internal struct that describes the type and gives it a unique number. (Basic types, plus the layout of the type description structure, are predefined by the software for bootstrapping.) After the type is described, it can be referenced by its type number.
+
+Thus when we send our first type `T`, the gob encoder sends a description of `T` and tags it with a type number, say 127. All values, including the first, are then prefixed by that number, so a stream of `T` values looks like:
+
+ ("define type id" 127, definition of type T)(127, T value)(127, T value), ...
+
+These type numbers make it possible to describe recursive types and send values of those types. Thus gobs can encode types such as trees:
+
+ type Node struct {
+ Value int
+ Left, Right *Node
+ }
+
+(It's an exercise for the reader to discover how the zero-defaulting rule makes this work, even though gobs don't represent pointers.)
+
+With the type information, a gob stream is fully self-describing except for the set of bootstrap types, which is a well-defined starting point.
+
+* Compiling a machine
+
+The first time you encode a value of a given type, the gob package builds a little interpreted machine specific to that data type. It uses reflection on the type to construct that machine, but once the machine is built it does not depend on reflection. The machine uses package unsafe and some trickery to convert the data into the encoded bytes at high speed. It could use reflection and avoid unsafe, but would be significantly slower. (A similar high-speed approach is taken by the protocol buffer support for Go, whose design was influenced by the implementation of gobs.) Subsequent values of the same type use the already-compiled machine, so they can be encoded right away.
+
+Decoding is similar but harder. When you decode a value, the gob package holds a byte slice representing a value of a given encoder-defined type to decode, plus a Go value into which to decode it. The gob package builds a machine for that pair: the gob type sent on the wire crossed with the Go type provided for decoding. Once that decoding machine is built, though, it's again a reflectionless engine that uses unsafe methods to get maximum speed.
+
+* Use
+
+There's a lot going on under the hood, but the result is an efficient, easy-to-use encoding system for transmitting data. Here's a complete example showing differing encoded and decoded types. Note how easy it is to send and receive values; all you need to do is present values and variables to the [[http://golang.org/pkg/encoding/gob/][gob package]] and it does all the work.
+
+ package main
+
+ import (
+ "bytes"
+ "encoding/gob"
+ "fmt"
+ "log"
+ )
+
+ type P struct {
+ X, Y, Z int
+ Name string
+ }
+
+ type Q struct {
+ X, Y *int32
+ Name string
+ }
+
+ func main() {
+ // Initialize the encoder and decoder. Normally enc and dec would be
+ // bound to network connections and the encoder and decoder would
+ // run in different processes.
+ var network bytes.Buffer // Stand-in for a network connection
+ enc := gob.NewEncoder(&network) // Will write to network.
+ dec := gob.NewDecoder(&network) // Will read from network.
+ // Encode (send) the value.
+ err := enc.Encode(P{3, 4, 5, "Pythagoras"})
+ if err != nil {
+ log.Fatal("encode error:", err)
+ }
+ // Decode (receive) the value.
+ var q Q
+ err = dec.Decode(&q)
+ if err != nil {
+ log.Fatal("decode error:", err)
+ }
+ fmt.Printf("%q: {%d,%d}\n", q.Name, *q.X, *q.Y)
+ }
+
+You can compile and run this example code in the [[http://play.golang.org/p/_-OJV-rwMq][Go Playground]].
+
+The [[http://golang.org/pkg/net/rpc/][rpc package]] builds on gobs to turn this encode/decode automation into transport for method calls across the network. That's a subject for another article.
+
+* Details
+
+The [[http://golang.org/pkg/encoding/gob/][gob package documentation]], especially the file [[http://golang.org/src/pkg/encoding/gob/doc.go][doc.go]], expands on many of the details described here and includes a full worked example showing how the encoding represents data. If you are interested in the innards of the gob implementation, that's a good place to start.
diff --git a/content/godoc-documenting-go-code.article b/content/godoc-documenting-go-code.article
new file mode 100644
index 0000000..602df0e
--- /dev/null
+++ b/content/godoc-documenting-go-code.article
@@ -0,0 +1,54 @@
+Godoc: documenting Go code
+31 Mar 2011
+Tags: godoc
+
+Andrew Gerrand
+
+* Introduction
+
+The Go project takes documentation seriously. Documentation is a huge part of making software accessible and maintainable. Of course it must be well-written and accurate, but it also must be easy to write and to maintain. Ideally, it should be coupled to the code itself so the documentation evolves along with the code. The easier it is for programmers to produce good documentation, the better for everyone.
+
+To that end, we have developed the [[http://golang.org/cmd/godoc/][godoc]] documentation tool. This article describes godoc's approach to documentation, and explains how you can use our conventions and tools to write good documentation for your own projects.
+
+Godoc parses Go source code - including comments - and produces documentation as HTML or plain text. The end result is documentation tightly coupled with the code it documents. For example, through godoc's web interface you can navigate from a function's [[http://golang.org/pkg/strings/#HasPrefix][documentation]] to its [[http://golang.org/src/pkg/strings/strings.go?#L312][implementation]] with one click.
+
+Godoc is conceptually related to Python's [[http://www.python.org/dev/peps/pep-0257/][Docstring]] and Java's [[http://www.oracle.com/technetwork/java/javase/documentation/index-jsp-135444.html][Javadoc]], but its design is simpler. The comments read by godoc are not language constructs (as with Docstring) nor must they have their own machine-readable syntax (as with Javadoc). Godoc comments are just good comments, the sort you would want to read even if godoc didn't exist.
+
+The convention is simple: to document a type, variable, constant, function, or even a package, write a regular comment directly preceding its declaration, with no intervening blank line. Godoc will then present that comment as text alongside the item it documents. For example, this is the documentation for the `fmt` package's [[http://golang.org/pkg/fmt/#Fprint][`Fprint`]] function:
+
+ // Fprint formats using the default formats for its operands and writes to w.
+ // Spaces are added between operands when neither is a string.
+ // It returns the number of bytes written and any write error encountered.
+ func Fprint(w io.Writer, a ...interface{}) (n int, err error) {
+
+Notice this comment is a complete sentence that begins with the name of the element it describes. This important convention allows us to generate documentation in a variety of formats, from plain text to HTML to UNIX man pages, and makes it read better when tools truncate it for brevity, such as when they extract the first line or sentence.
+
+Comments on package declarations should provide general package documentation. These comments can be short, like the [[http://golang.org/pkg/sort/][`sort`]] package's brief description:
+
+ // Package sort provides primitives for sorting slices and user-defined
+ // collections.
+ package sort
+
+They can also be detailed like the [[http://golang.org/pkg/encoding/gob/][gob package]]'s overview. That package uses another convention for packages that need large amounts of introductory documentation: the package comment is placed in its own file, [[http://golang.org/src/pkg/encoding/gob/doc.go][doc.go]], which contains only those comments and a package clause.
+
+When writing package comments of any size, keep in mind that their first sentence will appear in godoc's [[http://golang.org/pkg/][package list]].
+
+Comments that are not adjacent to a top-level declaration are omitted from godoc's output, with one notable exception. Top-level comments that begin with the word `"BUG(who)”` are recognized as known bugs, and included in the "Bugs” section of the package documentation. The "who” part should be the user name of someone who could provide more information. For example, this is a known issue from the [[http://golang.org/pkg/bytes/#bugs][bytes package]]:
+
+ // BUG(r): The rule Title uses for word boundaries does not handle Unicode punctuation properly.
+
+Godoc treats executable commands somewhat differently. Instead of inspecting the command source code, it looks for a Go source file belonging to the special package "documentation”. The comment on the "package documentation” clause is used as the command's documentation. For example, see the [[http://golang.org/cmd/godoc/][godoc documentation]] and its corresponding [[http://golang.org/src/cmd/godoc/doc.go][doc.go]] file.
+
+There are a few formatting rules that Godoc uses when converting comments to HTML:
+
+- Subsequent lines of text are considered part of the same paragraph; you must leave a blank line to separate paragraphs.
+
+- Pre-formatted text must be indented relative to the surrounding comment text (see gob's [[http://golang.org/src/pkg/encoding/gob/doc.go][doc.go]] for an example).
+
+- URLs will be converted to HTML links; no special markup is necessary.
+
+Note that none of these rules requires you to do anything out of the ordinary.
+
+In fact, the best thing about godoc's minimal approach is how easy it is to use. As a result, a lot of Go code, including all of the standard library, already follows the conventions.
+
+Your own code can present good documentation just by having comments as described above. Any Go packages installed inside `$GOROOT/src/pkg` and any `GOPATH` work spaces will already be accessible via godoc's command-line and HTTP interfaces, and you can specify additional paths for indexing via the `-path` flag or just by running `"godoc`."` in the source directory. See the [[http://golang.org/cmd/godoc/][godoc documentation]] for more details.
diff --git a/content/gos-declaration-syntax.article b/content/gos-declaration-syntax.article
new file mode 100644
index 0000000..e122550
--- /dev/null
+++ b/content/gos-declaration-syntax.article
@@ -0,0 +1,159 @@
+Go's Declaration Syntax
+7 Jul 2010
+Tags: c, syntax
+
+Rob Pike
+
+* Introduction
+
+Newcomers to Go wonder why the declaration syntax is different from the tradition established in the C family. In this post we'll compare the two approaches and explain why Go's declarations look as they do.
+
+* C syntax
+
+First, let's talk about C syntax. C took an unusual and clever approach to declaration syntax. Instead of describing the types with special syntax, one writes an expression involving the item being declared, and states what type that expression will have. Thus
+
+ int x;
+
+declares x to be an int: the expression 'x' will have type int. In general, to figure out how to write the type of a new variable, write an expression involving that variable that evaluates to a basic type, then put the basic type on the left and the expression on the right.
+
+Thus, the declarations
+
+ int *p;
+ int a[3];
+
+state that p is a pointer to int because '*p' has type int, and that a is an array of ints because a[3] (ignoring the particular index value, which is punned to be the size of the array) has type int.
+
+What about functions? Originally, C's function declarations wrote the types of the arguments outside the parens, like this:
+
+ int main(argc, argv)
+ int argc;
+ char *argv[];
+ { /* ... */ }
+
+Again, we see that main is a function because the expression main(argc, argv) returns an int. In modern notation we'd write
+
+ int main(int argc, char *argv[]) { /* ... */ }
+
+but the basic structure is the same.
+
+This is a clever syntactic idea that works well for simple types but can get confusing fast. The famous example is declaring a function pointer. Follow the rules and you get this:
+
+ int (*fp)(int a, int b);
+
+Here, fp is a pointer to a function because if you write the expression (*fp)(a, b) you'll call a function that returns int. What if one of fp's arguments is itself a function?
+
+ int (*fp)(int (*ff)(int x, int y), int b)
+
+That's starting to get hard to read.
+
+Of course, we can leave out the name of the parameters when we declare a function, so main can be declared
+
+ int main(int, char *[])
+
+Recall that argv is declared like this,
+
+ char *argv[]
+
+so you drop the name from the middle of its declaration to construct its type. It's not obvious, though, that you declare something of type char *[] by putting its name in the middle.
+
+And look what happens to fp's declaration if you don't name the parameters:
+
+ int (*fp)(int (*)(int, int), int)
+
+Not only is it not obvious where to put the name inside
+
+ int (*)(int, int)
+
+it's not exactly clear that it's a function pointer declaration at all. And what if the return type is a function pointer?
+
+ int (*(*fp)(int (*)(int, int), int))(int, int)
+
+It's hard even to see that this declaration is about fp.
+
+You can construct more elaborate examples but these should illustrate some of the difficulties that C's declaration syntax can introduce.
+
+There's one more point that needs to be made, though. Because type and declaration syntax are the same, it can be difficult to parse expressions with types in the middle. This is why, for instance, C casts always parenthesize the type, as in
+
+ (int)M_PI
+
+* Go syntax
+
+Languages outside the C family usually use a distinct type syntax in declarations. Although it's a separate point, the name usually comes first, often followed by a colon. Thus our examples above become something like (in a fictional but illustrative language)
+
+ x: int
+ p: pointer to int
+ a: array[3] of int
+
+These declarations are clear, if verbose - you just read them left to right. Go takes its cue from here, but in the interests of brevity it drops the colon and removes some of the keywords:
+
+ x int
+ p *int
+ a [3]int
+
+There is no direct correspondence between the look of [3]int and how to use a in an expression. (We'll come back to pointers in the next section.) You gain clarity at the cost of a separate syntax.
+
+Now consider functions. Let's transcribe the declaration for main, even though the main function in Go takes no arguments:
+
+ func main(argc int, argv *[]byte) int
+
+Superficially that's not much different from C, but it reads well from left to right:
+
+function main takes an int and a pointer to a slice of bytes and returns an int.
+
+Drop the parameter names and it's just as clear - they're always first so there's no confusion.
+
+ func main(int, *[]byte) int
+
+One value of this left-to-right style is how well it works as the types become more complex. Here's a declaration of a function variable (analogous to a function pointer in C):
+
+ f func(func(int,int) int, int) int
+
+Or if f returns a function:
+
+ f func(func(int,int) int, int) func(int, int) int
+
+It still reads clearly, from left to right, and it's always obvious which name is being declared - the name comes first.
+
+The distinction between type and expression syntax makes it easy to write and invoke closures in Go:
+
+ sum := func(a, b int) int { return a+b } (3, 4)
+
+* Pointers
+
+Pointers are the exception that proves the rule. Notice that in arrays and slices, for instance, Go's type syntax puts the brackets on the left of the type but the expression syntax puts them on the right of the expression:
+
+ var a []int
+ x = a[1]
+
+For familiarity, Go's pointers use the * notation from C, but we could not bring ourselves to make a similar reversal for pointer types. Thus pointers work like this
+
+ var p *int
+ x = *p
+
+We couldn't say
+
+ var p *int
+ x = p*
+
+because that postfix * would conflate with multiplication. We could have used the Pascal ^, for example:
+
+ var p ^int
+ x = p^
+
+and perhaps we should have (and chosen another operator for xor), because the prefix asterisk on both types and expressions complicates things in a number of ways. For instance, although one can write
+
+ []int("hi")
+
+as a conversion, one must parenthesize the type if it starts with a *:
+
+ (*int)(nil)
+
+Had we been willing to give up * as pointer syntax, those parentheses would be unnecessary.
+
+So Go's pointer syntax is tied to the familiar C form, but those ties mean that we cannot break completely from using parentheses to disambiguate types and expressions in the grammar.
+
+Overall, though, we believe Go's type syntax is easier to understand than C's, especially when things get complicated.
+
+* Notes
+
+Go's declarations read left to right. It's been pointed out that C's read in a spiral! See [[http://c-faq.com/decl/spiral.anderson.html][ The "Clockwise/Spiral Rule"]] by David Anderson.
diff --git a/content/introducing-go-playground.article b/content/introducing-go-playground.article
new file mode 100644
index 0000000..1229dd7
--- /dev/null
+++ b/content/introducing-go-playground.article
@@ -0,0 +1,16 @@
+Introducing the Go Playground
+15 Sep 2010
+Tags: release
+
+Andrew Gerrand
+
+* Introduction
+
+If you visit [[http://golang.org/][golang.org]] today you'll see our new look. We have given the site a new coat of paint and reorganized its content to make it easier to find. These changes are also reflected in the web interface of [[http://golang.org/cmd/godoc/][godoc]], the Go documentation tool.
+But the real news is a prominent new feature: the [[http://golang.org/][Go Playground]].
+.image introducing-go-playground_Untitled.png
+
+The Playground allows anyone with a web browser to write Go code that we immediately compile, link, and run on our servers. There are a few example programs to get you started (see the "Examples" drop-down). We hope that this will give curious programmers an opportunity to try the language before [[http://golang.org/doc/install.html][installing it]], and experienced Go users a convenient place in which to experiment. Beyond the front page, this functionality has the potential to make our reference and tutorial materials more engaging. We hope to extend its use in the near future.
+
+Of course, there are some limitations to the kinds of programs you can run in the Playground. We can't simply accept arbitrary code and run it on our servers without restrictions. The programs build and run in a sandbox with a reduced standard library; the only communication your program has to the outside world is via standard output, and there are limits to CPU and memory use. As such, consider this just a taste of the wonderful world of Go; to have the full experience you'll need to [[http://golang.org/doc/install.html][download it yourself]].
+If you've been meaning to try Go but never got around to it, why not visit [[http://golang.org/][golang.org]] to try it right now?
diff --git a/content/introducing-go-playground_Untitled.png b/content/introducing-go-playground_Untitled.png
new file mode 100644
index 0000000..1694893
--- /dev/null
+++ b/content/introducing-go-playground_Untitled.png
Binary files differ
diff --git a/content/introducing-gofix.article b/content/introducing-gofix.article
new file mode 100644
index 0000000..61655e8
--- /dev/null
+++ b/content/introducing-gofix.article
@@ -0,0 +1,55 @@
+Introducing Gofix
+15 Apr 2011
+Tags: gofix
+
+Russ Cox
+
+* Introduction
+
+The next Go release will include significant API changes in several fundamental Go packages. Code that [[http://codereview.appspot.com/4239076][implements an HTTP server handler]], [[http://codereview.appspot.com/4244055][calls `net.Dial`]], [[http://codereview.appspot.com/4357052][calls `os.Open`]], or [[http://codereview.appspot.com/4281055][uses the reflect package]] will not build unless it is updated to use the new APIs. Now that our releases are [[http://blog.golang.org/2011/03/go-becomes-more-stable.html][more stable and less frequent]], this will be a common situation. Each of these API changes happened in a different weekly snapshot and might have been manageable on its own; together, however, they represent a significant amount of manual effort to update existing code.
+
+[[http://goneat.org/cmd/gofix/][Gofix]] is a new tool that reduces the amount of effort it takes to update existing code. It reads a program from a source file, looks for uses of old APIs, rewrites them to use the current API, and writes the program back to the file. Not all API changes preserve all the functionality of an old API, so gofix cannot always do a perfect job. When gofix cannot rewrite a use of an old API, it prints a warning giving the file name and line number of the use, so that a developer can examine and rewrite the code. Gofix takes care of the easy, repetitive, tedious changes, so that a developer can focus on the ones that truly merit attention.
+
+Each time we make a significant API change we’ll add code to gofix to take care of the conversion, as much as mechanically possible. When you update to a new Go release and your code no longer builds, just run gofix on your source directory.
+
+You can extend gofix to support changes to your own APIs. The gofix program is a simple driver around plugins called fixes that each handle a particular API change. Right now, writing a new fix requires doing some scanning and rewriting of the go/ast syntax tree, usually in proportion to how complex the API changes are. If you want to explore, the [[http://code.google.com/p/go/source/browse/src/cmd/gofix/netdial.go][`netdialFix`]], [[http://code.google.com/p/go/source/browse/src/cmd/gofix/osopen.go][`osopenFix`]], [[http://code.google.com/p/go/source/browse/src/cmd/gofix/httpserver.go][`httpserverFix`]], and [[http://code.google.com/p/go/source/browse/src/cmd/gofix/reflect.go][`reflectFix`]] are all illustrative examples, in increasing order of complexity.
+
+We write Go code too, of course, and our code is just as affected by these API changes as yours. Typically, we write the gofix support at the same time as the API change and then use gofix to rewrite the uses in the main source tree. We use gofix to update other Go code bases and our personal projects. We even use gofix to update Google’s internal source tree when it is time to build against a new Go release.
+
+As an example, gofix can rewrite code like [[http://codereview.appspot.com/4353043/diff/10001/src/pkg/fmt/print.go#newcode657][this snippet from `fmt/print.go`]]:
+
+ switch f := value.(type) {
+ case *reflect.BoolValue:
+ p.fmtBool(f.Get(), verb, field)
+ case *reflect.IntValue:
+ p.fmtInt64(f.Get(), verb, field)
+ // ...
+ case reflect.ArrayOrSliceValue:
+ // Byte slices are special.
+ if f.Type().(reflect.ArrayOrSliceType).Elem().Kind() == reflect.Uint8 {
+ // ...
+ }
+ // ...
+ }
+
+to adapt it to the new reflect API:
+
+ switch f := value; f.Kind() {
+ case reflect.Bool:
+ p.fmtBool(f.Bool(), verb, field)
+ case reflect.Int, reflect.Int8, reflect.Int16, reflect.Int32, reflect.Int64:
+ p.fmtInt64(f.Int(), verb, field)
+ // ...
+ case reflect.Array, reflect.Slice:
+ // Byte slices are special.
+ if f.Type().Elem().Kind() == reflect.Uint8 {
+ // ...
+ }
+ // ...
+ }
+
+Nearly every line above changed in some small way. The changes involved in the rewrite are extensive but nearly entirely mechanical, just the kind of thing that computers are great at doing.
+
+Gofix is possible because Go has support in its standard libraries for [[http://golang.org/pkg/go/parser][parsing Go source files into syntax trees]] and also for [[http://golang.org/pkg/go/printer][printing those syntax trees back to Go source code]]. Importantly, the Go printing library prints a program in the official format (typically enforced via the gofmt tool), allowing gofix to make mechanical changes to Go programs without causing spurious formatting changes. In fact, one of the key motivations for creating gofmt—perhaps second only to avoiding debates about where a particular brace belongs—was to simplify the creation of tools that rewrite Go programs, as gofix does.
+
+Gofix has already made itself indispensable. In particular, the recent reflect changes would have been unpalatable without automated conversion, and the reflect API badly needed to be redone. Gofix gives us the ability to fix mistakes or completely rethink package APIs without worrying about the cost of converting existing code. We hope you find gofix as useful and convenient as we have.
diff --git a/content/json-and-go.article b/content/json-and-go.article
new file mode 100644
index 0000000..95730a8
--- /dev/null
+++ b/content/json-and-go.article
@@ -0,0 +1,253 @@
+JSON and Go
+25 Jan 2011
+Tags: json
+
+Andrew Gerrand
+
+* Introduction
+
+JSON (JavaScript Object Notation) is a simple data interchange format. Syntactically it resembles the objects and lists of JavaScript. It is most commonly used for communication between web back-ends and JavaScript programs running in the browser, but it is used in many other places, too. Its home page, [[http://json.org][json.org]], provides a wonderfully clear and concise definition of the standard.
+
+With the [[http://golang.org/pkg/encoding/json/][json package]] it's a snap to read and write JSON data from your Go programs.
+
+* Encoding
+
+To encode JSON data we use the [[http://golang.org/pkg/encoding/json/#Marshal][`Marshal`]] function.
+
+ func Marshal(v interface{}) ([]byte, error)
+
+Given the Go data structure, `Message`,
+
+ type Message struct {
+ Name string
+ Body string
+ Time int64
+ }
+
+and an instance of `Message`
+
+ m := Message{"Alice", "Hello", 1294706395881547000}
+
+we can marshal a JSON-encoded version of m using `json.Marshal`:
+
+ b, err := json.Marshal(m)
+
+If all is well, `err` will be `nil` and `b` will be a `[]byte` containing this JSON data:
+
+ b == []byte(`{"Name":"Alice","Body":"Hello","Time":1294706395881547000}`)
+
+Only data structures that can be represented as valid JSON will be encoded:
+
+- JSON objects only support strings as keys; to encode a Go map type it must be of the form `map[string]T` (where `T` is any Go type supported by the json package).
+
+- Channel, complex, and function types cannot be encoded.
+
+- Cyclic data structures are not supported; they will cause `Marshal` to go into an infinite loop.
+
+- Pointers will be encoded as the values they point to (or 'null' if the pointer is `nil`).
+
+The json package only accesses the exported fields of struct types (those that begin with an uppercase letter). Therefore only the the exported fields of a struct will be present in the JSON output.
+
+* Decoding
+
+To decode JSON data we use the [[http://golang.org/pkg/encoding/json/#Unmarshal][`Unmarshal`]] function.
+
+ func Unmarshal(data []byte, v interface{}) error
+
+We must first create a place where the decoded data will be stored
+
+ var m Message
+
+and call `json.Unmarshal`, passing it a `[]byte` of JSON data and a pointer to `m`
+
+ err := json.Unmarshal(b, &m)
+
+If `b` contains valid JSON that fits in `m`, after the call `err` will be `nil` and the data from `b` will have been stored in the struct `m`, as if by an assignment like:
+
+ m = Message{
+ Name: "Alice",
+ Body: "Hello",
+ Time: 1294706395881547000,
+ }
+
+How does `Unmarshal` identify the fields in which to store the decoded data? For a given JSON key `"Foo"`, `Unmarshal` will look through the destination struct's fields to find (in order of preference):
+
+- An exported field with a tag of `"Foo"` (see the [[http://golang.org/ref/spec#Struct_types][Go spec]] for more on struct tags),
+
+- An exported field named `"Foo"`, or
+
+- An exported field named `"FOO"` or `"FoO"` or some other case-insensitive match of `"Foo"`.
+
+What happens when the structure of the JSON data doesn't exactly match the Go type?
+
+ b := []byte(`{"Name":"Bob","Food":"Pickle"}`)
+ var m Message
+ err := json.Unmarshal(b, &m)
+
+`Unmarshal` will decode only the fields that it can find in the destination type. In this case, only the Name field of m will be populated, and the Food field will be ignored. This behavior is particularly useful when you wish to pick only a few specific fields out of a large JSON blob. It also means that any unexported fields in the destination struct will be unaffected by `Unmarshal`.
+
+But what if you don't know the structure of your JSON data beforehand?
+
+* Generic JSON with interface{}
+
+The `interface{}` (empty interface) type describes an interface with zero methods. Every Go type implements at least zero methods and therefore satisfies the empty interface.
+
+The empty interface serves as a general container type:
+
+ var i interface{}
+ i = "a string"
+ i = 2011
+ i = 2.777
+
+A type assertion accesses the underlying concrete type:
+
+ r := i.(float64)
+ fmt.Println("the circle's area", math.Pi*r*r)
+
+Or, if the underlying type is unknown, a type switch determines the type:
+
+ switch v := i.(type) {
+ case int:
+ fmt.Println("twice i is", v*2)
+ case float64:
+ fmt.Println("the reciprocal of i is", 1/v)
+ case string:
+ h := len(v) / 2
+ fmt.Println("i swapped by halves is", v[h:]+v[:h])
+ default:
+ // i isn't one of the types above
+ }
+
+The json package uses `map[string]interface{}` and
+`[]interface{}` values to store arbitrary JSON objects and arrays;
+it will happily unmarshal any valid JSON blob into a plain
+`interface{}` value. The default concrete Go types are:
+
+- `bool` for JSON booleans,
+
+- `float64` for JSON numbers,
+
+- `string` for JSON strings, and
+
+- `nil` for JSON null.
+
+* Decoding arbitrary data
+
+Consider this JSON data, stored in the variable `b`:
+
+ b := []byte(`{"Name":"Wednesday","Age":6,"Parents":["Gomez","Morticia"]}`)
+
+Without knowing this data's structure, we can decode it into an `interface{}` value with `Unmarshal`:
+
+ var f interface{}
+ err := json.Unmarshal(b, &f)
+
+At this point the Go value in `f` would be a map whose keys are strings and whose values are themselves stored as empty interface values:
+
+ f = map[string]interface{}{
+ "Name": "Wednesday",
+ "Age": 6,
+ "Parents": []interface{}{
+ "Gomez",
+ "Morticia",
+ },
+ }
+
+To access this data we can use a type assertion to access `f`'s underlying `map[string]interface{}`:
+
+ m := f.(map[string]interface{})
+
+We can then iterate through the map with a range statement and use a type switch to access its values as their concrete types:
+
+ for k, v := range m {
+ switch vv := v.(type) {
+ case string:
+ fmt.Println(k, "is string", vv)
+ case int:
+ fmt.Println(k, "is int", vv)
+ case []interface{}:
+ fmt.Println(k, "is an array:")
+ for i, u := range vv {
+ fmt.Println(i, u)
+ }
+ default:
+ fmt.Println(k, "is of a type I don't know how to handle")
+ }
+ }
+
+In this way you can work with unknown JSON data while still enjoying the benefits of type safety.
+
+* Reference Types
+
+Let's define a Go type to contain the data from the previous example:
+
+ type FamilyMember struct {
+ Name string
+ Age int
+ Parents []string
+ }
+
+ var m FamilyMember
+ err := json.Unmarshal(b, &m)
+
+Unmarshaling that data into a `FamilyMember` value works as expected, but if we look closely we can see a remarkable thing has happened. With the var statement we allocated a `FamilyMember` struct, and then provided a pointer to that value to `Unmarshal`, but at that time the `Parents` field was a `nil` slice value. To populate the `Parents` field, `Unmarshal` allocated a new slice behind the scenes. This is typical of how `Unmarshal` works with the supported reference types (pointers, slices, and maps).
+
+Consider unmarshaling into this data structure:
+
+ type Foo struct {
+ Bar *Bar
+ }
+
+If there were a `Bar` field in the JSON object, `Unmarshal` would allocate a new `Bar` and populate it. If not, `Bar` would be left as a `nil` pointer.
+
+From this a useful pattern arises: if you have an application that receives a few distinct message types, you might define "receiver" structure like
+
+ type IncomingMessage struct {
+ Cmd *Command
+ Msg *Message
+ }
+
+and the sending party can populate the `Cmd` field and/or the `Msg` field of the top-level JSON object, depending on the type of message they want to communicate. `Unmarshal`, when decoding the JSON into an `IncomingMessage` struct, will only allocate the data structures present in the JSON data. To know which messages to process, the programmer need simply test that either `Cmd` or `Msg` is not `nil`.
+
+* Streaming Encoders and Decoders
+
+The json package provides `Decoder` and `Encoder` types to support the common operation of reading and writing streams of JSON data. The `NewDecoder` and `NewEncoder` functions wrap the [[http://golang.org/pkg/io/#Reader][`io.Reader`]] and [[http://golang.org/pkg/io/#Writer][`io.Writer`]] interface types.
+
+ func NewDecoder(r io.Reader) *Decoder
+ func NewEncoder(w io.Writer) *Encoder
+
+Here's an example program that reads a series of JSON objects from standard input, removes all but the `Name` field from each object, and then writes the objects to standard output:
+
+ package main
+
+ import (
+ "encoding/json"
+ "log"
+ "os"
+ )
+
+ func main() {
+ dec := json.NewDecoder(os.Stdin)
+ enc := json.NewEncoder(os.Stdout)
+ for {
+ var v map[string]interface{}
+ if err := dec.Decode(&v); err != nil {
+ log.Println(err)
+ return
+ }
+ for k := range v {
+ if k != "Name" {
+ delete(v, k)
+ }
+ }
+ if err := enc.Encode(&v); err != nil {
+ log.Println(err)
+ }
+ }
+ }
+
+Due to the ubiquity of Readers and Writers, these `Encoder` and `Decoder` types can be used in a broad range of scenarios, such as reading and writing to HTTP connections, WebSockets, or files.
+
+* References
+
+For more information see the [[http://golang.org/pkg/encoding/json/][json package documentation]]. For an example usage of json see the source files of the [[http://golang.org/pkg/net/rpc/jsonrpc/][jsonrpc package]].
diff --git a/content/json-rpc-tale-of-interfaces.article b/content/json-rpc-tale-of-interfaces.article
new file mode 100644
index 0000000..435295d
--- /dev/null
+++ b/content/json-rpc-tale-of-interfaces.article
@@ -0,0 +1,36 @@
+JSON-RPC: a tale of interfaces
+27 Apr 2010
+Tags: json, rpc
+
+Andrew Gerrand
+
+* Introduction
+
+Here we present an example where Go's [[http://golang.org/doc/effective_go.html#interfaces_and_types][interfaces]] made it easy to refactor some existing code to make it more flexible and extensible. Originally, the standard library's [[http://golang.org/pkg/net/rpc/][RPC package]] used a custom wire format called [[http://golang.org/pkg/encoding/gob/][gob]]. For a particular application, we wanted to use [[http://golang.org/pkg/encoding/json/][JSON]] as an alternate wire format.
+
+We first defined a pair of interfaces to describe the functionality of the existing wire format, one for the client, and one for the server (depicted below).
+
+ type ServerCodec interface {
+ ReadRequestHeader(*Request) error
+ ReadRequestBody(interface{}) error
+ WriteResponse(*Response, interface{}) error
+ Close() error
+ }
+
+On the server side, we then changed two internal function signatures to accept the `ServerCodec` interface instead of our existing `gob.Encoder`. Here's one of them:
+
+ func sendResponse(sending *sync.Mutex, req *Request,
+ reply interface{}, enc *gob.Encoder, errmsg string)
+
+became
+
+ func sendResponse(sending *sync.Mutex, req *Request,
+ reply interface{}, enc ServerCodec, errmsg string)
+
+We then wrote a trivial `gobServerCodec` wrapper to reproduce the original functionality. From there it is simple to build a `jsonServerCodec`.
+
+After some similar changes to the client side, this was the full extent of the work we needed to do on the RPC package. This whole exercise took about 20 minutes! After tidying up and testing the new code, the [[http://code.google.com/p/go/source/diff?spec=svn9daf796ebf1cae97b2fcf760a4ab682f1f063f29&r=9daf796ebf1cae97b2fcf760a4ab682f1f063f29&format=side&path=/src/pkg/rpc/server.go][final changeset]] was submitted.
+
+In an inheritance-oriented language like Java or C++, the obvious path would be to generalize the RPC class, and create JsonRPC and GobRPC subclasses. However, this approach becomes tricky if you want to make a further generalization orthogonal to that hierarchy. (For example, if you were to implement an alternate RPC standard). In our Go package, we took a route that is both conceptually simpler and requires less code be written or changed.
+
+A vital quality for any codebase is maintainability. As needs change, it is essential to adapt your code easily and cleanly, lest it become unwieldy to work with. We believe Go's lightweight, composition-oriented type system provides a means of structuring code that scales.
diff --git a/content/laws-of-reflection.article b/content/laws-of-reflection.article
new file mode 100644
index 0000000..05d29b6
--- /dev/null
+++ b/content/laws-of-reflection.article
@@ -0,0 +1,334 @@
+The Laws of Reflection
+6 Sep 2011
+Tags: interface, reflect, type
+
+Rob Pike
+
+* Introduction
+
+Reflection in computing is the ability of a program to examine its own structure, particularly through types; it's a form of metaprogramming. It's also a great source of confusion.
+
+In this article we attempt to clarify things by explaining how reflection works in Go. Each language's reflection model is different (and many languages don't support it at all), but this article is about Go, so for the rest of this article the word "reflection" should be taken to mean "reflection in Go".
+
+* Types and interfaces
+
+Because reflection builds on the type system, let's start with a refresher about types in Go.
+
+Go is statically typed. Every variable has a static type, that is, exactly one type known and fixed at compile time: `int`, `float32`, `*MyType`, `[]byte`, and so on. If we declare
+
+ type MyInt int
+
+ var i int
+ var j MyInt
+
+then `i` has type `int` and `j` has type `MyInt`. The variables `i` and `j` have distinct static types and, although they have the same underlying type, they cannot be assigned to one another without a conversion.
+
+One important category of type is interface types, which represent fixed sets of methods. An interface variable can store any concrete (non-interface) value as long as that value implements the interface's methods. A well-known pair of examples is `io.Reader` and `io.Writer`, the types `Reader` and `Writer` from the [[http://golang.org/pkg/io/][io package]]:
+
+ // Reader is the interface that wraps the basic Read method.
+ type Reader interface {
+ Read(p []byte) (n int, err error)
+ }
+
+ // Writer is the interface that wraps the basic Write method.
+ type Writer interface {
+ Write(p []byte) (n int, err error)
+ }
+
+Any type that implements a `Read` (or `Write`) method with this signature is said to implement `io.Reader` (or `io.Writer`). For the purposes of this discussion, that means that a variable of type `io.Reader` can hold any value whose type has a `Read` method:
+
+ var r io.Reader
+ r = os.Stdin
+ r = bufio.NewReader(r)
+ r = new(bytes.Buffer)
+ // and so on
+
+It's important to be clear that whatever concrete value `r` may hold, `r`'s type is always `io.Reader`: Go is statically typed and the static type of `r` is `io.Reader`.
+
+An extremely important example of an interface type is the empty interface:
+
+ interface{}
+
+It represents the empty set of methods and is satisfied by any value at all, since any value has zero or more methods.
+
+Some people say that Go's interfaces are dynamically typed, but that is misleading. They are statically typed: a variable of interface type always has the same static type, and even though at run time the value stored in the interface variable may change type, that value will always satisfy the interface.
+
+We need to be precise about all this because reflection and interfaces are closely related.
+
+* The representation of an interface
+
+Russ Cox has written a [[http://research.swtch.com/2009/12/go-data-structures-interfaces.html][ detailed blog post]] about the representation of interface values in Go. It's not necessary to repeat the full story here, but a simplified summary is in order.
+
+A variable of interface type stores a pair: the concrete value assigned to the variable, and that value's type descriptor. To be more precise, the value is the underlying concrete data item that implements the interface and the type describes the full type of that item. For instance, after
+
+ var r io.Reader
+ tty, err := os.OpenFile("/dev/tty", os.O_RDWR, 0)
+ if err != nil {
+ return nil, err
+ }
+ r = tty
+
+`r` contains, schematically, the (value, type) pair, (`tty`, `*os.File`). Notice that the type `*os.File` implements methods other than `Read`; even though the interface value provides access only to the `Read` method, the value inside carries all the type information about that value. That's why we can do things like this:
+
+ var w io.Writer
+ w = r.(io.Writer)
+
+The expression in this assignment is a type assertion; what it asserts is that the item inside `r` also implements `io.Writer`, and so we can assign it to `w`. After the assignment, `w` will contain the pair (`tty`, `*os.File`). That's the same pair as was held in `r`. The static type of the interface determines what methods may be invoked with an interface variable, even though the concrete value inside may have a larger set of methods.
+
+Continuing, we can do this:
+
+ var empty interface{}
+ empty = w
+
+and our empty interface value `e` will again contain that same pair, (`tty`, `*os.File`). That's handy: an empty interface can hold any value and contains all the information we could ever need about that value.
+
+(We don't need a type assertion here because it's known statically that `w` satisfies the empty interface. In the example where we moved a value from a `Reader` to a `Writer`, we needed to be explicit and use a type assertion because `Writer`'s methods are not a subset of `Reader`'s.)
+
+One important detail is that the pair inside an interface always has the form (value, concrete type) and cannot have the form (value, interface type). Interfaces do not hold interface values.
+
+Now we're ready to reflect.
+
+* The first law of reflection
+
+* 1. Reflection goes from interface value to reflection object.
+
+At the basic level, reflection is just a mechanism to examine the type and value pair stored inside an interface variable. To get started, there are two types we need to know about in [[http://golang.org/pkg/reflect/][package reflect]]: [[http://golang.org/pkg/reflect/#Type][Type]] and [[http://golang.org/pkg/reflect/#Value][Value]]. Those two types give access to the contents of an interface variable, and two simple functions, called `reflect.TypeOf` and `reflect.ValueOf`, retrieve `reflect.Type` and `reflect.Value` pieces out of an interface value. (Also, from the `reflect.Value` it's easy to get to the `reflect.Type`, but let's keep the `Value` and `Type` concepts separate for now.)
+
+Let's start with `TypeOf`:
+
+ package main
+
+ import (
+ "fmt"
+ "reflect"
+ )
+
+ func main() {
+ var x float64 = 3.4
+ fmt.Println("type:", reflect.TypeOf(x))
+ }
+
+This program prints
+
+ type: float64
+
+You might be wondering where the interface is here, since the program looks like it's passing the `float64` variable `x`, not an interface value, to `reflect.TypeOf`. But it's there; as [[http://golang.org/pkg/reflect/#Type.TypeOf][godoc reports]], the signature of `reflect.TypeOf` includes an empty interface:
+
+ // TypeOf returns the reflection Type of the value in the interface{}.
+ func TypeOf(i interface{}) Type
+
+When we call `reflect.TypeOf(x)`, `x` is first stored in an empty interface, which is then passed as the argument; `reflect.TypeOf` unpacks that empty interface to recover the type information.
+
+The `reflect.ValueOf` function, of course, recovers the value (from here on we'll elide the boilerplate and focus just on the executable code):
+
+ var x float64 = 3.4
+ fmt.Println("value:", reflect.ValueOf(x))
+
+prints
+
+ value: <float64 Value>
+
+Both `reflect.Type` and `reflect.Value` have lots of methods to let us examine and manipulate them. One important example is that `Value` has a `Type` method that returns the `Type` of a `reflect.Value`. Another is that both `Type` and `Value` have a `Kind` method that returns a constant indicating what sort of item is stored: `Uint`, `Float64`, `Slice`, and so on. Also methods on `Value` with names like `Int` and `Float` let us grab values (as `int64` and `float64`) stored inside:
+
+ var x float64 = 3.4
+ v := reflect.ValueOf(x)
+ fmt.Println("type:", v.Type())
+ fmt.Println("kind is float64:", v.Kind() == reflect.Float64)
+ fmt.Println("value:", v.Float())
+
+prints
+
+ type: float64
+ kind is float64: true
+ value: 3.4
+
+There are also methods like `SetInt` and `SetFloat` but to use them we need to understand settability, the subject of the third law of reflection, discussed below.
+
+The reflection library has a couple of properties worth singling out. First, to keep the API simple, the "getter" and "setter" methods of `Value` operate on the largest type that can hold the value: `int64` for all the signed integers, for instance. That is, the `Int` method of `Value` returns an `int64` and the `SetInt` value takes an `int64`; it may be necessary to convert to the actual type involved:
+
+ var x uint8 = 'x'
+ v := reflect.ValueOf(x)
+ fmt.Println("type:", v.Type()) // uint8.
+ fmt.Println("kind is uint8: ", v.Kind() == reflect.Uint8) // true.
+ x = uint8(v.Uint()) // v.Uint returns a uint64.
+
+The second property is that the `Kind` of a reflection object describes the underlying type, not the static type. If a reflection object contains a value of a user-defined integer type, as in
+
+ type MyInt int
+ var x MyInt = 7
+ v := reflect.ValueOf(x)
+
+the `Kind` of `v` is still `reflect.Int`, even though the static type of `x` is `MyInt`, not `int`. In other words, the `Kind` cannot discriminate an int from a `MyInt` even though the `Type` can.
+
+* The second law of reflection
+
+*2.*Reflection*goes*from*reflection*object*to*interface value.*
+
+Like physical reflection, reflection in Go generates its own inverse.
+
+Given a `reflect.Value` we can recover an interface value using the `Interface` method; in effect the method packs the type and value information back into an interface representation and returns the result:
+
+ // Interface returns v's value as an interface{}.
+ func (v Value) Interface() interface{}
+
+As a consequence we can say
+
+ y := v.Interface().(float64) // y will have type float64.
+ fmt.Println(y)
+
+to print the `float64` value represented by the reflection object `v`.
+
+We can do even better, though. The arguments to `fmt.Println`, `fmt.Printf` and so on are all passed as empty interface values, which are then unpacked by the `fmt` package internally just as we have been doing in the previous examples. Therefore all it takes to print the contents of a `reflect.Value` correctly is to pass the result of the `Interface` method to the formatted print routine:
+
+ fmt.Println(v.Interface())
+
+(Why not `fmt.Println(v)`? Because `v` is a `reflect.Value`; we want the concrete value it holds.) Since our value is a `float64`, we can even use a floating-point format if we want:
+
+ fmt.Printf("value is %7.1e\n", v.Interface())
+
+and get in this case
+
+ 3.4e+00
+
+Again, there's no need to type-assert the result of `v.Interface()` to `float64`; the empty interface value has the concrete value's type information inside and `Printf` will recover it.
+
+In short, the `Interface` method is the inverse of the `ValueOf` function, except that its result is always of static type `interface{}`.
+
+Reiterating: Reflection goes from interface values to reflection objects and back again.
+
+* The third law of reflection
+
+* 3. To modify a reflection object, the value must be settable.
+
+The third law is the most subtle and confusing, but it's easy enough to understand if we start from first principles.
+
+Here is some code that does not work, but is worth studying.
+
+ var x float64 = 3.4
+ v := reflect.ValueOf(x)
+ v.SetFloat(7.1) // Error: will panic.
+
+If you run this code, it will panic with the cryptic message
+
+ panic: reflect.Value.SetFloat using unaddressable value
+
+The problem is not that the value `7.1` is not addressable; it's that `v` is not settable. Settability is a property of a reflection `Value`, and not all reflection `Values` have it.
+
+The `CanSet` method of `Value` reports the settability of a `Value`; in our case,
+
+ var x float64 = 3.4
+ v := reflect.ValueOf(x)
+ fmt.Println("settability of v:", v.CanSet())
+
+prints
+
+ settability of v: false
+
+It is an error to call a `Set` method on an non-settable `Value`. But what is settability?
+
+Settability is a bit like addressability, but stricter. It's the property that a reflection object can modify the actual storage that was used to create the reflection object. Settability is determined by whether the reflection object holds the original item. When we say
+
+ var x float64 = 3.4
+ v := reflect.ValueOf(x)
+
+we pass a copy of `x` to `reflect.ValueOf`, so the interface value created as the argument to `reflect.ValueOf` is a copy of `x`, not `x` itself. Thus, if the statement
+
+ v.SetFloat(7.1)
+
+were allowed to succeed, it would not update `x`, even though `v` looks like it was created from `x`. Instead, it would update the copy of `x` stored inside the reflection value and `x` itself would be unaffected. That would be confusing and useless, so it is illegal, and settability is the property used to avoid this issue.
+
+If this seems bizarre, it's not. It's actually a familiar situation in unusual garb. Think of passing `x` to a function:
+
+ f(x)
+
+We would not expect `f` to be able to modify `x` because we passed a copy of `x`'s value, not `x` itself. If we want `f` to modify `x` directly we must pass our function the address of `x` (that is, a pointer to `x`):
+
+`f(&x)`
+
+This is straightforward and familiar, and reflection works the same way. If we want to modify `x` by reflection, we must give the reflection library a pointer to the value we want to modify.
+
+Let's do that. First we initialize `x` as usual and then create a reflection value that points to it, called `p`.
+
+ var x float64 = 3.4
+ p := reflect.ValueOf(&x) // Note: take the address of x.
+ fmt.Println("type of p:", p.Type())
+ fmt.Println("settability of p:", p.CanSet())
+
+The output so far is
+
+ type of p: *float64
+ settability of p: false
+
+The reflection object `p` isn't settable, but it's not `p` we want to set, it's (in effect) `*p`. To get to what `p` points to, we call the `Elem` method of `Value`, which indirects through the pointer, and save the result in a reflection `Value` called `v`:
+
+ v := p.Elem()
+ fmt.Println("settability of v:", v.CanSet())
+
+Now `v` is a settable reflection object, as the output demonstrates,
+
+ settability of v: true
+
+and since it represents `x`, we are finally able to use `v.SetFloat` to modify the value of `x`:
+
+ v.SetFloat(7.1)
+ fmt.Println(v.Interface())
+ fmt.Println(x)
+
+The output, as expected, is
+
+ 7.1
+ 7.1
+
+Reflection can be hard to understand but it's doing exactly what the language does, albeit through reflection `Types` and `Values` that can disguise what's going on. Just keep in mind that reflection Values need the address of something in order to modify what they represent.
+
+* Structs
+
+In our previous example `v` wasn't a pointer itself, it was just derived from one. A common way for this situation to arise is when using reflection to modify the fields of a structure. As long as we have the address of the structure, we can modify its fields.
+
+Here's a simple example that analyzes a struct value, `t`. We create the reflection object with the address of the struct because we'll want to modify it later. Then we set `typeOfT` to its type and iterate over the fields using straightforward method calls (see [[http://golang.org/pkg/reflect/][package reflect]] for details). Note that we extract the names of the fields from the struct type, but the fields themselves are regular `reflect.Value` objects.
+
+ type T struct {
+ A int
+ B string
+ }
+ t := T{23, "skidoo"}
+ s := reflect.ValueOf(&t).Elem()
+ typeOfT := s.Type()
+ for i := 0; i < s.NumField(); i++ {
+ f := s.Field(i)
+ fmt.Printf("%d: %s %s = %v\n", i,
+ typeOfT.Field(i).Name, f.Type(), f.Interface())
+ }
+
+The output of this program is
+
+ 0: A int = 23
+ 1: B string = skidoo
+
+There's one more point about settability introduced in passing here: the field names of `T` are upper case (exported) because only exported fields of a struct are settable.
+
+Because `s` contains a settable reflection object, we can modify the fields of the structure.
+
+ s.Field(0).SetInt(77)
+ s.Field(1).SetString("Sunset Strip")
+ fmt.Println("t is now", t)
+
+And here's the result:
+
+ t is now {77 Sunset Strip}
+
+If we modified the program so that `s` was created from `t`, not `&t`, the calls to `SetInt` and `SetString` would fail as the fields of `t` would not be settable.
+
+* Conclusion
+
+Here again are the laws of reflection:
+
+- Reflection goes from interface value to reflection object.
+
+- Reflection goes from reflection object to interface value.
+
+- To modify a reflection object, the value must be settable.
+
+Once you understand these laws reflection in Go becomes much easier to use, although it remains subtle. It's a powerful tool that should be used with care and avoided unless strictly necessary.
+
+There's plenty more to reflection that we haven't covered — sending and receiving on channels, allocating memory, using slices and maps, calling methods and functions — but this post is long enough. We'll cover some of those topics in a later article.
diff --git a/content/learn-go-from-your-browser.article b/content/learn-go-from-your-browser.article
new file mode 100644
index 0000000..98ddd24
--- /dev/null
+++ b/content/learn-go-from-your-browser.article
@@ -0,0 +1,15 @@
+Learn Go from your browser
+4 Oct 2011
+Tags: learn, playground, tour
+
+Andrew Gerrand
+
+* Introduction
+
+We are excited to announce [[http://go-tour.appspot.com/][A Tour of Go]], a guided tour of the Go programming language you can run from your browser.
+
+The tour is hands-on, demonstrating the language through code samples that you can modify, compile, and run from the tour itself. (The technology behind the [[http://golang.org/doc/play/][Go Playground]] does the work.)
+
+The tour has three sections. The first section covers basic syntax and data structures; the second discusses methods and interfaces; and the third introduces Go's concurrency primitives. Each section concludes with a few exercises so you can practice what you've learned.
+
+So, what are you waiting for? [[http://go-tour.appspot.com/][Get started now!]]
diff --git a/content/new-talk-and-tutorials.article b/content/new-talk-and-tutorials.article
new file mode 100644
index 0000000..608c47a
--- /dev/null
+++ b/content/new-talk-and-tutorials.article
@@ -0,0 +1,12 @@
+New Talk and Tutorials
+5 May 2010
+
+Andrew Gerrand
+
+* Introduction
+
+Rob Pike recently gave a talk at Stanford's [[http://www.stanford.edu/class/ee380/][Computer Systems Colloquium]] (EE380). Titled [[http://www.stanford.edu/class/ee380/Abstracts/100428.html][_Another_Go_at_Language_Design_]], the presentation gives an overview of the itches Go was built to scratch, and how Go addresses those problems. You can view [[http://stanford-online.stanford.edu/courses/ee380/100428-ee380-300.asx][a video stream of the talk]], and [[http://www.stanford.edu/class/ee380/Abstracts/100428-pike-stanford.pdf][download the slides]].
+
+Last week's release included a code lab, [[http://golang.org/doc/codelab/wiki/][Writing Web Applications]], that details the construction of a simple wiki program. It is a practical introduction to some fundamental Go concepts, and the first of a series of Go code labs.
+
+Lastly, we are often asked "How do Go packages work?" It's easier to show than to explain, so I put together a [[http://www.youtube.com/watch?v=jDWBJOXs_iI][Go Packages screen cast]] that demonstrates the process of writing, building, installing, and redistributing Go packages. I hope to post more of these covering a variety of Go programming topics to the [[http://youtube.com/gocoding][gocoding YouTube channel]] in the near future.
diff --git a/content/organizing-go-code.article b/content/organizing-go-code.article
new file mode 100644
index 0000000..abfb807
--- /dev/null
+++ b/content/organizing-go-code.article
@@ -0,0 +1,53 @@
+Organizing Go code
+16 Aug 2012
+Tags: godoc, gopath, interface, libraries
+
+Andrew Gerrand
+
+* Introduction
+
+Go code is organized differently to that of other languages. This post discusses how to name and package the elements of your Go program to best serve its users.
+
+* Choose good names
+
+The names you choose affect how you think about your code, so take care when naming your package and its exported identifiers.
+
+A package's name provides context for its contents. For instance, the [[http://golang.org/pkg/bytes/][bytes package]] from the standard library exports the `Buffer` type. On its own, the name `Buffer` isn't very descriptive, but when combined with its package name its meaning becomes clear: `bytes.Buffer`. If the package had a less descriptive name, like `util`, the buffer would likely acquire the longer and clumsier name `util.BytesBuffer`.
+
+Don't be shy about renaming things as you work. As you spend time with your program you will better understand how its pieces fit together and, therefore, what their names should be. There's no need to lock yourself into early decisions. (The [[http://golang.org/cmd/gofmt/][gofmt command]] has a `-r` flag that provides a syntax-aware search and replace, making large-scale refactoring easier.)
+
+A good name is the most important part of a software interface: the name is the first thing every client of the code will see. A well-chosen name is therefore the starting point for good documentation. Many of the following practices result organically from good naming.
+
+* Choose a good import path (make your package "go get"-able)
+
+An import path is the string with which users import a package. It specifies the directory (relative to `$GOROOT/src/pkg` or `$GOPATH/src`) in which the package's source code resides.
+
+Import paths should be globally unique, so use the path of your source repository as its base. For instance, the `websocket` package from the `go.net` sub-repository has an import path of `"code.google.com/p/go.net/websocket"`. The Go project owns the path `"code.google.com/p/go"`, so that path cannot be used by another author for a different package. Because the repository URL and import path are one and the same, the `go`get` command can fetch and install the package automatically.
+
+If you don't use a hosted source repository, choose some unique prefix such as a domain, company, or project name. As an example, the import path of all Google's internal Go code starts with the string `"google"`.
+
+The last element of the import path is typically the same as the package name. For instance, the import path `"net/http"` contains package `http`. This is not a requirement - you can make them different if you like - but you should follow the convention for predictability's sake: a user might be surprised that import `"foo/bar"` introduces the identifier `quux` into the package name space.
+
+Sometimes people set `GOPATH` to the root of their source repository and put their packages in directories relative to the repository root, such as `"src/my/package"`. On one hand, this keeps the import paths short (`"my/package"` instead of `"github.com/me/project/my/package"`), but on the other it breaks `go`get` and forces users to re-set their `GOPATH` to use the package. Don't do this.
+
+* Minimize the exported interface
+
+Your code is likely composed of many small pieces of useful code, and so it is tempting to expose much of that functionality in your package's exported interface. Resist that urge!
+
+The larger the interface you provide, the more you must support. Users will quickly come to depend on every type, function, variable, and constant you export, creating an implicit contract that you must honor in perpetuity or risk breaking your users' programs. In preparing Go 1 we carefully reviewed the standard library's exported interfaces and removed the parts we weren't ready to commit to. You should take similar care when distributing your own libraries.
+
+If in doubt, leave it out!
+
+* What to put into a package
+
+It is easy to just throw everything into a "grab bag" package, but this dilutes the meaning of the package name (as it must encompass a lot of functionality) and forces the users of small parts of the package to compile and link a lot of unrelated code.
+
+On the other hand, it is also easy to go overboard in splitting your code into small packages, in which case you will likely becomes bogged down in interface design, rather than just getting the job done.
+
+Look to the Go standard libraries as a guide. Some of its packages are large and some are small. For instance, the [[http://golang.org/pkg/net/http/][http package]] comprises 17 go source files (excluding tests) and exports 109 identifiers, and the [[http://golang.org/pkg/hash/][hash package]] consists of one file that exports just three declarations. There is no hard and fast rule; both approaches are appropriate given their context.
+
+With that said, package main is often larger than other packages. Complex commands contain a lot of code that is of little use outside the context of the executable, and often it's simpler to just keep it all in the one place. Godoc is nearly 6000 lines over [[http://golang.org/src/cmd/godoc/][16 files]], and the go tool is more than 7000 lines spread across [[http://golang.org/src/cmd/go/][23 files]].
+
+* Document your code
+
+Good documentation is an essential quality of usable and maintainable code. Read the [[http://golang.org/doc/articles/godoc_documenting_go_code.html][Godoc: documenting Go code]] article to learn how to write good doc comments.
diff --git a/content/preview-of-go-version-1.article b/content/preview-of-go-version-1.article
new file mode 100644
index 0000000..7d4328a
--- /dev/null
+++ b/content/preview-of-go-version-1.article
@@ -0,0 +1,19 @@
+A preview of Go version 1
+5 Oct 2011
+Tags: v1
+
+Russ Cox
+
+* Introduction
+
+We want to be able to provide a stable base for people using Go. People should be able to write Go programs and expect that they will continue to compile and run without change, on a timescale of years. Similarly, people should be able to write books about Go, be able to say which version of Go the book is describing, and have that version number still be meaningful much later. None of these properties is true for Go today.
+
+We propose to issue a Go release early next year that will be called “Go version 1”, Go 1 for short, that will be the first Go release to be stable in this way. Code that compiles in Go version 1 should, with few exceptions, continue to compile throughout the lifetime of that version, as we issue updates and bug fixes such as Go version 1.1, 1.2, and so on. It will also be maintained with fixes for bugs and security flaws even as other versions may evolve. Also, production environments such as Google App Engine will support it for an extended time.
+
+Go version 1 will be a stable language with stable libraries. Other than critical fixes, changes made to the library and packages for versions 1.1, 1.2 and so on may add functionality but will not break existing Go version 1 programs.
+
+Our goal is for Go 1 to be a stable version of today’s Go, not a wholesale rethinking of the language. In particular, we are explicitly resisting any efforts to design new language features “by committee.”
+
+However, there are various changes to the Go language and packages that we have intended for some time and prototyped but have not deployed yet, primarily because they are significant and backwards-incompatible. If Go 1 is to be long-lasting, it is important that we plan, announce, implement, and test these changes as part of the preparation of Go 1, rather than delay them until after it is released and thereby introduce divergence that contradicts our goals.
+
+Today, we are publishing our preliminary [[https://docs.google.com/document/pub?id=1ny8uI-_BHrDCZv_zNBSthNKAMX_fR_0dc6epA6lztRE][plan for Go 1]] for feedback from the Go community. If you have feedback, please reply to the [[http://groups.google.com/group/golang-nuts/browse_thread/thread/badc4f323431a4f6][thread on the golang-nuts mailing list]].
diff --git a/content/profiling-go-programs.article b/content/profiling-go-programs.article
new file mode 100644
index 0000000..87c3740
--- /dev/null
+++ b/content/profiling-go-programs.article
@@ -0,0 +1,451 @@
+Profiling Go Programs
+24 Jun 2011
+Tags: benchmark, optimization, pprof, profiling
+
+Russ Cox
+
+* Introduction
+
+At Scala Days 2011 a few weeks ago, Robert Hundt presented a paper titled [[http://research.google.com/pubs/pub37122.html][Loop Recognition in C++/Java/Go/Scala.]] The paper implemented a specific loop finding algorithm, such as you might use in a flow analysis pass of a compiler, in C++, Go, Java, Scala, and then used those programs to draw conclusions about typical performance concerns in these languages. The Go program presented in that paper runs quite slowly, making it an excellent opportunity to demonstrate how to use Go's profiling tools to take a slow program and make it faster.
+
+_By_using_Go's_profiling_tools_to_identify_and_correct_specific_bottlenecks,_we_can_make_the_Go_loop_finding_program_run_an_order_of_magnitude_faster_and_use_6x_less_memory._
+
+Hundt's paper does not specify which versions of the C++, Go, Java, and Scala tools he used. In this blog post, we will be using the most recent weekly snapshot of the `6g` Go compiler and the version of `g++` that ships with the Ubuntu Natty distribution. (We will not be using Java or Scala, because we are not skilled at writing efficient programs in either of those languages, so the comparison would be unfair. Since C++ was the fastest language in the paper, the comparisons here with C++ should suffice.)
+
+ $ 6g -V
+ 6g version weekly.2011-06-16 8787
+ $ g++ --version
+ g++ (Ubuntu/Linaro 4.5.2-8ubuntu4) 4.5.2
+ ...
+ $
+
+The programs are run on a Lenovo X201s with a 2.13 GHz Core i7-based CPU and 4 GB of RAM running Ubuntu Natty's Linux 2.6.38-8-generic kernel. The machine is running with CPU frequency scaling disabled via
+
+ $ sudo bash
+ # for i in /sys/devices/system/cpu/cpu[0-9]
+ do
+ echo performance > $i/cpufreq/scaling_governor
+ done
+ #
+
+We've taken [[http://code.google.com/p/multi-language-bench/][Hundt's benchmark programs]] in C++ and Go, combined each into a single source file, and removed all but one line of output. We'll time the program using Linux's `time` utility with a format that shows user time, system time, real time, and maximum memory usage:
+
+ $ cat xtime
+ #!/bin/sh
+ /usr/bin/time -f '%Uu %Ss %er %MkB %C' "$@"
+ $
+
+ $ make havlak1cc
+ g++ -O3 -o havlak1cc havlak1.cc
+ $ xtime havlak1cc
+ # of loops: 76002 (total 3800100)
+ loop-0, nest: 0, depth: 0
+ 27.37u 0.08s *27.47r*716864kB*havlak1cc*
+ $
+
+ $ make havlak1
+ 6g havlak1.go
+ 6l -o havlak1 havlak1.6
+ $ xtime havlak1
+ # of loops: 76000 (including 1 artificial root node)
+ 56.63u 0.26s *56.92r*1642640kB*havlak1*
+ $
+
+The C++ program runs in 27.47 seconds and uses 700 MB of memory. The Go program runs in 56.92 seconds and uses 1604 MB of memory. (These measurements are difficult to reconcile with the ones in the paper, but the point of this post is to explore how to use `gopprof`, not to reproduce the results from the paper.)
+
+To start tuning the Go program, we have to enable profiling. If the code used the [[http://golang.org/pkg/testing/][Go testing package]]'s benchmarking support, we could use gotest's standard `-cpuprofile` and `-memprofile` flags. In a standalone program like this one, we have to import `runtime/pprof` and add a few lines of code:
+
+ var cpuprofile = flag.String("cpuprofile", "", "write cpu profile to file")
+
+ func main() {
+ flag.Parse()
+ if *cpuprofile != "" {
+ f, err := os.Create(*cpuprofile)
+ if err != nil {
+ log.Fatal(err)
+ }
+ pprof.StartCPUProfile(f)
+ defer pprof.StopCPUProfile()
+ }
+ ...
+
+The new code defines a flag named `cpuprofile`, calls the [[http://golang.org/pkg/flag/][Go flag library]] to parse the command line flags, and then, if the `cpuprofile` flag has been set on the command line, [[http://golang.org/pkg/runtime/pprof/#StartCPUProfile][starts CPU profiling]] redirected to that file. The profiler requires a final call to [[http://golang.org/pkg/runtime/pprof/#StopCPUProfile][`StopCPUProfile`]] to flush any pending writes to the file before the program exits; we use `defer` to make sure this happens as `main` returns.
+
+After adding that code, we can run the program with the new `-cpuprofile` flag and then run `gopprof` to interpret the profile.
+
+ $ make havlak1.prof
+ havlak1 -cpuprofile=havlak1.prof
+ # of loops: 76000 (including 1 artificial root node)
+ $ gopprof havlak1 havlak1.prof
+ Welcome to pprof! For help, type 'help'.
+ (pprof)
+
+The `gopprof` program is a slight variant of [[http://code.google.com/p/google-perftools/wiki/GooglePerformanceTools][Google's `pprof` C++ profiler]]. The most important command is `topN`, which shows the top `N` samples in the profile:
+
+ (pprof) top10
+ Total: 5758 samples
+ 1028 17.9% 17.9% 1161 20.2% hash_lookup
+ 696 12.1% 29.9% 697 12.1% scanblock
+ 565 9.8% 39.8% 1042 18.1% hash_insert_internal
+ 420 7.3% 47.0% 4278 74.3% main.FindLoops
+ 225 3.9% 51.0% 1149 20.0% main.DFS
+ 225 3.9% 54.9% 226 3.9% memhash
+ 198 3.4% 58.3% 437 7.6% sweep
+ 172 3.0% 61.3% 1902 33.0% runtime.mallocgc
+ 102 1.8% 63.1% 500 8.7% runtime.MCache_Alloc
+ 102 1.8% 64.8% 102 1.8% runtime.memmove
+ (pprof)
+
+When CPU profiling is enabled, the Go program stops about 100 times per second and records a sample consisting of the program counters on the currently executing goroutine's stack. The profile has 5758 samples, so it was running for a bit over 57 seconds. In the `gopprof` output, there is a row for each function that appeared in a sample. The first two columns show the number of samples in which the function was running (as opposed to waiting for a called function to return), as a raw count and as a percentage of total samples. The `hash_lookup` function was running during 1028 samples, or 17.9%. The `top10` output is sorted by this sample count. The third column shows the running total during the listing: the first three rows account for 39.8% of the samples. The fourth and fifth columns show the number of samples in which the function appeared (either running or waiting for a called function to return). The `main.FindLoops` function was running in 7.3% of the samples, but it was on the call stack (it or functions it called were running) in 74.3% of the samples.
+
+To sort by the fourth and fifth columns, use the `-cum` (for cumulative) flag:
+
+ (pprof) top5 -cum
+ Total: 5758 samples
+ 0 0.0% 0.0% 4301 74.7% main.main
+ 0 0.0% 0.0% 4301 74.7% runtime.initdone
+ 0 0.0% 0.0% 4301 74.7% runtime.mainstart
+ 0 0.0% 0.0% 4278 74.3% main.FindHavlakLoops
+ 420 7.3% 7.3% 4278 74.3% main.FindLoops
+ (pprof)
+
+In fact the total for `main.FindLoops` and `main.main` should have been 100%, but each stack sample only includes the bottom 100 stack frames; during about a quarter of the samples, the recursive `main.DFS` function was more than 100 frames deeper than `main.main` so the complete trace was truncated.
+
+The stack trace samples contain more interesting data about function call relationships than the text listings can show. The `web` command writes a graph of the profile data in SVG format and opens it in a web browser. (There is also a `gv` command that writes PostScript and opens it in Ghostview. For either command, you need [[http://www.graphviz.org/][graphviz]] installed.)
+
+ (pprof) web
+
+A small fragment of [[http://benchgraffiti.googlecode.com/hg/havlak/havlak1.svg][the full graph]] looks like:
+
+.image profiling-go-programs_havlak1a-75.png
+
+Each box in the graph corresponds to a single function, and the boxes are sized according to the number of samples in which the function was running. An edge from box X to box Y indicates that X calls Y; the number along the edge is the number of times that call appears in a sample. If a call appears multiple times in a single sample, such as during recursive function calls, each appearance counts toward the edge weight. That explains the 69206 on the self-edge from `main.DFS` to itself.
+
+Just at a glance, we can see that the program spends much of its time in hash operations, which correspond to use of Go's `map` values. We can tell `web` to use only samples that include a specific function, such as `hash_lookup`, which clears some of the noise from the graph:
+
+ (pprof) web hash lookup
+
+.image profiling-go-programs_havlak1-hash_lookup-75.png
+
+If we squint, we can see that the calls to `runtime.mapaccess1` are being made by `main.FindLoops` and `main.DFS`.
+
+Now that we have a rough idea of the big picture, it's time to zoom in on a particular function. Let's look at `main.DFS` first, just because it is a shorter function:
+
+ (pprof) list DFS
+ Total: 5758 samples
+ ROUTINE ====================== main.DFS in /home/rsc/g/benchgraffiti/havlak/havlak1.go
+ samples 225 Total 2296 (flat / cumulative)
+ 3 3 240: func DFS(currentNode *BasicBlock, nodes []*UnionFindNode, number map[*BasicBlock]int, last []int, current int) int {
+ 18 19 241: nodes[current].Init(currentNode, current)
+ . 166 242: number[currentNode] = current
+ . . 243:
+ 2 2 244: lastid := current
+ 167 167 245: for _, target := range currentNode.OutEdges {
+ 17 508 246: if number[target] == unvisited {
+ 10 1157 247: lastid = DFS(target, nodes, number, last, lastid+1)
+ . . 248: }
+ . . 249: }
+ 7 273 250: last[number[currentNode]] = lastid
+ 1 1 251: return lastid
+ . . 252: }
+ (pprof)
+
+The listing shows the source code for the `DFS` function (really, for every function matching the regular expression `DFS`). The first three columns are the number of samples taken while running that line, the number of samples taken while running that line or in code called from that line, and the line number in the file. The related command `disasm` shows a disassembly of the function instead of a source listing; when there are enough samples this can help you see which instructions are expensive. The `weblist` command mixes the two modes: it shows [[http://benchgraffiti.googlecode.com/hg/havlak/havlak1.html][a source listing in which clicking a line shows the disassembly]].
+
+Since we already know that the time is going into map lookups implemented by the hash runtime functions, we care most about the second column. A large fraction of time is spent in recursive calls to `DFS` (line 247), as would be expected from a recursive traversal. Excluding the recursion, it looks like the time is going into the accesses to the `number` map on lines 242, 246, and 250. For that particular lookup, a map is not the most efficient choice. Just as they would be in a compiler, the basic block structures have unique sequence numbers assigned to them. Instead of using a `map[*BasicBlock]int` we can use a `[]int`, a slice indexed by the block number. There's no reason to use a map when an array or slice will do.
+
+Changing `number` from a map to a slice requires editing seven lines in the program and cut its run time by nearly a factor of two:
+
+ $ make havlak2
+ 6g havlak2.go
+ 6l -o havlak2 havlak2.6
+ rm havlak2.6
+ $ xtime havlak2
+ # of loops: 76000 (including 1 artificial root node)
+ 30.88u 0.24s *31.14r*1564608kB*havlak2*
+ $
+
+(See the [[http://code.google.com/p/benchgraffiti/source/diff?name=34f7624bb2e2&r=240c155236f9&format=unidiff&path=/havlak/havlak.go][diff between `havlak1` and `havlak2`]])
+
+We can run the profiler again to confirm that `main.DFS` is no longer a significant part of the run time:
+
+ $ _make_havlak2.prof_
+ havlak2 -cpuprofile=havlak2.prof
+ # of loops: 76000 (including 1 artificial root node)
+ $ _gopprof_havlak2_havlak2.prof_
+ Welcome to pprof! For help, type 'help'.
+ (pprof) _top5_
+ Total: 3099 samples
+ 626 20.2% 20.2% 626 20.2% scanblock
+ 309 10.0% 30.2% 2839 91.6% main.FindLoops
+ 176 5.7% 35.9% 1732 55.9% runtime.mallocgc
+ 173 5.6% 41.4% 397 12.8% sweep
+ 101 3.3% 44.7% 111 3.6% main.DFS
+ (pprof)
+
+`main.DFS` still appears in the profile, but its total time has dropped from 20.0% to 3.6%. The rest of the program runtime has dropped too. Now the program is spending most of its time allocating memory and garbage collecting (`runtime.mallocgc`, which both allocates and runs periodic garbage collections, accounts for 55.9% of the time). To find out why the garbage collector is running so much, we have to find out what is allocating memory. One way is to add memory profiling to the program. We'll arrange that if the `-memprofile` flag is supplied, the program stops after one iteration of the loop finding, writes a memory profile, and exits:
+
+ *var*memprofile*=*flag.String("memprofile",*"",*"write*memory*profile*to*this*file")*
+ ...
+
+ FindHavlakLoops(cfgraph, lsgraph)
+ *****if**memprofile*!=*""*{
+ ********f,*err*:=*os.Create(*memprofile)
+ ********if*err*!=*nil*{
+ ************log.Fatal(err)
+ ********}
+ ********pprof.WriteHeapProfile(f)
+ ********f.Close()
+ ********return
+ ****}*
+
+We invoke the program with `-memprofile` flag to write a profile:
+
+ $ _make_havlak3.mprof_ # [[http://code.google.com/p/benchgraffiti/source/diff?name=240c155236f9&r=796913012f93&format=unidiff&path=/havlak/havlak.go][diff from havlak2]]
+ havlak3 -memprofile=havlak3.mprof
+ $
+
+We use `gopprof` exactly the same way. Now the samples we are examining are memory allocations, not clock ticks.
+
+ $ _gopprof_havlak3_havlak3.mprof_
+ Adjusting heap profiles for 1-in-524288 sampling rate
+ Welcome to pprof! For help, type 'help'.
+ (pprof) _top5_
+ Total: 118.3 MB
+ 66.1 55.8% 55.8% 103.7 87.7% main.FindLoops
+ 30.5 25.8% 81.6% 30.5 25.8% main.*LSG·NewLoop
+ 10.0 8.5% 90.1% 10.0 8.5% main.NewBasicBlock
+ 6.5 5.5% 95.6% 6.5 5.5% main.*SimpleLoop·AddNode
+ 2.1 1.7% 97.3% 12.1 10.2% main.*CFG·CreateNode
+ (pprof)
+
+`Gopprof` reports that `FindLoops` has allocated approximately 66.1 of the 118.3 MB in use; `NewLoop` accounts for another 30.5 MB. To reduce overhead, the memory profiler only records information for approximately one block per half megabyte allocated (the “1-in-524288 sampling rate”), so these are approximations to the actual counts.
+
+To find the memory allocations, we can list those functions.
+
+ (pprof) _list_FindLoops_
+ Total: 118.3 MB
+ ROUTINE ====================== main.FindLoops in /home/rsc/g/benchgraffiti/havlak/havlak3.go
+ MB 66.1 Total 103.7 (flat / cumulative)
+ ...
+ . . 267:
+ 1.9 1.9 268: nonBackPreds := make([]map[int]bool, size)
+ 3.8 3.8 269: backPreds := make([][]int, size)
+ . . 270:
+ 1.0 1.0 271: number := make([]int, size)
+ 1.0 1.0 272: header := make([]int, size, size)
+ 1.0 1.0 273: types := make([]int, size, size)
+ 1.0 1.0 274: last := make([]int, size, size)
+ 1.9 1.9 275: nodes := make([]*UnionFindNode, size, size)
+ . . 276:
+ . . 277: for i := 0; i < size; i++ {
+ 5.5 5.5 278: nodes[i] = new(UnionFindNode)
+ . . 279: }
+ ...
+ . . 286: for i, bb := range cfgraph.Blocks {
+ . . 287: number[bb.Name] = unvisited
+ 48.0 48.0 288: nonBackPreds[i] = make(map[int]bool)
+ . . 289: }
+ ...
+ (pprof) _list_NewLoop_
+ Total: 118.3 MB
+ ROUTINE ====================== main.*LSG·NewLoop in /home/rsc/g/benchgraffiti/havlak/havlak3.go
+ . . 578: func (lsg *LSG) NewLoop() *SimpleLoop {
+ 2.5 2.5 579: loop := new(SimpleLoop)
+ 7.5 7.5 580: loop.basicBlocks = make(map[*BasicBlock]bool)
+ 20.5 20.5 581: loop.Children = make(map[*SimpleLoop]bool)
+ ...
+ . . 588: }
+ (pprof)
+
+It looks like the current bottleneck is the same as the last one: using maps where simpler data structures suffice. `FindLoops` is allocating about 48 MB of maps, and `NewLoop` is allocating another 20 MB.
+
+As an aside, if we run `gopprof` with the `--inuse_objects` flag, it will report allocation counts instead of sizes:
+
+ $ _gopprof_--inuse_objects_havlak3_havlak3.mprof_
+ Adjusting heap profiles for 1-in-524288 sampling rate
+ Welcome to pprof! For help, type 'help'.
+ (pprof) _list_NewLoop_
+ Total: 1604080 objects
+ ROUTINE ====================== main.*LSG·NewLoop in /home/rsc/g/benchgraffiti/havlak/havlak3.go
+ . . 578: func (lsg *LSG) NewLoop() *SimpleLoop {
+ 54613 54613 579: loop := new(SimpleLoop)
+ 75678 75678 580: loop.basicBlocks = make(map[*BasicBlock]bool)
+ 207530 207530 581: loop.Children = make(map[*SimpleLoop]bool)
+ ...
+ . . 588: }
+ (pprof)
+
+Since the 200,000 maps account for 20 MB, it looks like the initial map allocation takes about 100 bytes. That's reasonable when a map is being used to hold key-value pairs, but not when a map is being used as a stand-in for a simple set, as it is here.
+
+Instead of using a map, we can use a simple slice to list the elements. In all but one of the cases where maps are being used, it is impossible for the algorithm to insert a duplicate element. In the one remaining case, we can write a simple variant of the `append` built-in function:
+
+ func appendUnique(a []int, x int) []int {
+ for _, y := range a {
+ if x == y {
+ return a
+ }
+ }
+ return append(a, x)
+ }
+
+In addition to writing that function, changing the Go program to use slices instead of maps requires changing just a few lines of code.
+
+ $ _xtime_havlak4_ # [[http://code.google.com/p/benchgraffiti/source/diff?name=796913012f93&r=d856c2f698c1&format=unidiff&path=/havlak/havlak.go][diff from havlak3]]
+ # of loops: 76000 (including 1 artificial root node)
+ 18.35u 0.11s *18.48r*575792kB*havlak4*
+ $
+
+We're now at 3x faster than when we started. Let's look at a CPU profile again.
+
+ $ _gopprof_havlak4_havlak4.prof_
+ Welcome to pprof! For help, type 'help'.
+ (pprof) _top10_
+ Total: 1851 samples
+ 283 15.3% 15.3% 283 15.3% scanblock
+ 233 12.6% 27.9% 1622 87.6% main.FindLoops
+ 142 7.7% 35.5% 1054 56.9% runtime.mallocgc
+ 112 6.1% 41.6% 276 14.9% sweep
+ 111 6.0% 47.6% 115 6.2% main.DFS
+ 85 4.6% 52.2% 661 35.7% runtime.growslice
+ 84 4.5% 56.7% 84 4.5% runtime.memmove
+ 69 3.7% 60.5% 281 15.2% runtime.MCache_Alloc
+ 67 3.6% 64.1% 84 4.5% MCentral_Alloc
+ 67 3.6% 67.7% 93 5.0% MCentral_Free
+ (pprof)
+
+Now memory allocation and the consequent garbage collection (`runtime.mallocgc`) accounts for 56.9% of our run time. Another way to look at why the system is garbage collecting is to look at the allocations that are causing the collections, the ones that spend most of the time in `mallocgc`:
+
+ (pprof) _web_mallocgc_
+
+.image profiling-go-programs_havlak4a-mallocgc.png
+
+It's hard to tell what's going on in that graph, because there are many nodes with small sample numbers obscuring the big ones. We can tell `gopprof` to ignore nodes that don't account for at least 10% of the samples:
+
+ $ _gopprof_--nodefraction=0.1_6.out_prof_
+ Welcome to pprof! For help, type 'help'.
+ (pprof) _web_mallocgc_
+
+.image profiling-go-programs_havlak4a-mallocgc-trim.png
+
+We can follow the thick arrows easily now, to see that `FindLoops` is triggering most of the garbage collection. If we list `FindLoops` we can see that much of it is right at the beginning:
+
+ (pprof) _list_FindLoops_
+ . . 270: func FindLoops(cfgraph *CFG, lsgraph *LSG) {
+ . . 271: if cfgraph.Start == nil {
+ . . 272: return
+ . . 273: }
+ . . 274:
+ . . 275: size := cfgraph.NumNodes()
+ . . 276:
+ . 17 277: nonBackPreds := make([][]int, size)
+ . 82 278: backPreds := make([][]int, size)
+ . . 279:
+ . 2 280: number := make([]int, size)
+ . 1 281: header := make([]int, size, size)
+ . 61 282: types := make([]int, size, size)
+ . . 283: last := make([]int, size, size)
+ . 58 284: nodes := make([]*UnionFindNode, size, size)
+ . . 285:
+ 2 2 286: for i := 0; i < size; i++ {
+ . 261 287: nodes[i] = new(UnionFindNode)
+ . . 288: }
+ ...
+ (pprof)
+
+Every time `FindLoops` is called, it allocates some sizable bookkeeping structures. Since the benchmark calls `FindLoops` 50 times, these add up to a significant amount of garbage, so a significant amount of work for the garbage collector.
+
+Having a garbage-collected language doesn't mean you can ignore memory allocation issues. In this case, a simple solution is to introduce a cache so that each call to `FindLoops` reuses the previous call's storage when possible. (In fact, in Hundt's paper, he explains that the Java program needed just this change to get anything like reasonable performance, but he did not make the same change in the other garbage-collected implementations.)
+
+We'll add a global `cache` structure:
+
+ var cache struct {
+ size int
+ nonBackPreds [][]int
+ backPreds [][]int
+ number []int
+ header []int
+ types []int
+ last []int
+ nodes []*UnionFindNode
+ }
+
+and then have `FindLoops` consult it as a replacement for allocation:
+
+ if cache.size < size {
+ cache.size = size
+ cache.nonBackPreds = make([][]int, size)
+ cache.backPreds = make([][]int, size)
+ cache.number = make([]int, size)
+ cache.header = make([]int, size)
+ cache.types = make([]int, size)
+ cache.last = make([]int, size)
+ cache.nodes = make([]*UnionFindNode, size)
+ for i := range cache.nodes {
+ cache.nodes[i] = new(UnionFindNode)
+ }
+ }
+
+ nonBackPreds := cache.nonBackPreds[:size]
+ for i := range nonBackPreds {
+ nonBackPreds[i] = nonBackPreds[i][:0]
+ }
+ backPreds := cache.backPreds[:size]
+ for i := range nonBackPreds {
+ backPreds[i] = backPreds[i][:0]
+ }
+ number := cache.number[:size]
+ header := cache.header[:size]
+ types := cache.types[:size]
+ last := cache.last[:size]
+ nodes := cache.nodes[:size]
+
+Such a global variable is bad engineering practice, of course: it means that concurrent calls to `FindLoops` are now unsafe. For now, we are making the minimal possible changes in order to understand what is important for the performance of our program; this change is simple and mirrors the code in the Java implementation. The final version of the Go program will use a separate `LoopFinder` instance to track this memory, restoring the possibility of concurrent use.
+
+ $ _xtime_havlak5_ # [[http://code.google.com/p/benchgraffiti/source/diff?name=d856c2f698c1&r=5ce46b0ee1db&format=unidiff&path=/havlak/havlak.go][diff from havlak4]]
+ # of loops: 76000 (including 1 artificial root node)
+ 12.59u 0.07s *12.67r*584496kB*havlak5*
+ $
+
+There's more we can do to clean up the program and make it faster, but none of it requires profiling techniques that we haven't already shown. The work list used in the inner loop can be reused across iterations and across calls to `FindLoops`, and it can be combined with the separate “node pool” generated during that pass. Similarly, the loop graph storage can be reused on each iteration instead of reallocated. In addition to these performance changes, the [[http://code.google.com/p/benchgraffiti/source/browse/havlak/havlak6.go][final version]] is written using idiomatic Go style, using data structures and methods. The stylistic changes have only a minor effect on the run time: the algorithm and constraints are unchanged.
+
+The final version runs in 3.84 seconds and uses 257 MB of memory:
+
+ $ _xtime_havlak6_
+ # of loops: 76000 (including 1 artificial root node)
+ 3.79u 0.04s *3.84r*263472kB*havlak6*
+ $
+
+That's nearly 15 times faster than the program we started with. Even if we disable reuse of the generated loop graph, so that the only cached memory is the loop finding bookeeping, the program still runs 10x faster than the original and uses 2.5x less memory.
+
+ $ _xtime_havlak6_-reuseloopgraph=false_
+ # of loops: 76000 (including 1 artificial root node)
+ 5.74u 0.10s *5.84r*617040kB*havlak6*-reuseloopgraph=false*
+ $
+
+Of course, it's no longer fair to compare this Go program to the original C++ program, which used inefficient data structures like `set`s where `vector`s would be more appropriate. As a sanity check, we translated the final Go program into [[http://code.google.com/p/benchgraffiti/source/browse/havlak/havlak6.cc][equivalent C++ code]]. Its execution time is similar to the Go program's:
+
+ $ xtime havlak6cc
+ # of loops: 76000 (including 1 artificial root node)
+ 4.04u 0.38s *4.42r*387744kB*havlak6cc*
+ $
+
+The Go program runs slightly faster because the C++ program is using automatic deletes and allocation instead of an explicit cache. That makes the C++ program a bit shorter and easier to write, but not dramatically so:
+
+ $ _wc_havlak6.cc;_wc_havlak6.go_
+ 401 1220 9040 [[http://code.google.com/p/benchgraffiti/source/browse/havlak/havlak6.cc][havlak6.cc]]
+ 461 1441 9467 [[http://code.google.com/p/benchgraffiti/source/browse/havlak/havlak6.go][havlak6.go]]
+ $
+
+Benchmarks are only as good as the programs they measure. We used `gopprof` to study an inefficient Go program and then to improve its performance by an order of magnitude and to reduce its memory usage by a factor of six. A subsequent comparison with an equivalently optimized C++ program shows that Go can be competitive with C++ when programmers are careful about how much garbage is generated by inner loops.
+
+The program sources, Linux x86-64 binaries, and profiles used to write this post are available in the [[http://code.google.com/p/benchgraffiti/][benchgraffiti project on Google Code]].
+
+As mentioned above, [[http://golang.org/cmd/gotest][gotest]] includes these profiling flags already: define a [[http://golang.org/pkg/testing/#Benchmark][benchmark function]] and you're all set. There is also a standard HTTP interface to profiling data. In an HTTP server, adding
+
+ import _ "http/pprof"
+
+will install handlers for a few URLs under `/debug/pprof/`. Then you can run `gopprof` with a single argument—the URL to your server's profiling data—and it will download and examine a live profile.
+
+ gopprof http://localhost:6060/debug/pprof/profile # 30-second CPU profile
+ gopprof http://localhost:6060/debug/pprof/heap # heap profile
diff --git a/content/profiling-go-programs_havlak1-hash_lookup-75.png b/content/profiling-go-programs_havlak1-hash_lookup-75.png
new file mode 100644
index 0000000..d849124
--- /dev/null
+++ b/content/profiling-go-programs_havlak1-hash_lookup-75.png
Binary files differ
diff --git a/content/profiling-go-programs_havlak1a-75.png b/content/profiling-go-programs_havlak1a-75.png
new file mode 100644
index 0000000..3283665
--- /dev/null
+++ b/content/profiling-go-programs_havlak1a-75.png
Binary files differ
diff --git a/content/profiling-go-programs_havlak4a-mallocgc-trim.png b/content/profiling-go-programs_havlak4a-mallocgc-trim.png
new file mode 100644
index 0000000..63ef9a8
--- /dev/null
+++ b/content/profiling-go-programs_havlak4a-mallocgc-trim.png
Binary files differ
diff --git a/content/profiling-go-programs_havlak4a-mallocgc.png b/content/profiling-go-programs_havlak4a-mallocgc.png
new file mode 100644
index 0000000..ee7347f
--- /dev/null
+++ b/content/profiling-go-programs_havlak4a-mallocgc.png
Binary files differ
diff --git a/content/real-go-projects-smarttwitter-and-webgo.article b/content/real-go-projects-smarttwitter-and-webgo.article
new file mode 100644
index 0000000..5fd46df
--- /dev/null
+++ b/content/real-go-projects-smarttwitter-and-webgo.article
@@ -0,0 +1,23 @@
+Real Go Projects: SmartTwitter and web.go
+19 Oct 2010
+Tags: concurrency, guest, json
+
+Michael Hoisie
+
+* Introduction
+
+_This_week's_article_is_written_by_ [[http://www.hoisie.com/][_Michael_Hoisie_]]. _A_programmer_based_in_San_Francisco,_he_is_one_of_Go's_early_adopters_and_the_author_of_several_popular_Go_libraries._He_describes_his_experiences_using_Go:_
+
+I was introduced to Go by a post on [[http://news.ycombinator.com/][Hacker News]]. About an hour later I was hooked. At the time I was working at a web start-up, and had been developing internal testing apps in Python. Go offered speed, better concurrency support, and sane Unicode handling, so I was keen to port my programs to the language. At that time there wasn't an easy way to write web apps in Go, so I decided to build a simple web framework, [[http://github.com/hoisie/web.go][web.go]]. It was modeled after a popular Python framework, [[http://webpy.org/][web.py]], which I had worked with previously. While working on web.go I got involved in the Go community, submitted a bunch of bug reports, and hacked on some standard library packages (mainly [[http://golang.org/pkg/http/][http]] and [[http://golang.org/pkg/json/][json]]).
+
+After a few weeks I noticed that web.go was getting attention at Github. This was surprising because I'd never really promoted the project. I think there's a niche for simple, fast web applications, and I think Go can fill it.
+
+One weekend I decided to write a simple Facebook application: it would re-post your Twitter status updates to your Facebook profile. There is an official Twitter application to do this, but it re-posts everything, creating noise in your Facebook feed. My application allowed you to filter retweets, mentions, hashtags, replies, and more. This turned into [[http://www.facebook.com/apps/application.php?id=135488932982][Smart Twitter]], which currently has nearly 90,000 users.
+
+The entire program is written in Go, and uses [[http://code.google.com/p/redis/][Redis]] as its storage back-end. It is very fast and robust. It currently processes about two dozen tweets per second, and makes heavy use of Go's channels. It runs on a single Virtual Private Server instance with 2GB of RAM, which has no problem handling the load. Smart Twitter uses very little CPU time, and is almost entirely memory-bound as the entire database is kept in memory. At any given time there are around 10 goroutines running concurrently: one accepting HTTP connections, another reading from the Twitter Streaming API, a couple for error handling, and the rest either processing web requests or re-posting incoming tweets.
+
+Smart Twitter also spawned other open-source Go projects: [[http://github.com/hoisie/mustache.go][mustache.go]], [[http://github.com/hoisie/redis.go][redis.go]], and [[http://github.com/hoisie/twitterstream][twitterstream]].
+
+I see a lot of work left to do on web.go. For instance, I'd like to add better support for streaming connections, websockets, route filters, better support in shared hosts, and improving the documentation. I recently left the start-up to do software freelancing, and I'm planning to use Go where possible. This means I'll probably use it as a back end for personal apps, as well as for clients that like working with cutting edge technology.
+
+Finally, I'd like to thank the Go team for all their effort. Go is a wonderful platform and I think it has a bright future. I hope to see the language grow around the needs of the community. There's a lot of interesting stuff happening in the community, and I look forward to seeing what people can hack together with the language.
diff --git a/content/share-memory-by-communicating.article b/content/share-memory-by-communicating.article
new file mode 100644
index 0000000..fdbc0b5
--- /dev/null
+++ b/content/share-memory-by-communicating.article
@@ -0,0 +1,79 @@
+Share Memory By Communicating
+13 Jul 2010
+Tags: channel, concurrency, goroutine
+
+Andrew Gerrand
+
+* Introduction
+
+Traditional threading models (commonly used when writing Java, C++, and Python programs, for example) require the programmer to communicate between threads using shared memory. Typically, shared data structures are protected by locks, and threads will contend over those locks to access the data. In some cases, this is made easier by the use of thread-safe data structures such as Python's Queue.
+
+Go's concurrency primitives - goroutines and channels - provide an elegant and distinct means of structuring concurrent software. (These concepts have an [[http://swtch.com/~rsc/thread/][interesting history]] that begins with C. A. R. Hoare's [[http://www.usingcsp.com/][Communicating Sequential Processes]].) Instead of explicitly using locks to mediate access to shared data, Go encourages the use of channels to pass references to data between goroutines. This approach ensures that only one goroutine has access to the data at a given time. The concept is summarized in the document [[http://golang.org/doc/effective_go.html][Effective Go]] (a must-read for any Go programmer):
+
+_Do_not_communicate_by_sharing_memory;_instead,_share_memory_by_communicating._
+
+Consider a program that polls a list of URLs. In a traditional threading environment, one might structure its data like so:
+
+ type Resource struct {
+ url string
+ polling bool
+ lastPolled int64
+ }
+
+ type Resources struct {
+ data []*Resource
+ lock *sync.Mutex
+ }
+
+And then a Poller function (many of which would run in separate threads) might look something like this:
+
+ func Poller(res *Resources) {
+ for {
+ // get the least recently-polled Resource
+ // and mark it as being polled
+ res.lock.Lock()
+ var r *Resource
+ for _, v := range res.data {
+ if v.polling {
+ continue
+ }
+ if r == nil || v.lastPolled < r.lastPolled {
+ r = v
+ }
+ }
+ if r != nil {
+ r.polling = true
+ }
+ res.lock.Unlock()
+ if r == nil {
+ continue
+ }
+
+ // poll the URL
+
+ // update the Resource's polling and lastPolled
+ res.lock.Lock()
+ r.polling = false
+ r.lastPolled = time.Nanoseconds()
+ res.lock.Unlock()
+ }
+ }
+
+This function is about a page long, and requires more detail to make it complete. It doesn't even include the URL polling logic (which, itself, would only be a few lines), nor will it gracefully handle exhausting the pool of Resources.
+
+Let's take a look at the same functionality implemented using Go idiom. In this example, Poller is a function that receives Resources to be polled from an input channel, and sends them to an output channel when they're done.
+
+ type Resource string
+
+ func Poller(in, out chan *Resource) {
+ for r := range in {
+ // poll the URL
+
+ // send the processed Resource to out
+ out <- r
+ }
+ }
+
+The delicate logic from the previous example is conspicuously absent, and our Resource data structure no longer contains bookkeeping data. In fact, all that's left are the important parts. This should give you an inkling as to the power of these simple language features.
+
+There are many omissions from the above code snippets. For a walkthrough of a complete, idiomatic Go program that uses these ides, see the Codewalk [[http://golang.org/doc/codewalk/sharemem/][_Share_Memory_By_Communicating_]].
diff --git a/content/spotlight-on-external-go-libraries.article b/content/spotlight-on-external-go-libraries.article
new file mode 100644
index 0000000..6daf4cd
--- /dev/null
+++ b/content/spotlight-on-external-go-libraries.article
@@ -0,0 +1,41 @@
+Spotlight on external Go libraries
+3 Jun 2011
+Tags: community, libraries
+
+Andrew Gerrand
+
+* Introduction
+
+While the Go authors have been working hard at improving Go's standard library, the greater community has created a growing ecosystem of external libraries. In this post we look at some popular Go libraries and how they can be used.
+
+[[http://labix.org/mgo][Mgo]] (pronounced "mango") is a MongoDB database driver. [[http://www.mongodb.org/][MongoDB]] is a [[http://en.wikipedia.org/wiki/Document-oriented_database][document-oriented database]] with a long list of features suitable for [[http://www.mongodb.org/display/DOCS/Use%2BCases][a broad range of uses]]. The mgo package provides a rich, idiomatic Go API for working with MongoDB, from basic operations such as inserting and updating records to the more advanced [[http://www.mongodb.org/display/DOCS/MapReduce][MapReduce]] and [[http://www.mongodb.org/display/DOCS/GridFS][GridFS]] features. Mgo has a bunch of cool features including automated cluster discovery and result pre-fetching - see the [[http://labix.org/mgo][mgo homepage]] for details and example code. For working with large data sets Go, MongoDB, and mgo are a powerful combination.
+
+[[https://github.com/dchest/authcookie][Authcookie]] is a web library for generating and verifying user authentication cookies. It allows web servers to hand out cryptographically secure tokens tied to a specific user that will expire after a specified time period. It has a simple API that makes it straightforward to add authentication to existing web applications. See the [[https://github.com/dchest/authcookie/blob/master/README.md][README file]] for details and example code.
+
+[[http://code.google.com/p/go-charset][Go-charset]] provides support for converting between Go's standard UTF-8 encoding and a variety of character sets. The go-charset package implements a translating io.Reader and io.Writer so you can wrap existing Readers and Writers (such as network connections or file descriptors), making it easy to communicate with systems that use other character encodings.
+
+[[https://github.com/madari/go-socket.io][Go-socket.io]] is a Go implementation of [[http://socket.io/][Socket.IO]], a client/server API that allows web servers to push messages to web browsers. Depending on the capabilities of the user's browser, Socket.IO uses the best transport for the connection, be it modern websockets, AJAX long polling, or some [[http://socket.io/#transports][other mechanism]]. Go-socket.io bridges the gap between Go servers and rich JavaScript clients for a wide range of browsers. To get a feel for go-socket.io see the [[https://github.com/madari/go-socket.io/blob/master/example/example.go][chat server example]].
+
+It's worth mentioning that these packages are [[http://golang.org/cmd/goinstall/][goinstallable]]. With an up-to-date Go [[http://golang.org/doc/install.html][installation]] you can install them all with a single command:
+
+ goinstall launchpad.net/mgo \
+ github.com/dchest/authcookie \
+ go-charset.googlecode.com/hg/charset \
+ github.com/madari/go-socket.io
+
+
+Once goinstalled, the packages can be imported using those same paths:
+
+ import (
+ "launchpad.net/mgo"
+ "github.com/dchest/authcookie"
+ "go-charset.googlecode.com/hg/charset"
+ "github.com/madari/go-socket.io"
+ )
+
+
+Also, as they are now a part of the local Go system, we can inspect their documentation with [[http://golang.org/cmd/godoc/][godoc]]:
+
+ godoc launchpad.net/mgo Database # see docs for Database type
+
+Of course, this is just the tip of the iceberg; there are more great Go libraries listed on the [[http://godashboard.appspot.com/package][package dashboard]] and many more to come.
diff --git a/content/the-app-engine-sdk-and-workspaces-gopath.article b/content/the-app-engine-sdk-and-workspaces-gopath.article
new file mode 100644
index 0000000..be40a2a
--- /dev/null
+++ b/content/the-app-engine-sdk-and-workspaces-gopath.article
@@ -0,0 +1,104 @@
+The App Engine SDK and workspaces (GOPATH)
+9 Jan 2013
+Tags: appengine, build, gopath
+
+Andrew Gerrand
+
+* Introduction
+
+When we released Go 1 we introduced the [[http://golang.org/cmd/go/][go tool]] and, with it, the concept of workspaces. Workspaces (specified by the GOPATH environment variable) are a convention for organizing code that simplifies fetching, building, and installing Go packages. If you're not familiar with workspaces, please read [[http://golang.org/doc/code.html][this article]] or watch [[http://www.youtube.com/watch?v=XCsL89YtqCs][this screencast]] before reading on.
+
+Until recently, the tools in the App Engine SDK were not aware of workspaces. Without workspaces the "[[http://golang.org/cmd/go/#hdr-Download_and_install_packages_and_dependencies][go get]]" command cannot function, and so app authors had to install and update their app dependencies manually. It was a pain.
+
+This has all changed with version 1.7.4 of the App Engine SDK. The [[https://developers.google.com/appengine/docs/go/tools/devserver][dev_appserver]] and [[https://developers.google.com/appengine/docs/go/tools/uploadinganapp][appcfg]] tools are now workspace-aware. When running locally or uploading an app, these tools now search for dependencies in the workspaces specified by the GOPATH environment variable. This means you can now use "go get" while building App Engine apps, and switch between normal Go programs and App Engine apps without changing your environment or habits.
+
+For example, let's say you want to build an app that uses OAuth 2.0 to authenticate with a remote service. A popular OAuth 2.0 library for Go is the [[http://code.google.com/p/goauth2][goauth2]] package, which you can install to your workspace with this command:
+
+ go get code.google.com/p/goauth2/oauth
+
+When writing your App Engine app, import the oauth package just as you would in a regular Go program:
+
+ import "code.google.com/p/goauth2/oauth"
+
+Now, whether running your app with the dev_appserver or deploying it with appcfg, the tools will find the oauth package in your workspace. It just works.
+
+* Hybrid stand-alone/App Engine apps
+
+The Go App Engine SDK builds on Go's standard [[http://golang.org/pkg/net/http/][net/http]] package to serve web requests and, as a result, many Go web servers can be run on App Engine with only a few changes. For example, [[http://golang.org/cmd/godoc/][godoc]] is included in the Go distribution as a stand-alone program, but it can also run as an App Engine app (godoc serves [[http://golang.org/][golang.org]] from App Engine).
+
+But wouldn't it be nice if you could write a program that is both a stand-alone web server and an App Engine app? By using [[http://golang.org/pkg/go/build/#hdr-Build_Constraints][build constraints]], you can.
+
+Build constraints are line comments that determine whether a file should be included in a package. They are most often used in code that handles a variety of operating systems or processor architectures. For instance, the [[http://golang.org/pkg/path/filepath/][path/filepath]] package includes the file [[http://golang.org/src/pkg/path/filepath/symlink.go][symlink.go]], which specifies a build constraint to ensure that it is not built on Windows systems (which do not have symbolic links):
+
+ // +build !windows
+
+The App Engine SDK introduces a new build constraint term: "appengine". Files that specify
+
+ // +build appengine
+
+will be built by the App Engine SDK and ignored by the go tool. Conversely, files that specify
+
+ // +build !appengine
+
+are ignored by the App Engine SDK, while the go tool will happily build them.
+
+The [[http://code.google.com/p/goprotobuf/][goprotobuf]] library uses this mechanism to provide two implementations of a key part of its encode/decode machinery: [[http://code.google.com/p/goprotobuf/source/browse/proto/pointer_unsafe.go][pointer_unsafe.go]] is the faster version that cannot be used on App Engine because it uses the [[http://golang.org/pkg/unsafe/][unsafe package]], while [[http://code.google.com/p/goprotobuf/source/browse/proto/pointer_reflect.go][pointer_reflect.go]] is a slower version that avoids unsafe by using the [[http://golang.org/pkg/reflect/][reflect package]] instead.
+
+Let's take a simple Go web server and turn it into a hybrid app. This is main.go:
+
+ package main
+
+ import (
+ "fmt"
+ "net/http"
+ )
+
+ func main() {
+ http.HandleFunc("/", handler)
+ http.ListenAndServe("localhost:8080", nil)
+ }
+
+ func handler(w http.ResponseWriter, r *http.Request) {
+ fmt.Fprint(w, "Hello!")
+ }
+
+Build this with the go tool and you'll get a stand-alone web server executable.
+
+The App Engine infrastructure provides its own main function that runs its equivalent to ListenAndServe. To convert main.go to an App Engine app, drop the call to ListenAndServe and register the handler in an init function (which runs before main). This is app.go:
+
+ package main
+
+ import (
+ "fmt"
+ "net/http"
+ )
+
+ func init() {
+ http.HandleFunc("/", handler)
+ }
+
+ func handler(w http.ResponseWriter, r *http.Request) {
+ fmt.Fprint(w, "Hello!")
+ }
+
+To make this a hybrid app, we need to split it into an App Engine-specific part, an stand-alone binary-specific part, and the parts common to both versions. In this case, there is no App Engine-specific part, so we split it into just two files:
+
+app.go specifies and registers the handler function. It is identical to the code listing above, and requires no build constraints as it should be included in all versions of the program.
+
+main.go runs the web server. It includes the "!appengine" build constraint, as it must only included when building the stand-alone binary.
+
+ // +build !appengine
+
+ package main
+
+ import "net/http"
+
+ func main() {
+ http.ListenAndServe("localhost:8080", nil)
+ }
+
+To see a more complex hybrid app, take a look at the [[http://code.google.com/p/go/source/browse/?repo=talks#hg%2Fpresent][present tool]].
+
+* Conclusions
+
+We hope these changes will make it easier to work on apps with external dependencies, and to maintain code bases that contain both stand-alone programs and App Engine apps.
diff --git a/content/third-party-libraries-goprotobuf-and.article b/content/third-party-libraries-goprotobuf-and.article
new file mode 100644
index 0000000..119e531
--- /dev/null
+++ b/content/third-party-libraries-goprotobuf-and.article
@@ -0,0 +1,26 @@
+Third-party libraries: goprotobuf and beyond
+20 Apr 2010
+Tags: protobuf
+
+Andrew Gerrand
+
+* Introduction
+
+On March 24, Rob Pike announced [[http://code.google.com/p/goprotobuf/][goprotobuf]], the Go bindings of Google's data interchange format [[http://code.google.com/apis/protocolbuffers/docs/overview.html][Protocol Buffers]], called protobufs for short. With this announcement, Go joins C++, Java, and Python as languages providing official protobuf implementations. This marks an important milestone in enabling the interoperability between existing systems and those built in Go.
+
+The goprotobuf project consists of two parts: a 'protocol compiler plugin' that generates Go source files that, once compiled, can access and manage protocol buffers; and a Go package that implements run-time support for encoding (marshaling), decoding (unmarshaling), and accessing protocol buffers.
+
+To use goprotobuf, you first need to have both Go and [[http://code.google.com/p/protobuf/][protobuf]] installed. You can then install the 'proto' package with [[http://golang.org/cmd/goinstall/][goinstall]]:
+
+ goinstall goprotobuf.googlecode.com/hg/proto
+
+And then install the protobuf compiler plugin:
+
+ cd $GOROOT/src/pkg/goprotobuf.googlecode.com/hg/compiler
+ make install
+
+For more detail see the project's [[http://code.google.com/p/goprotobuf/source/browse/README][README]] file.
+
+This is one of a growing list of third-party [[http://godashboard.appspot.com/package][Go projects]]. Since the announcement of goprotobuf, the X Go bindings have been spun off from the standard library to the [[http://code.google.com/p/x-go-binding/][x-go-binding]] project, and work has begun on a [[http://www.freetype.org/][Freetype]] port, [[http://code.google.com/p/freetype-go/][freetype-go]]. Other popular third-party projects include the lightweight web framework [[http://github.com/hoisie/web.go][web.go]], and the Go GTK bindings [[http://github.com/mattn/go-gtk][gtk-go]].
+
+We wish to encourage the development of other useful packages by the open source community. If you're working on something, don't keep it to yourself - let us know through our mailing list [[http://groups.google.com/group/golang-nuts][golang-nuts]].
diff --git a/content/two-go-talks-lexical-scanning-in-go-and.article b/content/two-go-talks-lexical-scanning-in-go-and.article
new file mode 100644
index 0000000..7469651
--- /dev/null
+++ b/content/two-go-talks-lexical-scanning-in-go-and.article
@@ -0,0 +1,21 @@
+Two Go Talks: "Lexical Scanning in Go" and "Cuddle: an App Engine Demo"
+1 Sep 2011
+Tags: appengine, lexer, talk, video
+
+Andrew Gerrand
+
+* Introduction
+
+On Tuesday night Rob Pike and Andrew Gerrand each presented at the [[http://www.sydney-gtug.org/][Sydney Google Technology User Group]].
+
+Rob's talk, "[[http://www.youtube.com/watch?v=HxaD_trXwRE][Lexical Scanning in Go]]", discusses the design of a particularly interesting and idiomatic piece of Go code, the lexer component of the new [[http://golang.org/pkg/exp/template/][template package.]]
+
+.iframe http://www.youtube.com/embed/HxaD_trXwRE 345 560
+
+The slides are [[http://cuddle.googlecode.com/hg/talk/lex.html][available here]]. The new template package is available as [[http://golang.org/pkg/exp/template/][exp/template]] in Go release r59. In a future release it will replace the old template package.
+
+Andrew's talk, "[[http://www.youtube.com/watch?v=HQtLRqqB-Kk][Cuddle: an App Engine Demo]]", describes the construction of a simple real-time chat application that uses App Engine's [[http://code.google.com/appengine/docs/go/datastore/overview.html][Datastore]], [[http://code.google.com/appengine/docs/go/channel/overview.html][Channel]], and [[http://code.google.com/appengine/docs/go/datastore/memcache.html][Memcache]] APIs. It also includes a question and answer session that covers [[http://code.google.com/appengine/docs/go/gettingstarted/][Go for App Engine]] and Go more generally.
+
+.iframe http://www.youtube.com/embed/HQtLRqqB-Kk 345 560
+
+The slides are [[http://cuddle.googlecode.com/hg/talk/index.html][available here]]. The code is available at the [[http://code.google.com/p/cuddle/][cuddle Google Code project]].
diff --git a/content/two-recent-go-articles.article b/content/two-recent-go-articles.article
new file mode 100644
index 0000000..ef6fb90
--- /dev/null
+++ b/content/two-recent-go-articles.article
@@ -0,0 +1,45 @@
+Two recent Go articles
+6 Mar 2013
+
+Andrew Gerrand
+
+* Introduction
+
+In today's blog post I'd like to highlight a couple of recent articles about Go.
+
+* Go at Google
+
+In October last year, Rob Pike presented a keynote at the ACM [[http://splashcon.org/2012/][SPLASH]] conference in Tucson. The talk, titled [[http://talks.golang.org/2012/splash.slide][Go at Google]], was a comprehensive discussion of the motivations behind Go. Rob later expanded on his talk to produce an essay titled [[http://talks.golang.org/2012/splash.article][Go at Google: Language Design in the Service of Software Engineering]]. Here is the abstract:
+
+ The Go programming language was conceived in late 2007 as an
+ answer to some of the problems we were seeing developing
+ software infrastructure at Google. The computing landscape
+ today is almost unrelated to the environment in which the
+ languages being used, mostly C++, Java, and Python, had been
+ created. The problems introduced by multicore processors,
+ networked systems, massive computation clusters, and the web
+ programming model were being worked around rather than
+ addressed head-on. Moreover, the scale has changed: today's
+ server programs comprise tens of millions of lines of code,
+ are worked on by hundreds or even thousands of programmers,
+ and are updated literally every day. To make matters worse,
+ build times, even on large compilation clusters, have
+ stretched to many minutes, even hours.
+
+ Go was designed and developed to make working in this
+ environment more productive. Besides its better-known
+ aspects such as built-in concurrency and garbage collection,
+ Go's design considerations include rigorous dependency
+ management, the adaptability of software architecture as
+ systems grow, and robustness across the boundaries between
+ components.
+
+This article explains how these issues were addressed while building an efficient, compiled programming language that feels lightweight and pleasant. Examples and explanations will be taken from the real-world problems faced at Google.
+
+If you have wondered about the design decisions behind Go, you may find your questions answered by [[http://talks.golang.org/2012/splash.article][the essay]]. It is recommended reading for both new and experienced Go programmers.
+
+* Go at the Google Developers Academy
+
+At Google I/O 2012 the Google Developers team [[http://googledevelopers.blogspot.com.au/2012/06/google-launches-new-developer-education.html][launched]] the [[https://developers.google.com/academy/][Google Developers Academy]], a program that provides training materials on Google technologies. Go is one of those technologies and we're pleased to announce the first GDA article featuring Go front and center:
+
+[[https://developers.google.com/appengine/training/go-plus-appengine/][Getting Started with Go, App Engine and Google+ API]] is an introduction to writing web applications in Go. It demonstrates how to build and deploy App Engine applications and make calls to the Google+ API using the Google APIs Go Client. This is a great entry point for Go programmers eager to get started with Google's developer ecosystem.
diff --git a/content/two-recent-go-talks.article b/content/two-recent-go-talks.article
new file mode 100644
index 0000000..8feccf3
--- /dev/null
+++ b/content/two-recent-go-talks.article
@@ -0,0 +1,29 @@
+Two recent Go talks
+2 Jan 2013
+Tags: talk, video
+
+Andrew Gerrand
+
+* Introduction
+
+Late last year I wrote a couple of Go talks and presented them at [[http://thestrangeloop.com/][Strange Loop]], [[http://oredev.com][Øredev]], and various other venues. The talks are designed to give insight into the practice of Go programming, each describing the construction of a real program and demonstrating the power and depth of the Go language and its libraries and tools.
+
+The following videos are, in my opinion, the best recordings of these talks.
+
+* Go: a simple programming environment
+
+Go is a general-purpose language that bridges the gap between efficient statically typed languages and productive dynamic language. But it’s not just the language that makes Go special – Go has broad and consistent standard libraries and powerful but simple tools.
+
+This talk gives an introduction to Go, followed by a tour of some real programs that demonstrate the power, scope, and simplicity of the Go programming environment.
+
+.iframe http://player.vimeo.com/video/53221558?badge=0 281 500
+
+See the [[http://talks.golang.org/2012/simple.slide][slide deck]] (use the left and right arrows to navigate).
+
+* Go: code that grows with grace
+
+One of Go's key design goals is code adaptability; that it should be easy to take a simple design and build upon it in a clean and natural way. In this talk I describe a simple "chat roulette" server that matches pairs of incoming TCP connections, and then use Go's concurrency mechanisms, interfaces, and standard library to extend it with a web interface and other features. While the function of the program changes dramatically, Go's flexibility preserves the original design as it grows.
+
+.iframe http://player.vimeo.com/video/53221560?badge=0 281 500
+
+See the [[http://talks.golang.org/2012/chat.slide][slide deck]] (use the left and right arrows to navigate).
diff --git a/content/upcoming-google-io-go-events.article b/content/upcoming-google-io-go-events.article
new file mode 100644
index 0000000..1641eca
--- /dev/null
+++ b/content/upcoming-google-io-go-events.article
@@ -0,0 +1,16 @@
+Upcoming Google I/O Go Events
+12 May 2010
+
+Andrew Gerrand
+
+* Introduction
+
+[[http://code.google.com/events/io/2010/][Google I/O 2010]] is happening next week at the Moscone Centre in San Francisco. Those of you with tickets will be able to catch some of the Go team both at I/O and at [[http://code.google.com/events/io/2010/bootcamp.html][Bootcamp]]. In reverse-chronological order:
+
+Rob Pike and Russ Cox will be presenting a [[http://code.google.com/events/io/2010/sessions/go-programming.html][Go Programming]] talk on Thursday at 10.15am. This session takes a detailed look at how Go differs from other languages in a practical sense. Through a series of examples, they will demonstrate various features of Go and the ways in which they affect program design.
+
+Several members of the Go team will be at the Go cube during [[http://code.google.com/events/io/2010/officehours.html][Office Hours]] on Wednesday between 12pm and 2:30pm. Come by to have your Go questions answered by the experts.
+
+At Bootcamp on Tuesday at 4.15pm, Andrew Gerrand will be giving an introductory talk about Go. The session will give an overview of the problems that motivated us to build a new language, and the ways in which Go addresses those problems.
+
+If you're coming to I/O, we look forward to seeing you there!
diff --git a/content/writing-scalable-app-engine.article b/content/writing-scalable-app-engine.article
new file mode 100644
index 0000000..d260f35
--- /dev/null
+++ b/content/writing-scalable-app-engine.article
@@ -0,0 +1,18 @@
+Writing scalable App Engine applications
+1 Nov 2011
+Tags: appengine, optimization
+
+David Symonds
+
+* Introduction
+
+Back in May, we [[http://blog.golang.org/2011/05/go-and-google-app-engine.html][announced]] the Go runtime for App Engine. Since then, we've opened it up for everyone to use, added many new APIs, and improved performance. We have been thrilled by all the interesting ways that people are using Go on App Engine.
+One of the key benefits of the Go runtime, apart from working in a fantastic language, is that it has high performance. Go applications compile to native code, with no interpreter or virtual machine getting between your program and the machine.
+
+Making your web application fast is important because it is well known that a web site's latency has a measurable impact on user happiness, and [[http://googlewebmastercentral.blogspot.com/2010/04/using-site-speed-in-web-search-ranking.html][Google web search uses it as a ranking factor]]. Also announced in May was that App Engine would be [[http://googleappengine.blogspot.com/2011/05/year-ahead-for-google-app-engine.html][leaving its Preview status]] and transitioning to a [[http://www.google.com/enterprise/cloud/appengine/pricing.html][new pricing model]], providing another reason to write efficient App Engine applications.
+
+To make it easier for Go developers using App Engine to write highly efficient, scalable applications, we recently updated some existing App Engine articles to include snippets of Go source code and to link to relevant Go documentation.
+
+- [[http://code.google.com/appengine/articles/scaling/overview.html][Best practices for writing scalable applications]]
+
+- [[http://code.google.com/appengine/articles/managing-resources.html][Managing Your App's Resource Usage]]
