Go is influenced by
C (especially the
Plan 9 dialect), but with an emphasis on greater simplicity and safety. It consists of: • A syntax and environment adopting patterns more common in
dynamic languages: • Optional concise variable declaration and initialization through
type inference (x := 0 instead of var x int = 0; or var x = 0;) • Fast compilation • Remote package management (go get) and online package documentation • Distinctive approaches to particular problems: • Built-in concurrency primitives:
light-weight processes (goroutines),
channels, and the select statement • An
interface system in place of
virtual inheritance, and type embedding instead of non-virtual inheritance • A toolchain that, by default, produces
statically linked native binaries without external Go dependencies • A desire to keep the language specification simple enough to hold in a programmer's head, in part by
omitting features that are common in similar languages. • 25 reserved words
Syntax Go's syntax includes changes from
C aimed at keeping code concise and readable. A combined declaration/initialization operator was introduced that allows the programmer to write i := 3 or s := "Hello, world!",
without specifying the types of variables used. This contrasts with C's int i = 3; and string s = "Hello, world!"; (though since
C23 type inference has been supported using auto, like
C++). Go also removes the requirement to use parentheses in if statement conditions. Semicolons still terminate statements;{{efn|But "To allow complex statements to occupy a single line, a semicolon may be omitted before a closing ) or }".}} but are implicit when the end of a line occurs. Methods may return multiple values, and returning a result, err pair is the conventional way a method indicates an error to its caller in Go. Go adds literal syntaxes for initializing struct parameters by name and for initializing
maps and
slices. As an alternative to C's three-statement for loop, Go's range expressions allow concise iteration over arrays, slices, strings, maps, and channels.
Keywords Go contains the following 25 keywords: • break • case • chan • const • continue • default • defer • else • fallthrough • for • func • go • goto • if • import • interface • map • package • range • return • select • struct • switch • type • var
Types Go has a number of built-in types, including numeric ones (, , , etc.),
Booleans, and byte strings (). Strings are immutable; built-in operators and keywords (rather than functions) provide concatenation, comparison, and
UTF-8 encoding/decoding.
Record types can be defined with the keyword. Go contains the following primitives: • bool • int8 • uint8 • int16 • uint16 • int32 • uint32 • int64 • uint64 • int • uint • uintptr • float32 • float64 • complex64 • complex128 • string Note that byte is an alias for uint8 and rune is an alias for int32. For each type and each non-negative integer constant , there is an
array type denoted ; arrays of differing lengths are thus of different types.
Dynamic arrays are available as "slices", denoted for some type (compare to other languages like C/C++ and
Java, where instead the arrays are denoted ) These have a length and a
capacity specifying when new memory needs to be allocated to expand the array. Several slices may share their underlying memory.
Pointers are available for all types, and the pointer-to- type is denoted (similar to
Rust; compare to other languages like C/C++ and
C#, where pointers are denoted ). Address-taking and indirection use the and operators, as in C, or happen implicitly through the method call or attribute access syntax. There is no pointer arithmetic, except via the special type in the standard library. For a pair of types , , the type is the type mapping type- keys to type- values, which can be thought of as equivalent to in other languages. The Go Programming Language specification does not give any performance guarantees or implementation requirements for map types, though it is usually implemented as a
hash table (equivalent to in other languages). Hash tables are built into the language, with special syntax and built-in functions. is a
channel that allows sending values of type between
concurrent Go processes. Aside from its support for
interfaces, Go's type system is
nominal: the keyword can be used to define a new
named type, which is distinct from other named types that have the same layout (in the case of a , the same members in the same order). Some conversions between types (e.g., between the various integer types) are pre-defined and adding a new type may define additional conversions, but conversions between named types must always be invoked explicitly. For example, the keyword can be used to define a type for
IPv4 addresses, based on 32-bit unsigned integers as follows: type ipv4addr uint32 With this type definition, interprets the value as an IP address. Simply assigning to a variable of type is a type error.
Constant expressions may be either typed or "untyped"; they are given a type when assigned to a typed variable if the value they represent passes a compile-time check.
Function types are indicated by the keyword; they take zero or more
parameters and
return zero or more values, all of which are typed. The parameter and return values determine a function type; thus, is the type of functions that take a and a 32-bit signed integer, and return a signed integer (of default width) and a value of the built-in interface type . Any named type has a
method set associated with it. The IP address example above can be extended with a method for checking whether its value is a known standard: // ZeroBroadcast reports whether addr is 255.255.255.255. func (addr ipv4addr) ZeroBroadcast() bool { return addr == 0xFFFFFFFF } Due to nominal typing, this method definition adds a method to , but not on . While methods have special definition and call syntax, there is no distinct method type.
Interface system Go provides two features that replace
class inheritance. The first is
embedding, which can be viewed as an automated form of
composition. The second are its
interfaces, which provides
runtime polymorphism. Interfaces are a class of types and provide a limited form of
structural typing in the otherwise nominal type system of Go. An object which is of an interface type is also of another type, much like
C++ objects being simultaneously of a base and derived class. The design of Go interfaces was inspired by
protocols from the Smalltalk programming language. Multiple sources use the term
duck typing when describing Go interfaces. Although the term duck typing is not precisely defined and therefore not wrong, it usually implies that type conformance is not statically checked. Because conformance to a Go interface is checked statically by the Go compiler (except when performing a type assertion), the Go authors prefer the term
structural typing. The definition of an interface type lists required methods by name and type. Any object of type T for which functions exist matching all the required methods of interface type I is an object of type I as well. The definition of type T need not (and cannot) identify type I. For example, if , are defined as import "math" type Shape interface { Area() float64 } // Note: no "implements" declaration type Square struct { side float64 } func (sq Square) Area() float64 { return sq.side * sq.side } // No "implements" declaration here either type Circle struct { radius float64 } func (c Circle) Area() float64 { return math.Pi * math.Pow(c.radius, 2) } then both a and a are implicitly a and can be assigned to a -typed variable. In formal language, Go's interface system provides
structural rather than
nominal typing. Interfaces can embed other interfaces with the effect of creating a combined interface that is satisfied by exactly the types that implement the embedded interface and any methods that the newly defined interface adds. The Go standard library uses interfaces to provide genericity in several places, including the input/output system that is based on the concepts of and . Besides calling methods via interfaces, Go allows converting interface values to other types with a run-time type check. The language constructs to do so are the
type assertion, which checks against a single potential type: var shp Shape = Square{5} square, ok := shp.(Square) // Asserts Square type on shp, should work if ok { fmt.Printf("%#v\n", square) } else { fmt.Println("Can't print shape as Square") } and the
type switch, which checks against multiple types: func (sq Square) Diagonal() float64 { return sq.side * math.Sqrt2 } func (c Circle) Diameter() float64 { return 2 * c.radius } func LongestContainedLine(shp Shape) float64 { switch v := shp.(type) { case Square: return v.Diagonal() // Or, with type assertion, shp.(Square).Diagonal() case Circle: return v.Diameter() // Or, with type assertion, shp.(Circle).Diameter() default: return 0 // In practice, this should be handled with errors } } The
empty interface interface{} is an important base case because it can refer to an item of
any concrete type. It is similar to the class in
Java or
C# or void* in
C or Any in
C++ and
Rust and is satisfied by any type, including built-in types like . Code using the empty interface cannot simply call methods (or built-in operators) on the referred-to object, but it can store the interface{} value, try to convert it to a more useful type via a type assertion or type switch, or inspect it with Go's reflect package. Because interface{} can refer to any value, it is a limited way to escape the restrictions of static typing, like void* in C but with additional run-time type checks. The interface{} type can be used to model structured data of any arbitrary schema in Go, such as
JSON or
YAML data, by representing it as a map[string]interface{} (map of string to empty interface). This recursively describes data in the form of a dictionary with string keys and values of any type. Interface values are implemented using pointer to data and a second pointer to run-time type information. Like some other types implemented using pointers in Go, interface values are nil if uninitialized.
Generic code using parameterized types Since version 1.18, Go supports generic code using parameterized types. Functions and types now have the ability to be generic using type parameters. These type parameters are specified within square brackets, right after the function or type name. The compiler transforms the generic function or type into non-generic by substituting
type arguments for the type parameters provided, either explicitly by the user or type inference by the compiler. This transformation process is referred to as type instantiation. Interfaces now can define a set of types (known as type set) using | (Union) operator, as well as a set of methods. These changes were made to support type constraints in generics code. For a generic function or type, a constraint can be thought of as the type of the type argument: a meta-type. This new ~T syntax will be the first use of ~ as a token in Go. ~T means the set of all types whose underlying type is T. type Number interface { ~int | ~float64 | ~float32 | ~int32 | ~int64 } func Add[T Number](nums ...T) T { var sum T for _, v := range nums { sum += v } return sum } func main() { add := Add[int] // Type instantiation println(add(1, 2, 3, 4, 5)) // 15 res := Add(1.1, 2.2, 3.3, 4.4, 5.5) // Type Inference println(res) // +1.650000e+001 }
Enumerated types Package system In Go's package system, each package has a path (e.g., "compress/bzip2" or "golang.org/x/net/html") and a name (e.g., bzip2 or html). By default other packages' definitions must
always be prefixed with the other package's name. However the name used can be changed from the package name, and if imported as _, then no package prefix is required. Only the
capitalized names from other packages are accessible: io.Reader is public but bzip2.reader is not. The go get command can retrieve packages stored in a remote repository and developers are encouraged to develop packages inside a base path corresponding to a source repository (such as example.com/user_name/package_name) to reduce the likelihood of name collision with future additions to the standard library or other external libraries.
Concurrency: goroutines and channels The Go language has built-in facilities, as well as library support, for writing
concurrent programs. The runtime is
asynchronous: program execution that performs, for example, a network read will be suspended until data is available to process, allowing other parts of the program to perform other work. This is built into the runtime and does not require any changes in program code. The go runtime also automatically schedules concurrent operations (goroutines) across multiple CPUs; this can achieve parallelism for a properly written program. The primary concurrency construct is the
goroutine, a type of
green thread. A function call prefixed with the go keyword starts a function in a new goroutine. The language specification does not specify how goroutines should be implemented, but current implementations multiplex a Go process's goroutines onto a smaller set of
operating-system threads, similar to the scheduling performed in
Erlang and
Haskell's
Glasgow Haskell Compiler (GHC) runtime implementation. While a standard library package featuring most of the classical
concurrency control structures (
mutex locks, etc.) is available, idiomatic concurrent programs instead prefer
channels, which
send messages between goroutines. Optional buffers store messages in
FIFO order and allow sending goroutines to proceed before their messages are received. The existence of channels does not by itself set Go apart from
actor model-style concurrent languages like Erlang, where messages are addressed directly to actors (corresponding to goroutines). In the actor model, channels are themselves actors, therefore addressing a channel just means to address an actor. The actor style can be simulated in Go by maintaining a one-to-one correspondence between goroutines and channels, but the language allows multiple goroutines to share a channel or a single goroutine to send and receive on multiple channels. From these tools one can build concurrent constructs like
worker pools, pipelines (in which, say, a file is decompressed and parsed as it downloads), background calls with timeout, "fan-out" parallel calls to a set of services, and others. Channels have also found uses further from the usual notion of interprocess communication, like serving as a concurrency-safe list of recycled buffers, implementing
coroutines (which helped inspire the name
goroutine), and implementing
iterators. Concurrency-related structural conventions of Go (
channels and alternative channel inputs) are derived from
Tony Hoare's communicating sequential processes model. Unlike previous concurrent programming languages such as
Occam or
Limbo (a language on which Go co-designer Rob Pike worked), Go does not provide any built-in notion of safe or verifiable concurrency. While the communicating-processes model is favored in Go, it is not the only one: all goroutines in a program share a single address space. This means that mutable objects and pointers can be shared between goroutines; see , below.
Suitability for parallel programming Although Go's concurrency features are not aimed primarily at
parallel processing, they can be used to program
shared-memory multi-processor machines. Various studies have been done into the effectiveness of this approach. One of these studies compared the size (in
lines of code) and speed of programs written by a seasoned programmer not familiar with the language and corrections to these programs by a Go expert (from Google's development team), doing the same for
Chapel,
Cilk and
Intel TBB. The study found that the non-expert tended to write
divide-and-conquer algorithms with one statement per recursion, while the expert wrote distribute-work-synchronize programs using one goroutine per processor core. The expert's programs were usually faster, but also longer.
Lack of data race safety Go's approach to concurrency can be summarized as "don't communicate by sharing memory; share memory by communicating". There are no restrictions on how goroutines access shared data, making
data races possible. Specifically, unless a program explicitly synchronizes via channels or other means, writes from one goroutine might be partly, entirely, or not at all visible to another, often with no guarantees about ordering of writes. Instead of language support, safe concurrent programming thus relies on conventions; for example, Chisnall recommends an idiom called "aliases
xor mutable", meaning that passing a mutable value (or pointer) over a channel signals a transfer of ownership over the value to its receiver. The gc toolchain has an optional data race detector that can check for unsynchronized access to shared memory during runtime since version 1.1, additionally a best-effort race detector is also included by default since version 1.6 of the gc runtime for access to the map data type.
Binaries The linker in the gc toolchain creates statically linked binaries by default; therefore all Go binaries include the Go runtime.
Omissions Go deliberately omits certain features common in other languages, including
(implementation) inheritance,
assertions,
pointer arithmetic,
implicit type conversions,
untagged unions, and
tagged unions. The designers added only those facilities that all three agreed on. Of the omitted language features, the designers explicitly argue against assertions and pointer arithmetic, while defending the choice to omit type inheritance as giving a more useful language, encouraging instead the use of
interfaces to achieve
dynamic dispatch and
composition to reuse code. Composition and
delegation are in fact largely automated by embedding; according to researchers Schmager
et al., this feature "has many of the drawbacks of inheritance: it affects the public interface of objects, it is not fine-grained (i.e, no method-level control over embedding), methods of embedded objects cannot be hidden, and it is static", making it "not obvious" whether programmers will overuse it to the extent that programmers in other languages are reputed to overuse inheritance.
Exception handling was initially omitted in Go due to lack of a "design that gives value proportionate to the complexity". An exception-like / mechanism that avoids the usual try-catch control structure was proposed and released in the March 30, 2010 snapshot. The Go authors advise using it for unrecoverable errors such as those that should halt an entire program or server request, or as a shortcut to propagate errors up the stack within a package. Across package boundaries, Go includes a canonical error type, and multi-value returns using this type are the standard idiom. ==Style==