go/doc/go_faq.html at go1.10 · dominicbarnes/go

Repository navigation

10BC8

<!--{

"Title": "Frequently Asked Questions (FAQ)",

"Path": "/doc/faq"

}-->

<h2 id="Origins">Origins</h2>

What is the purpose of the project?</h3>

<p>

No major systems language has emerged in over a decade, but over that time

the computing landscape has changed tremendously. There are several trends:

</p>

<ul>

<li>

Computers are enormously quicker but software development is not faster.

<li>

Dependency management is a big part of software development today but the

“header files” of languages in the C tradition are antithetical to clean

dependency analysis—and fast compilation.

<li>

There is a growing rebellion against cumbersome type systems like those of

Java and C++, pushing people towards dynamically typed languages such as

Python and JavaScript.

<li>

Some fundamental concepts such as garbage collection and parallel computation

are not well supported by popular systems languages.

<li>

The emergence of multicore computers has generated worry and confusion.

</ul>

<p>

We believe it's worth trying again with a new language, a concurrent,

garbage-collected language with fast compilation. Regarding the points above:

</p>

<ul>

<li>

It is possible to compile a large Go program in a few seconds on a single computer.

<li>

Go provides a model for software construction that makes dependency

analysis easy and avoids much of the overhead of C-style include files and

libraries.

<li>

Go's type system has no hierarchy, so no time is spent defining the

relationships between types. Also, although Go has static types the language

attempts to make types feel lighter weight than in typical OO languages.

<li>

Go is fully garbage-collected and provides fundamental support for

concurrent execution and communication.

<li>

By its design, Go proposes an approach for the construction of system

software on multicore machines.

</ul>

<p>

A much more expansive answer to this question is available in the article,

<a href="//talks.golang.org/2012/splash.article">Go at Google:

Language Design in the Service of Software Engineering</a>.

What is the status of the project?</h3>

<p>

Go became a public open source project on November 10, 2009.

After a couple of years of very active design and development, stability was called for and

Go 1 was <a href="//blog.golang.org/2012/03/go-version-1-is-released.html">released</a>

on March 28, 2012.

Go 1, which includes a <a href="/ref/spec">language specification</a>,

<a href="/pkg/">standard libraries</a>,

and <a href="/cmd/go/">custom tools</a>,

provides a stable foundation for creating reliable products, projects, and publications.

</p>

<p>

With that stability established, we are using Go to develop programs, products, and tools rather than

actively changing the language and libraries.

In fact, the purpose of Go 1 is to provide <a href="/doc/go1compat.html">long-term stability</a>.

Backwards-incompatible changes will not be made to any Go 1 point release.

We want to use what we have to learn how a future version of Go might look, rather than to play with

the language underfoot.

</p>

<p>

Of course, development will continue on Go itself, but the focus will be on performance, reliability,

portability and the addition of new functionality such as improved support for internationalization.

</p>

<p>

There may well be a Go 2 one day, but not for a few years and it will be influenced by what we learn using Go 1 as it is today.

</p>

What's the origin of the mascot?</h3>

<p>

The mascot and logo were designed by

<a href="http://reneefrench.blogspot.com">Renée French</a>, who also designed

<a href="https://9p.io/plan9/glenda.html">Glenda</a>,

the Plan 9 bunny.

The <a href="https://blog.golang.org/gopher">gopher</a>

is derived from one she used for an <a href="http://wfmu.org/">WFMU</a>

T-shirt design some years ago.

The logo and mascot are covered by the

<a href="http://creativecommons.org/licenses/by/3.0/">Creative Commons Attribution 3.0</a>

license.

</p>

What is the history of the project?</h3>

<p>

Robert Griesemer, Rob Pike and Ken Thompson started sketching the

goals for a new language on the white board on September 21, 2007.

Within a few days the goals had settled into a plan to do something

and a fair idea of what it would be. Design continued part-time in

parallel with unrelated work. By January 2008, Ken had started work

on a compiler with which to explore ideas; it generated C code as its

output. By mid-year the language had become a full-time project and

had settled enough to attempt a production compiler. In May 2008,

Ian Taylor independently started on a GCC front end for Go using the

draft specification. Russ Cox joined in late 2008 and helped move the language

and libraries from prototype to reality.

</p>

<p>

Go became a public open source project on November 10, 2009.

Many people from the community have contributed ideas, discussions, and code.

</p>

Why are you creating a new language?</h3>

<p>

Go was born out of frustration with existing languages and

environments for systems programming. Programming had become too

difficult and the choice of languages was partly to blame. One had to

choose either efficient compilation, efficient execution, or ease of

programming; all three were not available in the same mainstream

language. Programmers who could were choosing ease over

safety and efficiency by moving to dynamically typed languages such as

Python and JavaScript rather than C++ or, to a lesser extent, Java.

</p>

<p>

Go is an attempt to combine the ease of programming of an interpreted,

dynamically typed

language with the efficiency and safety of a statically typed, compiled language.

It also aims to be modern, with support for networked and multicore

computing. Finally, working with Go is intended to be <i>fast</i>: it should take

at most a few seconds to build a large executable on a single computer.

To meet these goals required addressing a number of

linguistic issues: an expressive but lightweight type system;

concurrency and garbage collection; rigid dependency specification;

and so on. These cannot be addressed well by libraries or tools; a new

language was called for.

</p>

<p>

The article <a href="//talks.golang.org/2012/splash.article">Go at Google</a>

discusses the background and motivation behind the design of the Go language,

as well as providing more detail about many of the answers presented in this FAQ.

</p>

What are Go's ancestors?</h3>

<p>

Go is mostly in the C family (basic syntax),

with significant input from the Pascal/Modula/Oberon

family (declarations, packages),

plus some ideas from languages

inspired by Tony Hoare's CSP,

such as Newsqueak and Limbo (concurrency).

However, it is a new language across the board.

In every respect the language was designed by thinking

about what programmers do and how to make programming, at least the

kind of programming we do, more effective, which means more fun.

</p>

What are the guiding principles in the design?</h3>

<p>

Programming today involves too much bookkeeping, repetition, and

clerical work. As Dick Gabriel says, “Old programs read

like quiet conversations between a well-spoken research worker and a

well-studied mechanical colleague, not as a debate with a compiler.

Who'd have guessed sophistication bought such noise?”

The sophistication is worthwhile—no one wants to go back to

the old languages—but can it be more quietly achieved?

</p>

<p>

Go attempts to reduce the amount of typing in both senses of the word.

Throughout its design, we have tried to reduce clutter and

complexity. There are no forward declarations and no header files;

everything is declared exactly once. Initialization is expressive,

automatic, and easy to use. Syntax is clean and light on keywords.

Stuttering (<code>foo.Foo* myFoo = new(foo.Foo)</code>) is reduced by

simple type derivation using the <code>:=</code>

declare-and-initialize construct. And perhaps most radically, there

is no type hierarchy: types just <i>are</i>, they don't have to

announce their relationships. These simplifications allow Go to be

expressive yet comprehensible without sacrificing, well, sophistication.

</p>

<p>

Another important principle is to keep the concepts orthogonal.

Methods can be implemented for any type; structures represent data while

interfaces represent abstraction; and so on. Orthogonality makes it

easier to understand what happens when things combine.

</p>

<h2 id="Usage">Usage</h2>

<h3 id="Is_Google_using_go_internally"> Is Google using Go internally?</h3>

<p>

Yes. There are now several Go programs deployed in

production inside Google. A public example is the server behind

<a href="//golang.org">golang.org</a>.

It's just the <a href="/cmd/godoc"><code>godoc</code></a>

document server running in a production configuration on

<a href="https://developers.google.com/appengine/">Google App Engine</a>.

</p>

<p>

Other examples include the <a href="//github.com/youtube/vitess/">Vitess</a>

system for large-scale SQL installations and Google's download server, <code>dl.google.com</code>,

which delivers Chrome binaries and other large installables such as <code>apt-get</code>

packages.

</p>

Do Go programs link with C/C++ programs?</h3>

<p>

There are two Go compiler implementations, <code>gc</code>

and <code>gccgo</code>.

<code>Gc</code> 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.

<code>Gccgo</code> is a GCC front-end that can, with care, be linked with

GCC-compiled C or C++ programs.

</p>

<p>

The <a href="/cmd/cgo/">cgo</a> program provides the mechanism for a

“foreign function interface” to allow safe calling of

C libraries from Go code. SWIG extends this capability to C++ libraries.

</p>

Does Go support Google's protocol buffers?</h3>

<p>

A separate open source project provides the necessary compiler plugin and library.

It is available at

<a href="//github.com/golang/protobuf">github.com/golang/protobuf/</a>

</p>

Can I translate the Go home page into another language?</h3>

<p>

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 <a href="//golang.org/">golang.org</a>),

you will need to abide by the guidelines at

<a href="//www.google.com/permissions/guidelines.html">www.google.com/permissions/guidelines.html</a>

</p>

<h2 id="Design">Design</h2>

Does Go have a runtime?</h3>

<p>

Go does have an extensive library, called the <em>runtime</em>,

that is part of every Go program.

The runtime library implements garbage collection, concurrency,

stack management, and other critical features of the Go language.

Although it is more central to the language, Go's runtime is analogous

to <code>libc</code>, the C library.

</p>

<p>

It is important to understand, however, that Go's runtime does not

include a virtual machine, such as is provided by the Java runtime.

Go programs are compiled ahead of time to native machine code.

Thus, although the term is often used to describe the virtual

environment in which a program runs, in Go the word “runtime”

is just the name given to the library providing critical language services.

</p>

What's up with Unicode identifiers?</h3>

<p>

It was important to us to extend the space of identifiers from the

confines of ASCII. Go's rule—identifier characters must be

letters or digits as defined by Unicode—is simple to understand

and to implement but has restrictions. Combining characters are

excluded by design, for instance.

Until there

is an agreed external definition of what an identifier might be,

plus a definition of canonicalization of identifiers that guarantees

no ambiguity, it seemed better to keep combining characters out of

the mix. Thus we have a simple rule that can be expanded later

without breaking programs, one that avoids bugs that would surely arise

from a rule that admits ambiguous identifiers.

</p>

<p>

On a related note, since an exported identifier must begin with an

upper-case letter, identifiers created from “letters”

in some languages can, by definition, not be exported. For now the

only solution is to use something like <code>X日本語</code>, which

is clearly unsatisfactory; we are considering other options. The

case-for-visibility rule is unlikely to change however; it's one

of our favorite features of Go.

</p>

<h3 id="Why_doesnt_Go_have_feature_X">Why does Go not have feature X?</h3>

<p>

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.

</p>

<p>

If it bothers you that Go is missing feature <var>X</var>,

please forgive us and investigate the features that Go does have. You might find that

they compensate in interesting ways for the lack of <var>X</var>.

</p>

Why does Go not have generic types?</h3>

<p>

Generics may well be added at some point. We don't feel an urgency for

them, although we understand some programmers do.

</p>

<p>

Generics are convenient but they come at a cost in

complexity in the type system and run-time. We haven't yet found a

design that gives value proportionate to the complexity, although we

continue to think about it. Meanwhile, Go's built-in maps and slices,

plus the ability to use the empty interface to construct containers

(with explicit unboxing) mean in many cases it is possible to write

code that does what generics would enable, if less smoothly.

</p>

<p>

The topic remains open.

For a look at several previous unsuccessful attempts to

design a good generics solution for Go, see

<a href="https://golang.org/issue/15292">this proposal</a>.

</p>

Why does Go not have exceptions?</h3>

<p>

We believe that coupling exceptions to a control

structure, as in the <code>try-catch-finally</code> idiom, results in

convoluted code. It also tends to encourage programmers to label

too many ordinary errors, such as failing to open a file, as

exceptional.

</p>

<p>

Go takes a different approach. For plain error handling, Go's multi-value

returns make it easy to report an error without overloading the return value.

<a href="/doc/articles/error_handling.html">A canonical error type, coupled

with Go's other features</a>, makes error handling pleasant but quite different

from that in other languages.

</p>

<p>

Go also has a couple

of built-in functions to signal and recover from truly exceptional

conditions. The recovery mechanism is executed only as part of a

function's state being torn down after an error, which is sufficient

to handle catastrophe but requires no extra control structures and,

when used well, can result in clean error-handling code.

</p>

<p>

See the <a href="/doc/articles/defer_panic_recover.html">Defer, Panic, and Recover</a> article for details.

</p>

Why does Go not have assertions?</h3>

<p>

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.

</p>

<p>

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.

</p>

Why build concurrency on the ideas of CSP?</h3>

<p>

Concurrency and multi-threaded programming have a reputation

for difficulty. We believe this is due partly to complex

designs such as pthreads and partly to overemphasis on low-level details

such as mutexes, condition variables, and memory barriers.

Higher-level interfaces enable much simpler code, even if there are still

mutexes and such under the covers.

</p>

<p>

One of the most successful models for providing high-level linguistic support

for concurrency comes from Hoare's Communicating Sequential Processes, or CSP.

Occam and Erlang are two well known languages that stem from CSP.

Go's concurrency primitives derive from a different part of the family tree

whose main contribution is the powerful notion of channels as first class objects.

Experience with several earlier languages has shown that the CSP model

fits well into a procedural language framework.

</p>

Why goroutines instead of threads?</h3>

<p>

Goroutines are part of making concurrency easy to use. The idea, which has

been around for a while, is to multiplex independently executing

functions—coroutines—onto a set of threads.

When a coroutine blocks, such as by calling a blocking system call,

the run-time automatically moves other coroutines on the same operating

system thread to a different, runnable thread so they won't be blocked.

The programmer sees none of this, which is the point.

The result, which we call goroutines, can be very cheap: they have little

overhead beyond the memory for the stack, which is just a few kilobytes.

</p>

<p>

To make the stacks small, Go's run-time uses resizable, bounded stacks. A newly

minted goroutine is given a few kilobytes, which is almost always enough.

When it isn't, the run-time grows (and shrinks) the memory for storing

the stack automatically, allowing many goroutines to live in a modest

amount of memory.

The CPU overhead averages about three cheap instructions per function call.

It is practical to create hundreds of thousands of goroutines in the same

address space.

If goroutines were just threads, system resources would

run out at a much smaller number.

</p>

Why are map operations not defined to be atomic?</h3>

<p>

After long discussion it was decided that the typical use of maps did not require

safe access from multiple goroutines, and in those cases where it did, the map was

probably part of some larger data structure or computation that was already

synchronized. Therefore requiring that all map operations grab a mutex would slow

down most programs and add safety to few. This was not an easy decision,

however, since it means uncontrolled map access can crash the program.

</p>

<p>

The language does not preclude atomic map updates. When required, such

as when hosting an untrusted program, the implementation could interlock

map access.

</p>

<p>

Map access is unsafe only when updates are occurring.

As long as all goroutines are only reading—looking up elements in the map,

including iterating through it using a

<code>for</code> <code>range</code> loop—and not changing the map

by assigning to elements or doing deletions,

it is safe for them to access the map concurrently without synchronization.

</p>

Will you accept my language change?</h3>

<p>

People often suggest improvements to the language—the

<a href="//groups.google.com/group/golang-nuts">mailing list</a>

contains a rich history of such discussions—but very few of these changes have

been accepted.

</p>

<p>

Although Go is an open source project, the language and libraries are protected

by a <a href="/doc/go1compat.html">compatibility promise</a> that prevents

changes that break existing programs.

If your proposal violates the Go 1 specification we cannot even entertain the

idea, regardless of its merit.

A future major release of Go may be incompatible with Go 1, but we're not ready

to start talking about what that might be.

</p>

<p>

Even if your proposal is compatible with the Go 1 spec, it might

not be in the spirit of Go's design goals.

The article <i><a href="//talks.golang.org/2012/splash.article">Go

at Google: Language Design in the Service of Software Engineering</a></i>

explains Go's origins and the motivation behind its design.

</p>

<h2 id="types">Types</h2>

Is Go an object-oriented language?</h3>

<p>

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, even built-in types such

as plain, “unboxed” integers.

They are not restricted to structs (classes).

</p>

<p>

Also, the lack of a type hierarchy makes “objects” in Go feel much more

lightweight than in languages such as C++ or Java.

</p>

How do I get dynamic dispatch of methods?</h3>

<p>

The only way to have dynamically dispatched methods is through an

interface. Methods on a struct or any other concrete type are always resolved statically.

</p>

Why is there no type inheritance?</h3>

<p>

Object-oriented programming, at least in the best-known languages,

involves too much discussion of the relationships between types,

relationships that often could be derived automatically. Go takes a

different approach.

</p>

<p>

Rather than requiring the programmer to declare ahead of time that two

types are related, in Go a type automatically satisfies any interface

that specifies a subset of its methods. Besides reducing the

bookkeeping, this approach has real advantages. Types can satisfy

many interfaces at once, without the complexities of traditional

multiple inheritance.

Interfaces can be very lightweight—an interface with

one or even zero methods can express a useful concept.

Interfaces can be added after the fact if a new idea comes along

or for testing—without annotating the original types.

Because there are no explicit relationships between types

and interfaces, there is no type hierarchy to manage or discuss.

</p>

<p>

It's possible to use these ideas to construct something analogous to

type-safe Unix pipes. For instance, see how <code>fmt.Fprintf</code>

enables formatted printing to any output, not just a file, or how the

<code>bufio</code> package can be completely separate from file I/O,

or how the <code>image</code> packages generate compressed

image files. All these ideas stem from a single interface

(<code>io.Writer</code>) representing a single method

(<code>Write</code>). And that's only scratching the surface.

Go's interfaces have a profound influence on how programs are structured.

</p>

<p>

It takes some getting used to but this implicit style of type

dependency is one of the most productive things about Go.

</p>

Why is <code>len</code> a function and not a method?</h3>

<p>

We debated this issue but decided

implementing <code>len</code> and friends as functions was fine in practice and

didn't complicate questions about the interface (in the Go type sense)

of basic types.

</p>

Why does Go not support overloading of methods and operators?</h3>

<p>

Method dispatch is simplified if it doesn't need to do type matching as well.

Experience with other languages told us that having a variety of

methods with the same name but different signatures was occasionally useful

but that it could also be confusing and fragile in practice. Matching only by name

and requiring consistency in the types was a major simplifying decision

in Go's type system.

</p>

<p>

Regarding operator overloading, it seems more a convenience than an absolute

requirement. Again, things are simpler without it.

</p>

Why doesn't Go have "implements" declarations?</h3>

<p>

A Go type satisfies an interface by implementing the methods of that interface,

nothing more. This property allows interfaces to be defined and used without

having to modify existing code. It enables a kind of structural typing that

promotes separation of concerns and improves code re-use, and makes it easier

to build on patterns that emerge as the code develops.

The semantics of interfaces is one of the main reasons for Go's nimble,

lightweight feel.

</p>

<p>

See the <a href="#inheritance">question on type inheritance</a> for more detail.

</p>

How can I guarantee my type satisfies an interface?</h3>

<p>

You can ask the compiler to check that the type <code>T</code> implements the

interface <code>I</code> by attempting an assignment using the zero value for

<code>T</code> or pointer to <code>T</code>, as appropriate:

</p>

<pre>

type T struct{}

var _ I = T{} // Verify that T implements I.

var _ I = (*T)(nil) // Verify that *T implements I.

</pre>

<p>

If <code>T</code> (or <code>*T</code>, accordingly) doesn't implement

<code>I</code>, the mistake will be caught at compile time.

</p>

<p>

If you wish the users of an interface to explicitly declare that they implement

it, you can add a method with a descriptive name to the interface's method set.

For example:

</p>

<pre>

type Fooer interface {

Foo()

ImplementsFooer()

}

</pre>

<p>

A type must then implement the <code>ImplementsFooer</code> method to be a

<code>Fooer</code>, clearly documenting the fact and announcing it in

<a href="/cmd/godoc/">godoc</a>'s output.

</p>

<pre>

type Bar struct{}

func (b Bar) ImplementsFooer() {}

func (b Bar) Foo() {}

</pre>

<p>

Most code doesn't make use of such constraints, since they limit the utility of

the interface idea. Sometimes, though, they're necessary to resolve ambiguities

among similar interfaces.

</p>

Why doesn't type T satisfy the Equal interface?</h3>

<p>

Consider this simple interface to represent an object that can compare

itself with another value:

</p>

<pre>

type Equaler interface {

Equal(Equaler) bool

}

</pre>

<p>

and this type, <code>T</code>:

</p>

<pre>

type T int

func (t T) Equal(u T) bool { return t == u } // does not satisfy Equaler

</pre>

<p>

Unlike the analogous situation in some polymorphic type systems,

<code>T</code> does not implement <code>Equaler</code>.

The argument type of <code>T.Equal</code> is <code>T</code>,

not literally the required type <code>Equaler</code>.

</p>

<p>

In Go, the type system does not promote the argument of

<code>Equal</code>; that is the programmer's responsibility, as

illustrated by the type <code>T2</code>, which does implement

<code>Equaler</code>:

</p>

<pre>

type T2 int

func (t T2) Equal(u Equaler) bool { return t == u.(T2) } // satisfies Equaler

</pre>

<p>

Even this isn't like other type systems, though, because in Go <em>any</em>

type that satisfies <code>Equaler</code> could be passed as the

argument to <code>T2.Equal</code>, and at run time we must

check that the argument is of type <code>T2</code>.

Some languages arrange to make that guarantee at compile time.

</p>

<p>

A related example goes the other way:

</p>

<pre>

type Opener interface {

Open() Reader

}

func (t T3) Open() *os.File

</pre>

<p>

In Go, <code>T3</code> does not satisfy <code>Opener</code>,

although it might in another language.

</p>

<p>

While it is true that Go's type system does less for the programmer

in such cases, the lack of subtyping makes the rules about

interface satisfaction very easy to state: are the function's names

and signatures exactly those of the interface?

Go's rule is also easy to implement efficiently.

We feel these benefits offset the lack of

automatic type promotion. Should Go one day adopt some form of polymorphic

typing, we expect there would be a way to express the idea of these

examples and also have them be statically checked.

</p>

Can I convert a []T to an []interface{}?</h3>

<p>

Not directly, because they do not have the same representation in memory.

It is necessary to copy the elements individually to the destination

slice. This example converts a slice of <code>int</code> to a slice of

<code>interface{}</code>:

</p>

<pre>

t := []int{1, 2, 3, 4}

s := make([]interface{}, len(t))

for i, v := range t {

s[i] = v

}

</pre>

Can I convert []T1 to []T2 if T1 and T2 have the same underlying type?</h3>

This last line of this code sample does not compile.

<pre>

type T1 int

type T2 int

var t1 T1

var x = T2(t1) // OK

var st1 []T1

var sx = ([]T2)(st1) // NOT OK

</pre>

<p>

In Go, types are closely tied to methods FFFD , in that every named type has

a (possibly empty) method set.

The general rule is that you can change the name of the type being

converted (and thus possibly change its method set) but you can't

change the name (and method set) of elements of a composite type.

Go requires you to be explicit about type conversions.

</p>

Why is my nil error value not equal to nil?

</h3>

<p>

Under the covers, interfaces are implemented as two elements, a type and a value.

The value, called the interface's dynamic value,

is an arbitrary concrete value and the type is that of the value.

For the <code>int</code> value 3, an interface value contains,

schematically, (<code>int</code>, <code>3</code>).

</p>

<p>

An interface value is <code>nil</code> only if the inner value and type are both unset,

(<code>nil</code>, <code>nil</code>).

In particular, a <code>nil</code> interface will always hold a <code>nil</code> type.

If we store a <code>nil</code> pointer of type <code>*int</code> inside

an interface value, the inner type will be <code>*int</code> regardless of the value of the pointer:

(<code>*int</code>, <code>nil</code>).

Such an interface value will therefore be non-<code>nil</code>

<em>even when the pointer inside is</em> <code>nil</code>.

</p>

<p>

This situation can be confusing, and arises when a <code>nil</code> value is

stored inside an interface value such as an <code>error</code> return:

</p>

<pre>

func returnsError() error {

var p *MyError = nil

if bad() {

p = ErrBad

}

return p // Will always return a non-nil error.

}

</pre>

<p>

If all goes well, the function returns a <code>nil</code> <code>p</code>,

so the return value is an <code>error</code> interface

value holding (<code>*MyError</code>, <code>nil</code>).

This means that if the caller compares the returned error to <code>nil</code>,

it will always look as if there was an error even if nothing bad happened.

To return a proper <code>nil</code> <code>error</code> to the caller,

the function must return an explicit <code>nil</code>:

</p>

<pre>

func returnsError() error {

if bad() {

return ErrBad

}

return nil

}

</pre>

<p>

It's a good idea for functions

that return errors always to use the <code>error</code> type in

their signature (as we did above) rather than a concrete type such

as <code>*MyError</code>, to help guarantee the error is

created correctly. As an example,

returns an <code>error</code> even though, if not <code>nil</code>,

it's always of concrete type

<a href="/pkg/os/#PathError"><code>*os.PathError</code></a>.

</p>

<p>

Similar situations to those described here can arise whenever interfaces are used.

Just keep in mind that if any concrete value

has been stored in the interface, the interface will not be <code>nil</code>.

For more information, see

<a href="/doc/articles/laws_of_reflection.html">The Laws of Reflection</a>.

</p>

Why are there no untagged unions, as in C?</h3>

<p>

Untagged unions would violate Go's memory safety

guarantees.

</p>

Why does Go not have variant types?</h3>

<p>

Variant types, also known as algebraic types, provide a way to specify

that a value might take one of a set of other types, but only those

types. A common example in systems programming would specify that an

error is, say, a network error, a security error or an application

error and allow the caller to discriminate the source of the problem

by examining the type of the error. Another example is a syntax tree

in which each node can be a different type: declaration, statement,

assignment and so on.

</p>

<p>

We considered adding variant types to Go, but after discussion

decided to leave them out because they overlap in confusing ways

with interfaces. What would happen if the elements of a variant type

were themselves interfaces?

</p>

<p>

Also, some of what variant types address is already covered by the

language. The error example is easy to express using an interface

value to hold the error and a type switch to discriminate cases. The

syntax tree example is also doable, although not as elegantly.

</p>

Why does Go not have covariant result types?</h3>

<p>

Covariant result types would mean that an interface like

</p>

<pre>

type Copyable interface {

Copy() interface{}

}

</pre>

<p>

would be satisfied by the method

</p>

<pre>

func (v Value) Copy() Value

</pre>

<p>because <code>Value</code> implements the empty interface.

In Go method types must match exactly, so <code>Value</code> does not

implement <code>Copyable</code>.

Go separates the notion of what a

type does—its methods—from the type's implementation.

If two methods return different types, they are not doing the same thing.

Programmers who want covariant result types are often trying to

express a type hierarchy through interfaces.

In Go it's more natural to have a clean separation between interface

and implementation.

</p>

<h2 id="values">Values</h2>

Why does Go not provide implicit numeric conversions?</h3>

<p>

The convenience of automatic conversion between numeric types in C is

outweighed by the confusion it causes. When is an expression unsigned?

How big is the value? Does it overflow? Is the result portable, independent

of the machine on which it executes?

It also complicates the compiler; “the usual arithmetic conversions”

are not easy to implement and inconsistent across architectures.

For reasons of portability, we decided to make things clear and straightforward

at the cost of some explicit conversions in the code.

The definition of constants in Go—arbitrary precision values free

of signedness and size annotations—ameliorates matters considerably,

though.

</p>

<p>

A related detail is that, unlike in C, <code>int</code> and <code>int64</code>

are distinct types even if <code>int</code> is a 64-bit type. The <code>int</code>

type is generic; if you care about how many bits an integer holds, Go

encourages you to be explicit.

</p>

<p>

A blog post titled <a href="https://blog.golang.org/constants">Constants</a>

explores this topic in more detail.

</p>

Why are maps built in?</h3>

<p>

The same reason strings are: they are such a powerful and important data

structure that providing one excellent implementation with syntactic support

makes programming more pleasant. We believe that Go's implementation of maps

is strong enough that it will serve for the vast majority of uses.

If a specific application can benefit from a custom implementation, it's possible

to write one but it will not be as convenient syntactically; this seems a reasonable tradeoff.

</p>

Why don't maps allow slices as keys?</h3>

<p>

Map lookup requires an equality operator, which slices do not implement.

They don't implement equality because equality is not well defined on such types;

there are multiple considerations involving shallow vs. deep comparison, pointer vs.

value comparison, how to deal with recursive types, and so on.

We may revisit this issue—and implementing equality for slices

View remainder of file in raw view

FilesExpand file tree

go_faq.html

Latest commit

History

go_faq.html

File metadata and controls