Go (programming language)


Go is a statically typed, compiled programming language designed at Google by Robert Griesemer, Rob Pike, and Ken Thompson. Go is syntactically similar to C, but with memory safety, garbage collection, structural typing, and CSP-style concurrency. The language is often referred to as "Golang" because of its domain name, golang.org, but the proper name is Go.
There are two major implementations:
A third-party transpiler GopherJS compiles Go to JavaScript for front-end web development.

History

Go was designed at Google in 2007 to improve programming productivity in an era of multicore, networked machines and large codebases. The designers wanted to address [|criticism] of other languages in use at Google, but keep their useful characteristics:
The designers were primarily motivated by their shared dislike of C++.
Go was publicly announced in November 2009, and version 1.0 was released in March 2012. Go is widely used in production at Google and in many other organizations and open-source projects.
mascot
In November 2016, the Go and Go Mono fonts were released by type designers Charles Bigelow and Kris Holmes specifically for use by the Go project. Go is a humanist sans-serif which resembles Lucida Grande and Go Mono is monospaced. Each of the fonts adhere to the WGL4 character set and were designed to be legible with a large x-height and distinct letterforms. Both Go and Go Mono adhere to the DIN 1450 standard by having a slashed zero, lowercase l with a tail, and an uppercase I with serifs.
In April 2018, the original logo was replaced with a stylized GO slanting right with trailing streamlines. However, the Gopher mascot remained the same.
In August 2018, the Go principal contributors published two "draft designs" for new language features, Generics and error handling, and asked Go users to submit feedback on them.
Lack of support for generic programming and the verbosity of error handling in Go 1.x had drawn considerable criticism.

Version history

Go 1 guarantees compatibility for the language specification and major parts of the standard library. All versions up to the current Go 1.14 release have maintained this promise.
Each major Go release is supported until there are two newer major releases.
Major versionInitial release dateLanguage changesOther changes
1–1.0.32012-03-28Initial release
1.1–1.1.22013-05-13
  • In Go 1.1, an integer division by constant zero is not a legal program, so it is a compile-time error.
  • The definition of string and rune literals has been refined to exclude surrogate halves from the set of valid Unicode code points.
  • Loosened return requirements rules. If the compiler can prove that a function always returns before reaching the end of a function, a final terminating statement can be omitted.
  • The language allows the implementation to choose whether the type and types are 32 or 64 bits.
  • On 64-bit architectures, the maximum heap size has been enlarged substantially, from a few gigabytes to several tens of gigabytes.
  • Addition of a race detector to the standard tool set.
  • 1.2–1.2.22013-12-01
  • The language now specifies that, for safety reasons, certain uses of nil pointers are guaranteed to trigger a run-time panic.
  • Go 1.2 adds the ability to specify the capacity as well as the length when using a slicing operation on an existing array or slice. A slicing operation creates a new slice by describing a contiguous section of an already-created array or slice.
  • The runtime scheduler can now be invoked on function calls.
  • Go 1.2 introduces a configurable limit to the total number of threads a single program may have.
  • In Go 1.2, the minimum size of the stack when a goroutine is created has been lifted from 4KB to 8KB.
  • 1.3–1.3.32014-06-18There are no language changes in this release.
  • The Go 1.3 memory model adds a new rule concerning sending and receiving on buffered channels, to make explicit that a buffered channel can be used as a simple semaphore, using a send into the channel to acquire and a receive from the channel to release.
  • Go 1.3 has changed the implementation of goroutine stacks away from the old, "segmented" model to a contiguous model.
  • For a while now, the garbage collector has been precise when examining values in the heap; the Go 1.3 release adds equivalent precision to values on the stack.
  • Iterations over small maps no longer happen in a consistent order. This is due to developers abusing implementation behaviour.
  • 1.4–1.4.32014-12-10
  • Range-expression without assignment
  • Automatic double-dereference on method calls is now disallowed in gc and gccgo. This is a backwards incompatible change, but in line with the language specification.
  • In 1.4, much of the runtime code has been translated to Go so that the garbage collector can scan the stacks of programs in the runtime and get accurate information about what variables are active.
  • The language accepted by the assemblers, and has had several changes, mostly to make it easier to deliver type information to the runtime.
  • Addition of internal packages.
  • New subcommand go generate.
  • 1.5–1.5.42015-08-19Due to an oversight, the rule that allowed the element type to be elided from slice literals was not applied to map keys. This has been corrected in Go 1.5.
    • The compiler and runtime are now implemented in Go and assembler, without C. Now that the Go compiler and runtime are implemented in Go, a Go compiler must be available to compile the distribution from source. The compiler is now self-hosted.
    • The garbage collector has been re-engineered for 1.5. The "stop the world" phase of the collector will almost always be under 10 milliseconds and usually much less.
    • In Go 1.5, the order in which goroutines are scheduled has been changed.
    1.6–1.6.42016-02-17There are no language changes in this release.
  • A major change was made to cgo defining the rules for sharing Go pointers with C code, to ensure that such C code can coexist with Go's garbage collector.
  • The Go parser is now hand-written instead of generated.
  • The command now diagnoses passing function or method values as arguments to, such as when passing where was intended.
  • 1.7–1.7.62016-08-15Clarification on terminating statements in the language specification. This does not change existing behaviour.
    • For 64-bit x86 systems, the following instructions have been added :,,,,,,,,,,,,,,,,,, and .
    • This release includes a new code generation back end for 64-bit x86 systems, based on SSA.
    • Packages using cgo may now include Fortran source files, although the Go bindings must still use C language APIs.
    • The new subcommand “ ” prints all supported operating system/architecture pairs.
    1.8–1.8.72017-02-16When explicitly converting a value from one struct type to another, as of Go 1.8 the tags are ignored. Thus two structs that differ only in their tags may be converted from one to the other.
    • For 64-bit x86 systems, the following instructions have been added:,,,,,,, and.
    • Garbage collection pauses should be significantly shorter than they were in Go 1.7, usually under 100 microseconds and often as low as 10 microseconds. See the document on eliminating stop-the-world stack re-scanning for details.
    • The overhead of deferred function calls has been reduced by about half.
    • The overhead of calls from Go into C has been reduced by about half.
    1.9–1.9.72017-08-24
  • Go now supports type aliases.
  • Force the intermediate rounding in floating-point arithmetic.
  • The Go compiler now supports compiling a package's functions in parallel, taking advantage of multiple cores.
    1.10–1.10.72018-02-16
    • A corner case involving shifts of untyped constants has been clarified.
    • The grammar for method expressions has been updated to relax the syntax to allow any type expression as a receiver.
    For the x86 64-bit port, the assembler now supports 359 new instructions, including the full AVX, AVX2, BMI, BMI2, F16C, FMA3, SSE2, SSE3, SSSE3, SSE4.1, and SSE4.2 extension sets. The assembler also no longer implements as an instruction, to avoid clearing the condition flags unexpectedly.
    1.11–1.11.62018-08-24There are no changes to the language specification.
    • Go 1.11 adds an experimental port to WebAssembly.
    • Go 1.11 adds preliminary support for a new concept called “modules”, an alternative to GOPATH with integrated support for versioning and package distribution.
    • The assembler for now accepts AVX512 instructions.
    • Go 1.11 drops support of Windows XP and Windows Vista.
    • Go 1.11.3 and later fix the TLS authentication vulnerability in the crypto/x509 package.
    1.12.12019-02-25There are no changes to the language specification.
  • Opt-in support for TLS 1.3
  • Improved modules support
  • Support for
  • Improved macOS & iOS forwards compatibility
  • 1.13.12019-09-03Go now supports a more uniform and modernized set of number literal prefixes
    • support for TLS 1.3 in the crypto/tls package by default
    • Support for error wrapping
    1.142020-02-25Permits embedding [|interfaces] with overlapping method sets
    Module support in the command is now ready for production use

    Design

    Go is influenced by C, but with an emphasis on greater simplicity and safety. The language consists of:
    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 const char *s = "Hello, world!";. Semicolons still terminate statements,

    Types

    Go has a number of built-in types, including numeric ones, booleans, and character strings. Strings are immutable; built-in operators and keywords provide concatenation, comparison, and UTF-8 encoding/decoding. Record types can be defined with the keyword.
    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. 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. 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 of hash tables mapping type- keys to type- values. Hash tables are built into the language, with special syntax and built-in functions. is a channel that allows sending values of type T 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. Some conversions between 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:

    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 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 ZeroBroadcast bool

    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 or delegation.
    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. Go interfaces were designed after 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. Since conformance to a Go interface is checked statically by the Go compiler, 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 identify type I. For example, if, are defined as

    import "math"
    type Shape interface
    type Square struct
    func Area float64
    type Circle struct
    func Area float64

    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, and the type switch, which checks against multiple types.
    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# and is satisfied by any type, including built-in types like. Code using the empty interface cannot simply call methods 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.
    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.

    Package system

    In Go's package system, each package has a path and a name. References to other packages' definitions must always be prefixed with the other package's name, and 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 to reduce the likelihood of name collision with future additions to the standard library or other external libraries.
    Proposals exist to introduce a proper package management solution for Go similar to CPAN for Perl or Rust's cargo system or Node's npm system.

    Concurrency: goroutines and channels

    The Go language has built-in facilities, as well as library support, for writing concurrent programs. Concurrency refers not only to CPU parallelism, but also to asynchrony: letting slow operations like a database or network read run while the program does other work, as is common in event-based servers.
    The primary concurrency construct is the goroutine, a type of light-weight process. A function call prefixed with the 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.
    While a standard library package featuring most of the classical concurrency control structures is available, idiomatic concurrent programs instead prefer channels, which provide send messages between goroutines. Optional buffers store messages in FIFO order and allow sending goroutines to proceed before their messages are received.
    Channels are typed, so that a channel of type can only be used to transfer messages of type. Special syntax is used to operate on them; is an expression that causes the executing goroutine to block until a value comes in over the channel, while sends the value . The built-in -like statement can be used to implement non-blocking communication on multiple channels; see [|below] for an example. Go has a memory model describing how goroutines must use channels or other operations to safely share data.
    The existence of channels sets Go apart from actor model-style concurrent languages like Erlang, where messages are addressed directly to actors. 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, 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, and implementing iterators.
    Concurrency-related structural conventions of Go are derived from Tony Hoare's communicating sequential processes model. Unlike previous concurrent programming languages such as Occam or Limbo, 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 and speed of programs written by a seasoned programmer not familiar with the language and corrections to these programs by a Go expert, 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. The expert's programs were usually faster, but also longer.

    Lack of race condition safety

    There are no restrictions on how goroutines access shared data, making race conditions 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. Furthermore, Go's internal data structures like interface values, slice headers, hash tables, and string headers are not immune to race conditions, so type and memory safety can be violated in multithreaded programs that modify shared instances of those types without synchronization. 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 over a channel signals a transfer of ownership over the value to its receiver.

    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 inheritance, generic programming, 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, 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.
    The designers express an openness to generic programming and note that built-in functions are in fact type-generic, but these are treated as special cases; Pike calls this a weakness that may at some point be changed. The Google team built at least one compiler for an experimental Go dialect with generics, but did not release it. They are also open to standardizing ways to apply code generation.. In June 2020, a new draft design document was published, which would add the necessary syntax to Go for declaring generic functions and types. A code translation tool was provided to allow users to try out the new syntax, along with a generics-enabled version of the online Go Playground.
    Initially omitted, the exception-like / mechanism was eventually added, which the Go authors advise using 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.

    Style

    The Go authors put substantial effort into influencing the style of Go programs:
    The main Go distribution includes tools for building, testing, and analyzing code:
    It also includes profiling and debugging support, runtime instrumentation, and a race condition tester.
    An ecosystem of third-party tools adds to the standard distribution, such as gocode, which enables code autocompletion in many text editors, goimports, which automatically adds/removes package imports as needed, and errcheck, which detects code that might unintentionally ignore errors.

    Examples

    Hello world


    package main
    import "fmt"
    func main

    where "fmt" is the package for formatted I/O, similar to C's C file input/output.

    Concurrency

    The following simple program demonstrates Go's concurrency features to implement an asynchronous program. It launches two lightweight threads : one waits for the user to type some text, while the other implements a timeout. The statement waits for either of these goroutines to send a message to the main routine, and acts on the first message to arrive.

    package main
    import
    func timeout
    func main

    https://golang.org/pkg/testing/ Testing

    Target function example:
    func ExtractUsername string
    Test code :
    import

    It is possible to run tests in parallel.

    Applications

    Some notable open-source applications written in Go include:
    Other notable companies and sites using Go include:
    The interface system, and the deliberate omission of inheritance, were praised by Michele Simionato, who likened these characteristics to those of Standard ML, calling it "a shame that no popular language has followed particular route".
    Dave Astels at Engine Yard wrote:
    Go was named Programming Language of the Year by the TIOBE Programming Community Index in its first year, 2009, for having a larger 12-month increase in popularity than any other language that year, and reached 13th place by January 2010, surpassing established languages like Pascal. By June 2015, its ranking had dropped to below 50th in the index, placing it lower than COBOL and Fortran. But as of January 2017, its ranking had surged to 13th, indicating significant growth in popularity and adoption. Go was awarded TIOBE programming language of the year 2016.
    Bruce Eckel has stated:
    A 2011 evaluation of the language and its implementation in comparison to C++, Java and Scala by a Google engineer found:
    The evaluation got a rebuttal from the Go development team. Ian Lance Taylor, who had improved the Go code for Hundt's paper, had not been aware of the intention to publish his code, and says that his version was "never intended to be an example of idiomatic or efficient Go"; Russ Cox then optimized the Go code, as well as the C++ code, and got the Go code to run slightly faster than C++ and more than an order of magnitude faster than the code in the paper.

    Naming dispute

    On November 10, 2009, the day of the general release of the language, Francis McCabe, developer of the Go! programming language, requested a name change of Google's language to prevent confusion with his language, which he had spent 10 years developing. McCabe raised concerns that "the 'big guy' will end up steam-rollering over" him, and this concern resonated with the more than 120 developers who commented on Google's official issues thread saying they should change the name, with some even saying the issue contradicts Google's motto of: Don't be evil.
    On October 12, 2010, the issue was closed by Google developer Russ Cox with the custom status "Unfortunate" accompanied by the following comment:
    "There are many computing products and services named Go. In the 11 months since our release, there has been minimal confusion of the two languages."

    Criticism

    Go critics assert that: