doc/go_lang_faq.html - go - Git at Google

 <!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_tutorial.html">Tutorial</a></li>
     <li><a href="go_spec.html">Language Specification</a></li>
     <li><a href="go_faq.html">FAQ</a></li>
     <li class="blank">&nbsp;</li>
     <li class="navhead">Other Resources</li>
     <li><a href="./">Go Docs</a></li>
     <li><a href="/pkg">Library documentation</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="creating_a_new_language">
 Why are you creating a new language?</h3>
 <p>
 TODO
 </p>

 <h3 id="history">
 What is the history of the project?</h3>
 <p>
 TODO
 </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, they span functions and
 perhaps even goroutines; they have wide-ranging implications.  There
 is also concern about the effect exceptions 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 definition.  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>

 <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 aren't maps atomic
 	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>
	<!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_tutorial.html">Tutorial</a></li>
	<li><a href="go_spec.html">Language Specification</a></li>
	<li><a href="go_faq.html">FAQ</a></li>
	<li class="blank"> </li>
	<li class="navhead">Other Resources</li>
	<li><a href="./">Go Docs</a></li>
	<li><a href="/pkg">Library documentation</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="creating_a_new_language">
	Why are you creating a new language?</h3>
	<p>
	TODO
	</p>

	<h3 id="history">
	What is the history of the project?</h3>
	<p>
	TODO
	</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, they span functions and
	perhaps even goroutines; they have wide-ranging implications. There
	is also concern about the effect exceptions 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 definition. 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>

	<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 aren't maps atomic
	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>