No major systems language has emerged in over a decade, but over that time the computing landscape has changed tremendously. There are several trends:
We believe it's worth trying again with a new language, a concurrent, garbage-collected language with fast compilation. Regarding the points above:
“Ogle” would be a good name for a Go debugger.
The 6g (and 8g and 5g) compiler is named in the
tradition of the Plan 9 C compilers, described in
http://plan9.bell-labs.com/sys/doc/compiler.html
(see the table in section 2).
6 is the architecture letter for amd64 (or x86-64, if you prefer), while
g stands for Go.
We considered doing that, but too many of the problems—lack of garbage collection, long dependency chains, nested include files, lack of concurrency awareness—are rooted in the design of the C and C++ languages themselves. We felt a viable solution required a more complete approach.
We understand that a significant fraction of computers in the world run Windows and it would be great if those computers could run Go programs. A group of volunteers has made significant progress toward porting Go to MinGW. You can follow their progress on the mailing list.
The mascot and logo were designed by Renée French, who also designed Glenda, the Plan 9 bunny. The gopher is derived from one she used for an WFMU T-shirt design some years ago. The logo and mascot are covered by the Creative Commons Attribution 3.0 license.
Go is an experiment. We hope adventurous users will give it a try and see if they enjoy it. Not every programmer will, but we hope enough will find satisfaction in the approach it offers to justify further development.
The Go project was conceived to make it easier to write the kind
of servers and other software Google uses internally, but the
implementation isn't quite mature enough yet for large-scale
production use. While we continue development we are also doing
experiments with the language as a candidate server environment. It's
getting there. For instance, the server behind http://golang.org is a Go program; in
fact it's just the godoc document server running in a
production configuration.
There are two Go compiler implementations, 6g and friends, generically called
gc, and gccgo.
Gc uses a different calling convention and linker and can
therefore only be linked with C programs using the same convention.
There is such a C compiler but no C++ compiler. Gccgo is a
GCC front-end that can, with care, be linked with GCC-compiled
C or C++ programs. However, because Go is garbage-collected it will be
unwise to do so, at least naively.
There is a “foreign function interface” to allow safe calling of C-written libraries from Go code. We expect to use SWIG to extend this capability to C++ libraries. There is no safe way to call Go code from C or C++ yet.
A separate open source project provides the necessary compiler plugin and library. It is available at http://code.google.com/p/goprotobuf/
Absolutely. We encourage developers to make Go Language sites in their own languages. However, if you choose to add the Google logo or branding to your site (it does not appear on golang.org), you will need to abide by the guidelines at http://www.google.com/permissions/guidelines.html
Every language contains novel features and omits someone's favorite feature. Go was designed with an eye on felicity of programming, speed of compilation, orthogonality of concepts, and the need to support features such as concurrency and garbage collection. Your favorite feature may be missing because it doesn't fit, because it affects compilation speed or clarity of design, or because it would make the fundamental system model too difficult.
If it bothers you that Go is missing feature X, please forgive us and investigate the features that Go does have. You might find that they compensate in interesting ways for the lack of X.
This and other language design questions are answered in the separate language design FAQ.
Yes and no. Although Go has types and methods and allows an object-oriented style of programming, there is no type hierarchy. The concept of “interface” in Go provides a different approach that we believe is easy to use and in some ways more general. There are also ways to embed types in other types to provide something analogous—but not identical—to subclassing. Moreover, methods in Go are more general than in C++ or Java: they can be defined for any sort of data, not just structs.
Also, the lack of type hierarchy makes “objects” in Go feel much more lightweight than in languages such as C++ or Java.
The only way to have dynamically dispatched methods is through an interface. Methods on structs or other types are always resolved statically.
There is a program, godoc, written in Go, that extracts
package documentation from the source code. It can be used on the
command line or on the web. An instance is running at
http://golang.org/pkg/.
In fact, godoc implements the full site at
http://golang.org/.
Eventually, there may be a small number of rules to guide things
like naming, layout, and file organization.
The document Effective Go
contains some style advice.
More directly, the program gofmt is a pretty-printer
whose purpose is to enforce layout rules; it replaces the usual
compendium of do's and don'ts that allows interpretation.
All the Go code in the repository has been run through gofmt.
The library sources are in go/src/pkg.
If you want to make a significant change, please discuss on the mailing list before embarking.
See the document Contributing to the Go project for more information about how to proceed.
Go doesn't provide assertions. They are undeniably convenient, but our experience has been that programmers use them as a crutch to avoid thinking about proper error handling and reporting. Proper error handling means that servers continue operation after non-fatal errors instead of crashing. Proper error reporting means that errors are direct and to the point, saving the programmer from interpreting a large crash trace. Precise errors are particularly important when the programmer seeing the errors is not familiar with the code.
The same arguments apply to the use of assert() in test programs. Proper
error handling means letting other tests run after one has failed, so
that the person debugging the failure gets a complete picture of what is
wrong. It is more useful for a test to report that
isPrime gives the wrong answer for 2, 3, 5, and 7 (or for
2, 4, 8, and 16) than to report that isPrime gives the wrong
answer for 2 and therefore no more tests were run. The programmer who
triggers the test failure may not be familiar with the code that fails.
Time invested writing a good error message now pays off later when the
test breaks.
In testing, if the amount of extra code required to write good errors seems repetitive and overwhelming, it might work better as a table-driven test instead. Go has excellent support for data structure literals.
We understand that this is a point of contention. There are many things in the Go language and libraries that differ from modern practices, simply because we feel it's sometimes worth trying a different approach.
Gccgo has a C++ front-end with a recursive descent parser coupled to the
standard GCC back end. Gc is written in C using
yacc/bison for the parser.
Although it's a new program, it fits in the Plan 9 C compiler suite
(http://plan9.bell-labs.com/sys/doc/compiler.html)
and uses a variant of the Plan 9 loader to generate ELF binaries.
We considered writing 6g, the original Go compiler, in Go itself but
elected not to do so because of the difficulties of bootstrapping and
especially of open source distribution—you'd need a Go compiler to
set up a Go environment. Gccgo, which came later, makes it possible to
consider writing a compiler in Go, which might well happen. (Go would be a
fine language in which to implement a compiler; a native lexer and
parser are already available in /pkg/go.)
We also considered using LLVM for 6g but we felt it was too large and
slow to meet our performance goals.
Again due to bootstrapping issues, the runtime is mostly in C (with a
tiny bit of assembler) although Go is capable of implementing most of
it now. Gccgo's runtime uses glibc.
Gc uses a custom library, to keep the footprint under
control; it is
compiled with a version of the Plan 9 C compiler that supports
segmented stacks for goroutines.
Work is underway to provide the same stack management in
gccgo.
One of Go's design goals is to approach the performance of C for comparable programs, yet on some benchmarks it does quite poorly, including several in test/bench. The slowest depend on libraries for which versions of comparable performance are not available in Go. For instance, pidigits depends on a multi-precision math package, and the C versions, unlike Go's, use GMP (which is written in optimized assembler). Benchmarks that depend on regular expressions (regex-dna, for instance) are essentially comparing Go's stopgap regexp package to mature, highly optimized regular expression libraries like PCRE.
Benchmark games are won by extensive tuning and the Go versions of most of the benchmarks need attention. If you measure comparable C and Go programs (reverse-complement is one example), you'll see the two languages are much closer in raw performance than this suite would indicate.
Still, there is room for improvement. The compilers are good but could be better, many librarise need major performance work, and the garbage collector isn't fast enough yet (even if it were, taking care not to generate unnecessary garbage can have a huge effect).