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 89ed86ee9c66cd928848ff85b493e6a3d37e8c06..62349fe5f7dc37fa118f3556dacc469cd8f85d0f 100644 (file)
--- 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