doc/code: drop mentions of GOPATH/pkg directory

It's already half gone and later will be all gone.
It's not worth explaining in an introduction doc.

Fixes #24506
Updates #4719

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

doc/code.html

@@ -44,18 +44,16 @@ control repositories.
 <h3 id="Workspaces">Workspaces</h3>
 
 <p>
-A workspace is a directory hierarchy with three directories at its root:
+A workspace is a directory hierarchy with two directories at its root:
 </p>
 
 <ul>
-<li><code>src</code> contains Go source files,
-<li><code>pkg</code> contains package objects, and
+<li><code>src</code> contains Go source files, and
 <li><code>bin</code> contains executable commands.
 </ul>
 
 <p>
-The <code>go</code> tool builds source packages and installs the resulting
-binaries to the <code>pkg</code> and <code>bin</code> directories.
+The <code>go</code> tool builds and installs binaries to the <code>bin</code> directory.
 </p>
 
 <p>
@@ -72,10 +70,6 @@ To give you an idea of how a workspace looks in practice, here's an example:
 bin/
     hello                          # command executable
     outyet                         # command executable
-pkg/
-    linux_amd64/
-        github.com/golang/example/
-            stringutil.a           # package object
 src/
     <a href="https://github.com/golang/example/">github.com/golang/example/</a>
         .git/                      # Git repository metadata
@@ -374,9 +368,8 @@ $ <b>go build</b>
 </pre>
 
 <p>
-This won't produce an output file. To do that, you must use <code>go
-install</code>, which places the package object inside the <code>pkg</code>
-directory of the workspace.
+This won't produce an output file.
+Instead it saves the compiled package in the local build cache.
 </p>
 
 <p>
@@ -400,19 +393,13 @@ func main() {
 </pre>
 
 <p>
-Whenever the <code>go</code> tool installs a package or binary, it also
-installs whatever dependencies it has.
-So when you install the <code>hello</code> program
+Install the <code>hello</code> program:
 </p>
 
 <pre>
 $ <b>go install github.com/user/hello</b>
 </pre>
 
-<p>
-the <code>stringutil</code> package will be installed as well, automatically.
-</p>
-
 <p>
 Running the new version of the program, you should see a new, reversed message:
 </p>
@@ -429,10 +416,6 @@ After the steps above, your workspace should look like this:
 <pre>
 bin/
     hello                 # command executable
-pkg/
-    linux_amd64/          # this will reflect your OS and architecture
-        github.com/user/
-            stringutil.a  # package object
 src/
     github.com/user/
         hello/
@@ -441,22 +424,6 @@ src/
             reverse.go    # package source
 </pre>
 
-<p>
-Note that <code>go install</code> placed the <code>stringutil.a</code> object
-in a directory inside <code>pkg/linux_amd64</code> that mirrors its source
-directory.
-This is so that future invocations of the <code>go</code> tool can find the
-package object and avoid recompiling the package unnecessarily.
-The <code>linux_amd64</code> part is there to aid in cross-compilation,
-and will reflect the operating system and architecture of your system.
-</p>
-
-<p>
-Go command executables are statically linked; the package objects need not
-be present to run Go programs.
-</p>
-
-
 <h3 id="PackageNames">Package names</h3>
 
 <p>
@@ -597,12 +564,6 @@ tree should now look like this:
 <pre>
 bin/
     hello                           # command executable
-pkg/
-    linux_amd64/
-        github.com/golang/example/
-            stringutil.a            # package object
-        github.com/user/
-            stringutil.a            # package object
 src/
     github.com/golang/example/
 	.git/                       # Git repository metadata