doc/go1: new introduction

This distills the motivational discussion and makes it the introduction to the release notes.
After this lands, I'll expand the discussion of the major changes to include more background.

Updates #3086.

R=golang-dev, gri, rsc
CC=golang-dev
https://golang.org/cl/5698057

doc/go1.html

@@ -10,29 +10,46 @@
 <h2 id="introduction">Introduction to Go 1</h2>
 
 <p>
-For a full explanation of the motivation and design of Go 1, see XXX.
+Go version 1, Go 1 for short, defines a language and a set of core libraries
-Here follows a summary.
+that provide a stable foundation for creating reliable products, projects, and
+publications.
 </p>
 
 <p>
-Go 1 is intended to be a stable language and core library set that
+The driving motivation for Go 1 is stability for its users. People should be able to
-will form a reliable foundation for people and organizations that
+write Go programs and expect that they will continue to compile and run without
-want to make a long-term commitment to developing in the Go programming
+change, on a time scale of years, including in production environments such as
-language. Go will continue to develop, but in a way that guarantees
+Google App Engine. Similarly, people should be able to write books about Go, be
-code written to the Go 1 specification will continue to work. For
+able to say which version of Go the book is describing, and have that version
-instance, Go 1 will be a supported platform on Google App Engine
+number still be meaningful much later.
-for the next few years. Incompatible changes to the environment,
-should they arise, will be done in a distinct version.
 </p>
 
 <p>
-This document describes the changes in the language and libraries
+Code that compiles in Go 1 should, with few exceptions, continue to compile and
-in Go 1, relative to the previous release, r60 (at the time of
+run throughout the lifetime of that version, even as we issue updates and bug
-writing, tagged as r60.3). It also explains how to update code at
+fixes such as Go version 1.1, 1.2, and so on. Other than critical fixes, changes
-r60 to compile and run under Go 1. Finally, it outlines the new
+made to the language and library for subsequent releases of Go 1 may
-<code>go</code> command for building Go programs and the new binary
+add functionality but will not break existing Go 1 programs.
-release process being introduced. Most of these topics have more
+<a href="go1compat.html">The Go 1 compatibility document</a>
-thorough presentations elsewhere; such documents are linked below.
+explains the compatibility guidelines in more detail.
+</p>
+
+<p>
+Go 1 is a representation of Go as it used today, not a wholesale rethinking of
+the language. We avoided designing new features and instead focused on cleaning
+up problems and inconsistencies and improving portability. There are a number
+changes to the Go language and packages that we had considered for some time and
+prototyped but not released primarily because they are significant and
+backwards-incompatible. Go 1 was an opportunity to get them out, which is
+helpful for the long term, but also means that Go 1 introduces incompatibilities
+for old programs. Fortunately, the <code>go</code> <code>fix</code> tool can
+automate much of the work needed to bring programs up to the Go 1 standard.
+</p>
+
+<p>
+This document outlines the major changes in Go 1 that will affect programmers
+updating existing code; its reference point is the prior release, r60 (tagged as
+r60.3). It also explains how to update code from r60 to run under Go 1.
 </p>
 
 <h2 id="language">Changes to the language</h2>

doc/go1.tmpl

@@ -6,29 +6,46 @@
 <h2 id="introduction">Introduction to Go 1</h2>
 
 <p>
-For a full explanation of the motivation and design of Go 1, see XXX.
+Go version 1, Go 1 for short, defines a language and a set of core libraries
-Here follows a summary.
+that provide a stable foundation for creating reliable products, projects, and
+publications.
 </p>
 
 <p>
-Go 1 is intended to be a stable language and core library set that
+The driving motivation for Go 1 is stability for its users. People should be able to
-will form a reliable foundation for people and organizations that
+write Go programs and expect that they will continue to compile and run without
-want to make a long-term commitment to developing in the Go programming
+change, on a time scale of years, including in production environments such as
-language. Go will continue to develop, but in a way that guarantees
+Google App Engine. Similarly, people should be able to write books about Go, be
-code written to the Go 1 specification will continue to work. For
+able to say which version of Go the book is describing, and have that version
-instance, Go 1 will be a supported platform on Google App Engine
+number still be meaningful much later.
-for the next few years. Incompatible changes to the environment,
-should they arise, will be done in a distinct version.
 </p>
 
 <p>
-This document describes the changes in the language and libraries
+Code that compiles in Go 1 should, with few exceptions, continue to compile and
-in Go 1, relative to the previous release, r60 (at the time of
+run throughout the lifetime of that version, even as we issue updates and bug
-writing, tagged as r60.3). It also explains how to update code at
+fixes such as Go version 1.1, 1.2, and so on. Other than critical fixes, changes
-r60 to compile and run under Go 1. Finally, it outlines the new
+made to the language and library for subsequent releases of Go 1 may
-<code>go</code> command for building Go programs and the new binary
+add functionality but will not break existing Go 1 programs.
-release process being introduced. Most of these topics have more
+<a href="go1compat.html">The Go 1 compatibility document</a>
-thorough presentations elsewhere; such documents are linked below.
+explains the compatibility guidelines in more detail.
+</p>
+
+<p>
+Go 1 is a representation of Go as it used today, not a wholesale rethinking of
+the language. We avoided designing new features and instead focused on cleaning
+up problems and inconsistencies and improving portability. There are a number
+changes to the Go language and packages that we had considered for some time and
+prototyped but not released primarily because they are significant and
+backwards-incompatible. Go 1 was an opportunity to get them out, which is
+helpful for the long term, but also means that Go 1 introduces incompatibilities
+for old programs. Fortunately, the <code>go</code> <code>fix</code> tool can
+automate much of the work needed to bring programs up to the Go 1 standard.
+</p>
+
+<p>
+This document outlines the major changes in Go 1 that will affect programmers
+updating existing code; its reference point is the prior release, r60 (tagged as
+r60.3). It also explains how to update code from r60 to run under Go 1.
 </p>
 
 <h2 id="language">Changes to the language</h2>