From: Rob Pike <r@golang.org>
Date: Wed, 29 Nov 2017 05:05:01 +0000 (+1100)
Subject: doc/faq: tweak the wording in the new section on goroutine IDs
X-Git-Tag: go1.10beta1~121
X-Git-Url: http://www.git.cypherpunks.su/?a=commitdiff_plain;h=21672b36eb0ad3bf1e2220b247900b2c63664464;p=gostls13.git

doc/faq: tweak the wording in the new section on goroutine IDs

There were too many changes of direction. Tidy up the intro a little
for better flow, and delete some unnecessary comments.

Change-Id: Ib5d85c0992626bd3152f86a51585884d3e0cab72
Reviewed-on: https://go-review.googlesource.com/80495
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
---

diff --git a/doc/go_faq.html b/doc/go_faq.html
index 89ed86ee9c..62349fe5f7 100644
--- a/doc/go_faq.html
+++ b/doc/go_faq.html
@@ -1488,15 +1488,15 @@ the goroutine later.
 </p>
 
 <p>
-The usage patterns that develop when threads and goroutines are
+The fundamental reason goroutines are anonymous is so that
+the full Go language is available when programming concurrent code.
+By contrast, the usage patterns that develop when threads and goroutines are
 named can restrict what a library using them can do.
-Goroutines
-are anonymous so the full Go language is available when programming
-concurrent code.
 </p>
 
 <p>
-For example, once one names a goroutine and constructs a model around
+Here is an illustration of the difficulties.
+Once one names a goroutine and constructs a model around
 it, it becomes special, and one is tempted to associate all computation
 with that goroutine, ignoring the possibility
 of using multiple, possibly shared goroutines for the processing.
@@ -1507,9 +1507,9 @@ when serving a request.
 </p>
 
 <p>
-Also, experience with libraries, such as those for graphics systems,
-that require all processing to occur on the "main thread",
-shows how awkward and limiting the approach can be when
+Moreover, experience with libraries such as those for graphics systems
+that require all processing to occur on the "main thread"
+has shown how awkward and limiting the approach can be when
 deployed in a concurrent language.
 The very existence of a special thread or goroutine forces
 the programmer to distort the program to avoid crashes