mirror of
https://github.com/golang/go
synced 2024-11-21 21:34:40 -07:00
324 lines
11 KiB
HTML
324 lines
11 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
|
|
"http://www.w3.org/TR/html4/transitional.dtd">
|
|
<html>
|
|
<head>
|
|
|
|
<meta http-equiv="content-type" content="text/html; charset=utf-8">
|
|
<title>The Go Programming Language Design FAQ</title>
|
|
|
|
<link rel="stylesheet" type="text/css" href="style.css">
|
|
<script type="text/javascript" src="godocs.js"></script>
|
|
|
|
</head>
|
|
|
|
<body>
|
|
|
|
<div id="topnav">
|
|
<table summary=""><tr>
|
|
<td id="headerImage">
|
|
<a href="./"><img src="./logo_blue.png" height="44" width="120" alt="Go Home Page" style="border:0" /></a>
|
|
</td>
|
|
<td id="headerDocSetTitle">The Go Programming Language</td>
|
|
</tr>
|
|
</table>
|
|
</div>
|
|
|
|
<div id="linkList">
|
|
<ul>
|
|
<li class="navhead">Related Guides</li>
|
|
<li><a href="go_spec.html">Language Specification</a></li>
|
|
<li><a href="go_mem.html">Memory Model</a></li>
|
|
<li><a href="go_tutorial.html">Tutorial</a></li>
|
|
<li><a href="effective_go.html">Effective Go</a></li>
|
|
<li class="blank"> </li>
|
|
<li class="navhead">Other Resources</li>
|
|
<li><a href="go_faq.html">FAQ</a></li>
|
|
<li><a href="go_lang_faq.html">Language Design FAQ</a></li>
|
|
<li><a href="go_for_cpp_programmers.html">Go for C++ Programmers</a></li>
|
|
<li class="blank"> </li>
|
|
<li class="navhead">Home</li>
|
|
<li><a href="/">Go documentation home</a></li>
|
|
</ul>
|
|
</div>
|
|
|
|
<div id="content">
|
|
|
|
<h1 id="The_Go_Programming_Language_Design_FAQ">The Go Programming Language Design FAQ</h1>
|
|
|
|
|
|
<!-- The Table of Contents is automatically inserted in this <div>.
|
|
Do not delete this <div>. -->
|
|
<div id="nav"></div>
|
|
|
|
<h2 id="origins">Origins</h2>
|
|
|
|
<h3 id="history">
|
|
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 activities. By January 2008, Ken 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. Meanwhile, Ian
|
|
Taylor had read the draft specification and written an independent GCC
|
|
front end.
|
|
</p>
|
|
|
|
<p>
|
|
In the last few months of 2008, Russ Cox joined the team and Go had
|
|
reached the point where it was usable as the main programming language
|
|
for the team's own work.
|
|
</p>
|
|
|
|
<h3 id="creating_a_new_language">
|
|
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 commonly
|
|
available language. Programmers who could were choosing ease over
|
|
safety and efficiency by moving to dynamic 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 the dynamic
|
|
languages with the efficiency and type safety of a compiled language.
|
|
It also aims to be modern, with support for networked and multicore
|
|
computing. Finally, it 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>
|
|
|
|
|
|
<h3 id="ancestors">
|
|
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 it borrows 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>
|
|
|
|
<h3 id="protagonists">
|
|
Who are the protagonists?</h3>
|
|
<p>
|
|
Robert Griesemer, Rob Pike and Ken Thompson laid out the goals and
|
|
original specification of the language. Ian Taylor read the draft
|
|
specification and decided to write <code>gccgo</code>. Russ
|
|
Cox joined later and helped move the language and libraries from
|
|
prototype to reality.
|
|
</p>
|
|
|
|
<h2 id="change_from_c">Changes from C</h2>
|
|
|
|
<h3 id="different_syntax">
|
|
Why is the syntax so different from C?</h3>
|
|
<p>
|
|
Other than declaration syntax, the differences are not major and stem
|
|
from two desires. First, the syntax should feel light, without too
|
|
many mandatory keywords, repetition, or arcana. Second, the language
|
|
has been designed to be easy to parse. The grammar is conflict-free
|
|
and can be parsed without a symbol table. This makes it much easier
|
|
to build tools such as debuggers, dependency analyzers, automated
|
|
documentation extractors, IDE plug-ins, and so on. C and its
|
|
descendants are notoriously difficult in this regard but it's not hard
|
|
to fix things up.
|
|
</p>
|
|
|
|
<h3 id="declarations_backwards">
|
|
Why are declarations backwards?</h3>
|
|
<p>
|
|
They're only backwards if you're used to C. In C, the notion is that a
|
|
variable is declared like an expression denoting its type, which is a
|
|
nice idea, but the type and expression grammars don't mix very well and
|
|
the results can be confusing; consider function pointers. Go mostly
|
|
separates expression and type syntax and that simplifies things (using
|
|
prefix <code>*</code> for pointers is an exception that proves the rule). In C,
|
|
the declaration
|
|
</p>
|
|
<pre>
|
|
int* a, b;
|
|
</pre>
|
|
<p>
|
|
declares <code>a</code> to be a pointer but not <code>b</code>; in Go
|
|
</p>
|
|
<pre>
|
|
var a, b *int;
|
|
</pre>
|
|
<p>
|
|
declares both to be pointers. This is clearer and more regular.
|
|
Also, the <code>:=</code> short declaration form argues that a full variable
|
|
declaration should present the same order as <code>:=</code> so
|
|
</p>
|
|
<pre>
|
|
var a uint64 = 1;
|
|
</pre>
|
|
has the same effect as
|
|
<pre>
|
|
a := uint64(1);
|
|
</pre>
|
|
<p>
|
|
Parsing is also simplified by having a distinct grammar for types that
|
|
is not just the expression grammar; keywords such as <code>func</code>
|
|
and <code>chan</code> keep things clear.
|
|
</p>
|
|
|
|
<h3 id="no_pointer_arithmetic">
|
|
Why is there no pointer arithmetic?</h3>
|
|
<p>
|
|
Safety. Without pointer arithmetic it's possible to create a
|
|
language that can never derive an illegal address that succeeds
|
|
incorrectly. Compiler and hardware technology have advanced to the
|
|
point where a loop using array indices can be as efficient as a loop
|
|
using pointer arithmetic. Also, the lack of pointer arithmetic can
|
|
simplify the implementation of the garbage collector.
|
|
</p>
|
|
|
|
<h3 id="inc_dec">
|
|
Why are <code>++</code> and <code>--</code> statements and not expressions? And why postfix, not prefix?</h3>
|
|
<p>
|
|
Without pointer arithmetic, the convenience value of pre- and postfix
|
|
increment operators drops. By removing them from the expression
|
|
hierarchy altogether, expression syntax is simplified and the messy
|
|
issues around order of evaluation of <code>++</code> and <code>--</code>
|
|
(consider <code>f(i++)</code> and <code>p[i] = q[++i]</code>)
|
|
are eliminated as well. The simplification is
|
|
significant. As for postfix vs. prefix, either would work fine but
|
|
the postfix version is more traditional; insistence on prefix arose
|
|
with the STL, part of a language whose name contains, ironically, a
|
|
postfix increment.
|
|
</p>
|
|
|
|
<h2 id="absent_features">Absent features</h2>
|
|
|
|
<h3 id="generics">
|
|
Why does Go not have generic types?</h3>
|
|
<p>
|
|
Generics may well come 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>
|
|
This remains an open issue.
|
|
</p>
|
|
|
|
<h3 id="exceptions">
|
|
Why does Go not have exceptions?</h3>
|
|
<p>
|
|
Exceptions are a similar story. A number of designs for exceptions
|
|
have been proposed but each adds significant complexity to the
|
|
language and run-time. By their very nature, exceptions span functions and
|
|
perhaps even goroutines; they have wide-ranging implications. There
|
|
is also concern about the effect they would have on the
|
|
libraries. They are, by definition, exceptional yet experience with
|
|
other languages that support them show they have profound effect on
|
|
library and interface specification. It would be nice to find a design
|
|
that allows them to be truly exceptional without encouraging common
|
|
errors to turn into special control flow requiring every programmer to
|
|
compensate.
|
|
</p>
|
|
<p>
|
|
Like generics, exceptions remain an open issue.
|
|
</p>
|
|
|
|
<h3 id="assertions">
|
|
Why does Go not have assertions?</h3>
|
|
<p>
|
|
This is answered in the general <a href="go_faq.html#Where_is_assert">FAQ</a>.
|
|
</p>
|
|
|
|
<h2 id="concurrency">Concurrency</h2>
|
|
|
|
<h3 id="atomic_maps">
|
|
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 threads, and in those cases where it did, the map was
|
|
probably part of some larger data structure or computation that was already
|
|
synchronized. Therefore making 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>
|
|
|
|
<h3 id="TODO">
|
|
TODO</h3>
|
|
<p>TODO:</p>
|
|
|
|
<pre>
|
|
Why does Go not have:
|
|
- macros?
|
|
- conditional compilation?
|
|
|
|
What do you have planned?
|
|
- variant types?
|
|
|
|
explain:
|
|
package design
|
|
slices
|
|
oo separate from storage (abstraction vs. implementation)
|
|
why garbage collection?
|
|
|
|
|
|
|
|
no data in interfaces
|
|
|
|
concurrency questions:
|
|
goroutine design
|
|
why csp
|
|
|
|
inheritance?
|
|
embedding?
|
|
dependency declarations in the language
|
|
|
|
oo questions
|
|
dynamic dispatch
|
|
clean separation of interface and implementation
|
|
|
|
why no automatic numeric conversions?
|
|
|
|
make vs new
|
|
Why do maps only work on builtin types?
|
|
</pre>
|
|
|
|
|
|
</div>
|
|
|
|
<div id="footer">
|
|
<p>Except as noted, this content is
|
|
licensed under <a href="http://creativecommons.org/licenses/by/3.0/">
|
|
Creative Commons Attribution 3.0</a>.
|
|
</div>
|
|
|
|
</body>
|
|
</html>
|