another brace of questions: types, maps, bookkeeping

DELTA=136  (120 added, 13 deleted, 3 changed)
OCL=35133
CL=35147

doc/go_lang_faq.html

@@ -86,8 +86,8 @@ 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.
+Go is an attempt to combine the ease of programming of a dynamic
+language 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.
@@ -124,6 +124,31 @@ Cox joined later and helped move the language and libraries from
 prototype to reality.
 </p>
 
+<h3 id="principles">
+What are the guiding principles in the design?</h3>
+<p>
+Programming today involves too much bookkeeping, repetition, and
+clerical work.  As Dick Gabriel says, &ldquo;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?&rdquo;
+The sophistication is worthwhile&mdash;no one wants to go back to
+the old languages&mdash;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 the 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>
+
 <h2 id="change_from_c">Changes from C</h2>
 
 <h3 id="different_syntax">
@@ -250,8 +275,102 @@ Why does Go not have assertions?</h3>
 This is answered in the general <a href="go_faq.html#Where_is_assert">FAQ</a>.
 </p>
 
+<h2 id="types">Types</h2>
+
+<h3 id="inheritance">
+Why is there no type inheritance?</h3>
+<p>
+Object-oriented programming, at least in the languages we've used,
+involves too much discussion of the relationships between types,
+relationships that often could be derived automatically.  Go takes a
+different approach that we're still learning about but that feels
+useful and powerful.
+</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&mdash;one or even zero methods
+in an interface can express useful concepts.
+Interfaces can be added after the fact if a new idea comes along
+or for testing&mdash;without annotating the original type.
+Because there are no explicit relationships between types
+and interfaces, there is no type hierarchy to manage.
+</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>crypto</code> packages stitch together block and
+stream ciphers.  All these ideas stem from a single interface
+(<code>io.Writer</code>) representing a single method
+(<code>Write</code>).  We've only scratched the surface.
+</p>
+<p>
+It takes some getting used to but this implicit style of type
+dependency is one of the most exciting things about Go.
+</p>
+
+<h3 id="methods_on_basics">
+Why is <code>len</code> a function and not a method?</h3>
+<p>
+To be blunt, Go isn't that kind of language.  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.  The issue didn't seem important enough to resolve that way.
+</p>
+
+<h3 id="overloading">
+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>
+
+<h3 id="builtin_maps">
+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 to use; this seems a reasonable tradeoff.
+</p>
+
+
+<h3 id="map_keys">
+Why don't maps allow structs and arrays as keys?</h3>
+<p>
+Map lookup requires an equality operator, which structs and arrays 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 structures, and so on.
+We may revisit this issue&mdash;and implementing equality for structs and arrays
+will not invalidate any existing programs&mdash;but without a clear idea of what
+equality of structs and arrays should mean, it was simpler to leave it out for now.
+</p>
+
 <h2 id="concurrency">Concurrency</h2>
 
+<h3 id="csp">
+Why build concurrency on the ideas of CSP?</h3>
+
+<h3 id="goroutines">
+What's the idea behind goroutines?</h3>
+
 <h3 id="atomic_maps">
 Why are map operations not defined to be atomic?</h3>
 
@@ -259,7 +378,7 @@ Why are map operations not defined to be atomic?</h3>
 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
+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>
@@ -275,13 +394,6 @@ 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
@@ -290,24 +402,19 @@ why garbage collection?
 
 
 
-no data in interfaces
-
-concurrency questions:
-	goroutine design
-	why csp
 
 inheritance?
 embedding?
 dependency declarations in the language
 
 oo questions
+	no data in interfaces
 	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>