all: remove everything; moved to x/website

Change-Id: Ibf88119ca2a021dc1abf01b83abb9ac850127a91
Reviewed-on: https://go-review.googlesource.com/c/blog/+/324270
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
diff --git a/AUTHORS b/AUTHORS
deleted file mode 100644
index 2b00ddb..0000000
--- a/AUTHORS
+++ /dev/null
@@ -1,3 +0,0 @@
-# This source code refers to The Go Authors for copyright purposes.
-# The master list of authors is in the main Go distribution,
-# visible at https://tip.golang.org/AUTHORS.
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
deleted file mode 100644
index d0485e8..0000000
--- a/CONTRIBUTING.md
+++ /dev/null
@@ -1,26 +0,0 @@
-# Contributing to Go
-
-Go is an open source project.
-
-It is the work of hundreds of contributors. We appreciate your help!
-
-## Filing issues
-
-When [filing an issue](https://golang.org/issue/new), make sure to answer these five questions:
-
-1.  What version of Go are you using (`go version`)?
-2.  What operating system and processor architecture are you using?
-3.  What did you do?
-4.  What did you expect to see?
-5.  What did you see instead?
-
-General questions should go to the [golang-nuts mailing list](https://groups.google.com/group/golang-nuts) instead of the issue tracker.
-The gophers there will answer or ask you to file an issue if you've tripped over a bug.
-
-## Contributing code
-
-Please read the [Contribution Guidelines](https://golang.org/doc/contribute.html)
-before sending patches.
-
-Unless otherwise noted, the Go source files are distributed under
-the BSD-style license found in the LICENSE file.
diff --git a/CONTRIBUTORS b/CONTRIBUTORS
deleted file mode 100644
index 1fbd3e9..0000000
--- a/CONTRIBUTORS
+++ /dev/null
@@ -1,3 +0,0 @@
-# This source code was written by the Go contributors.
-# The master list of contributors is in the main Go distribution,
-# visible at https://tip.golang.org/CONTRIBUTORS.
diff --git a/LICENSE b/LICENSE
deleted file mode 100644
index 6a66aea..0000000
--- a/LICENSE
+++ /dev/null
@@ -1,27 +0,0 @@
-Copyright (c) 2009 The Go Authors. All rights reserved.
-
-Redistribution and use in source and binary forms, with or without
-modification, are permitted provided that the following conditions are
-met:
-
-   * Redistributions of source code must retain the above copyright
-notice, this list of conditions and the following disclaimer.
-   * Redistributions in binary form must reproduce the above
-copyright notice, this list of conditions and the following disclaimer
-in the documentation and/or other materials provided with the
-distribution.
-   * Neither the name of Google Inc. nor the names of its
-contributors may be used to endorse or promote products derived from
-this software without specific prior written permission.
-
-THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
-"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
-LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
-A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
-OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
-SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
-LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
-DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
-THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
-(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
-OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
diff --git a/PATENTS b/PATENTS
deleted file mode 100644
index 7330990..0000000
--- a/PATENTS
+++ /dev/null
@@ -1,22 +0,0 @@
-Additional IP Rights Grant (Patents)
-
-"This implementation" means the copyrightable works distributed by
-Google as part of the Go project.
-
-Google hereby grants to You a perpetual, worldwide, non-exclusive,
-no-charge, royalty-free, irrevocable (except as stated in this section)
-patent license to make, have made, use, offer to sell, sell, import,
-transfer and otherwise run, modify and propagate the contents of this
-implementation of Go, where such license applies only to those patent
-claims, both currently owned or controlled by Google and acquired in
-the future, licensable by Google that are necessarily infringed by this
-implementation of Go.  This grant does not include claims that would be
-infringed only as a consequence of further modification of this
-implementation.  If you or your agent or exclusive licensee institute or
-order or agree to the institution of patent litigation against any
-entity (including a cross-claim or counterclaim in a lawsuit) alleging
-that this implementation of Go or any code incorporated within this
-implementation of Go constitutes direct or contributory patent
-infringement, or inducement of patent infringement, then any patent
-rights granted to you under this License for this implementation of Go
-shall terminate as of the date such litigation is filed.
diff --git a/README.md b/README.md
index d25e498..a123056 100644
--- a/README.md
+++ b/README.md
@@ -1,69 +1,5 @@
-# Go Blog
+# Go Blog (obsolete)
 
-[![Go Reference](https://pkg.go.dev/badge/golang.org/x/blog.svg)](https://pkg.go.dev/golang.org/x/blog)
+This repository formerly held the Go Blog server code and content.
 
-This repository holds the Go Blog server code and content.
-
-## Download/Install
-
-The easiest way to install is to run `go get -u golang.org/x/blog`. You can also
-manually git clone the repository to \$GOPATH/src/golang.org/x/blog.
-
-## Running Locally
-
-To run the blog server locally:
-
-```
-go run . -reload
-```
-
-and then visit [http://localhost:8080/](http://localhost:8080) in your browser.
-
-## Contributing
-
-Articles are written in the [x/tools/present][present] format.
-Articles on the blog should have broad interest to the Go community, and
-are mainly written by Go contributors. We encourage you to share your
-experiences using Go on your own website, and [to share them with the Go
-community][community]. [Hugo][hugo] is a static site server written in Go that
-makes it easy to write and share your stories.
-
-[present]: https://godoc.org/golang.org/x/tools/present
-[community]: https://golang.org/help/
-[hugo]: https://gohugo.io/
-
-## Report Issues / Send Patches
-
-This repository uses Gerrit for code changes. To learn how to submit changes to
-this repository, see https://golang.org/doc/contribute.html.
-
-The main issue tracker for the blog is located at
-https://github.com/golang/go/issues. Prefix your issue with "x/blog:" in the
-subject line, so it is easy to find.
-
-## Deploying
-
-The Google Cloud project triggers a fresh deploy of the blog on each submit
-but that deployment is published to a temporary URL.
-
-To publish the blog to blog.golang.org, you need access to the
-Cloud Console for the golang-org project.
-Then:
-
-1. Visit the
-   [builds list](https://console.cloud.google.com/cloud-build/builds?project=golang-org&query=trigger_id%3D%22c99674d3-32c1-4aec-ade4-ae2d5a844369%22)
-   and click on the build hash for the most recent build
-   with trigger name “Redeploy-blog-on-blog-commit”.
-
-   Scrolling to the bottom of the build log, you will find a URL in a log message like
-
-       Deployed service [blog] to [https://TEMPORARYURL.appspot.com]
-
-2. Copy that URL and load it in your browser. Check that it looks OK.
-
-3. Assuming it does, visit the
-   [AppEngine versions list](https://console.cloud.google.com/appengine/versions?project=golang-org&serviceId=blog).
-   Click “Migrate Traffic” on the new entry to move 100% of the blog.golang.org
-   traffic to the new version.
-
-4. You're done.
+That material has since moved to [golang.org/x/website](https://golang.org/x/website).
diff --git a/_content/10years.article b/_content/10years.article
deleted file mode 100644
index 5c2d69a..0000000
--- a/_content/10years.article
+++ /dev/null
@@ -1,137 +0,0 @@
-# Go Turns 10
-8 Nov 2019
-Summary: Happy 10th birthday, Go!
-
-Russ Cox, for the Go team
-rsc@golang.org
-
-##
-
-Happy birthday, Go!
-
-This weekend we celebrate the 10th anniversary of
-[the Go release](https://opensource.googleblog.com/2009/11/hey-ho-lets-go.html),
-marking the 10th birthday of Go as an open-source programming language
-and ecosystem for building modern networked software.
-
-To mark the occasion,
-[Renee French](https://twitter.com/reneefrench),
-the creator of the
-[Go gopher](https://blog.golang.org/gopher),
-painted this delightful scene:
-
-<a href="10years/gopher10th-large.jpg">
-.image 10years/gopher10th-small.jpg _ 850
-</a>
-
-Celebrating 10 years of Go makes me think back to early November 2009,
-when we were getting ready to share Go with the world.
-We didn’t know what kind of reaction to expect,
-whether anyone would care about this little language.
-I hoped that even if no one ended up using Go,
-we would at least have drawn attention to some good ideas,
-especially Go’s approach to concurrency and interfaces,
-that could influence follow-on languages.
-
-Once it became clear that people were excited about Go,
-I looked at the history of popular languages
-like C, C++, Perl, Python, and Ruby,
-examining how long each took to gain widespread adoption.
-For example, Perl seemed to me to have appeared fully-formed
-in the mid-to-late 1990s, with CGI scripts and the web,
-but it was first released in 1987.
-This pattern repeated for almost every language I looked at:
-it seems to take roughly a decade of quiet, steady improvement
-and dissemination before a new language really takes off.
-
-I wondered: where would Go be after a decade?
-
-Today, we can answer that question:
-Go is everywhere, used by at least [a million developers worldwide](https://research.swtch.com/gophercount).
-
-Go’s original target was networked system infrastructure,
-what we now call cloud software.
-Every major cloud provider today uses core cloud infrastructure written in Go,
-such as Docker, Etcd, Istio, Kubernetes, Prometheus, and Terraform;
-the majority of the
-[Cloud Native Computing Foundation’s projects](https://www.cncf.io/projects/)
-are written in Go.
-Countless companies are using Go to move their own work to the cloud as well,
-from startups building from scratch
-to enterprises modernizing their software stack.
-Go has also found adoption well beyond its original cloud target,
-with uses ranging
-from
-controlling tiny embedded systems with
-[GoBot](https://gobot.io) and [TinyGo](https://tinygo.org/)
-to detecting cancer with
-[massive big data analysis and machine learning at GRAIL](https://medium.com/grail-eng/bigslice-a-cluster-computing-system-for-go-7e03acd2419b),
-and everything in between.
-
-All this is to say that Go has succeeded beyond our wildest dreams.
-And Go’s success isn’t just about the language.
-It’s about the language, the ecosystem, and especially the community working together.
-
-In 2009, the language was a good idea with a working sketch of an implementation.
-The `go` command did not exist:
-we ran commands like `6g` to compile and `6l` to link binaries,
-automated with makefiles.
-We typed semicolons at the ends of statements.
-The entire program stopped during garbage collection,
-which then struggled to make good use of two cores.
-Go ran only on Linux and Mac, on 32- and 64-bit x86 and 32-bit ARM.
-
-Over the last decade, with the help of Go developers all over the world,
-we have evolved this idea and sketch into a productive language
-with fantastic tooling,
-a production-quality implementation,
-a
-[state-of-the-art garbage collector](https://blog.golang.org/ismmkeynote),
-and [ports to 12 operating systems and 10 architectures](https://golang.org/doc/install/source#introduction).
-
-Any programming language needs the support of a thriving ecosystem.
-The open source release was the seed for that ecosystem,
-but since then, many people have contributed their time and talent
-to fill the Go ecosystem with great tutorials, books, courses, blog posts,
-podcasts, tools, integrations, and of course reusable Go packages importable with `go` `get`.
-Go could never have succeeded without the support of this ecosystem.
-
-Of course, the ecosystem needs the support of a thriving community.
-In 2019 there are dozens of Go conferences all over the world,
-along with
-[over 150 Go meetup groups with over 90,000 members](https://www.meetup.com/pro/go).
-[GoBridge](https://golangbridge.org)
-and
-[Women Who Go](https://medium.com/@carolynvs/www-loves-gobridge-ccb26309f667)
-help bring new voices into the Go community,
-through mentoring, training, and conference scholarships.
-This year alone, they have taught
-hundreds of people from traditionally underrepresented groups
-at workshops where community members teach and mentor those new to Go.
-
-There are
-[over a million Go developers](https://research.swtch.com/gophercount)
-worldwide,
-and companies all over the globe are looking to hire more.
-In fact, people often tell us that learning Go
-helped them get their first jobs in the tech industry.
-In the end, what we’re most proud of about Go
-is not a well-designed feature or a clever bit of code
-but the positive impact Go has had in so many people’s lives.
-We aimed to create a language that would help us be better developers,
-and we are thrilled that Go has helped so many others.
-
-As
-[\#GoTurns10](https://twitter.com/search?q=%23GoTurns10),
-I hope everyone will take a moment to celebrate
-the Go community and all we have achieved.
-On behalf of the entire Go team at Google,
-thank you to everyone who has joined us over the past decade.
-Let’s make the next one even more incredible!
-
-<div>
-<center>
-<a href="10years/gopher10th-pin-large.jpg">
-.image 10years/gopher10th-pin-small.jpg _ 150
-</center>
-</div>
diff --git a/_content/10years/gopher10th-large.jpg b/_content/10years/gopher10th-large.jpg
deleted file mode 100644
index 9866013..0000000
--- a/_content/10years/gopher10th-large.jpg
+++ /dev/null
Binary files differ
diff --git a/_content/10years/gopher10th-pin-large.jpg b/_content/10years/gopher10th-pin-large.jpg
deleted file mode 100644
index e1dfebf..0000000
--- a/_content/10years/gopher10th-pin-large.jpg
+++ /dev/null
Binary files differ
diff --git a/_content/10years/gopher10th-pin-small.jpg b/_content/10years/gopher10th-pin-small.jpg
deleted file mode 100644
index d52de7f..0000000
--- a/_content/10years/gopher10th-pin-small.jpg
+++ /dev/null
Binary files differ
diff --git a/_content/10years/gopher10th-small.jpg b/_content/10years/gopher10th-small.jpg
deleted file mode 100644
index f6e776c..0000000
--- a/_content/10years/gopher10th-small.jpg
+++ /dev/null
Binary files differ
diff --git a/_content/11years.article b/_content/11years.article
deleted file mode 100644
index 1c2188f..0000000
--- a/_content/11years.article
+++ /dev/null
@@ -1,233 +0,0 @@
-# Eleven Years of Go
-12:01 10 Nov 2020
-Summary: Happy Birthday, Go!
-
-Russ Cox, for the Go team
-
-##
-
-Today we celebrate the eleventh birthday of the Go open source release.
-The parties we had for
-[Go turning 10](https://blog.golang.org/10years)
-seem like a distant memory.
-It’s been a tough year, but
-we’ve kept Go development moving forward
-and accumulated quite a few highlights.
-
-In November, we launched [go.dev and pkg.go.dev](https://blog.golang.org/go.dev)
-shortly after Go’s 10th birthday.
-
-In February, the [Go 1.14 release](https://blog.golang.org/go1.14)
-delivered the first officially “production-ready” implementation of Go modules,
-along with many performance improvements,
-including
-[faster defers](https://golang.org/design/34481-opencoded-defers)
-and
-[non-cooperative goroutine preemption](https://golang.org/design/24543/conservative-inner-frame)
-to reduce scheduling
-and garbage collection latency.
-
-In early March, we launched a
-[new API for protocol buffers](https://blog.golang.org/protobuf-apiv2),
-[google.golang.org/protobuf](https://pkg.go.dev/google.golang.org/protobuf),
-with much-improved support for protocol buffer reflection and custom messages.
-
-<img src="11years/gophermask.jpg" height="450" width="300" align="right" style="border: 2px solid black; margin: 0 0 1em 1em;">
-
-When the pandemic hit, we decided to pause any public announcements
-or launches in the spring,
-recognizing that everyone’s attention rightly belonged elsewhere.
-But we kept working, and one of our team members joined the
-Apple/Google collaboration on
-[privacy-preserving exposure notifications](https://www.google.com/covid19/exposurenotifications/)
-to support contact tracing efforts all over the world.
-In May, that group launched the
-[reference backend server](https://github.com/google/exposure-notifications-server),
-written in Go.
-
-We continued to improve [gopls](https://www.youtube.com/watch?v=EFJfdWzBHwE),
-which enables advanced
-[Go-aware support](https://github.com/golang/tools/blob/master/gopls/doc/user.md)
-in many editors.
-In June, the
-[VSCode Go extension officially joined the Go project](https://blog.golang.org/vscode-go)
-and is now maintained by the same developers who work on gopls.
-
-Also in June, thanks to your feedback, we open-sourced
-[the code behind pkg.go.dev](https://blog.golang.org/pkgsite)
-as part of the Go project as well.
-
-Later in June, we
-[released the latest design draft for generics](https://blog.golang.org/generics-next-step),
-along with a prototype tool and [generics playground](https://go2goplay.golang.org/).
-
-In July, we published and discussed three new design drafts for future changes:
-[new `//go:build` lines for file selection](https://golang.org/design/draft-gobuild),
-[file system interfaces](https://golang.org/design/draft-iofs),
-and
-[build-time file embedding](https://golang.org/design/draft-embed).
-(We’ll see all of those in 2021, as noted below.)
-
-In August, the [Go 1.15 release](https://blog.golang.org/go1.15)
-delivered mainly optimizations and bug fixes rather than new features.
-The most significant was the start of a rewrite of the linker,
-making it run 20% faster and use 30% less memory
-on average for large builds.
-
-Last month, we ran our [annual Go user survey](https://blog.golang.org/survey2020).
-We will post results on the blog once we’ve analyzed them.
-
-The Go community has adapted to “virtual-first” along with everyone else,
-and we saw many virtual meetups and over a dozen virtual Go conferences this year.
-Last week, the Go team hosted
-[Go day at Google Open Source Live](https://opensourcelive.withgoogle.com/events/go)
-(videos at the link).
-
-## Going Forward
-
-We’re also incredibly excited about what’s in store for Go’s 12th year.
-Most immediately, this week Go team members will
-be presenting eight events at
-[GopherCon 2020](https://www.gophercon.com/).
-Mark your calendars!
-
-- “Typing [Generic] Go”,
-  a talk by Robert Griesemer,\
-  [Nov 11, 10:00 AM (US Eastern)](https://www.gophercon.com/agenda/session/233094);
-  [Q&A at 10:30 AM](https://www.gophercon.com/agenda/session/417935).
-- “What to Expect When You’re NOT Expecting”,
-  a live taping of the Go time podcast with a panel of expert debuggers,
-  including Hana Kim,\
-  [Nov 11 12:00 PM](https://www.gophercon.com/agenda/session/2334490).
-- “Evolving the Go Memory Manager's RAM and CPU Efficiency”,
-  a talk by Michael Knyszek,\
-  [Nov 11 1:00 PM](https://www.gophercon.com/agenda/session/233086);
-  [Q&A at 1:50 PM](https://www.gophercon.com/agenda/session/417940).
-- “Implementing Faster Defers”,
-  a talk by Dan Scales,\
-  [Nov 11 5:10 PM](https://www.gophercon.com/agenda/session/233397);
-  [Q&A at 5:40 PM](https://www.gophercon.com/agenda/session/417941).
- - “Go Team - Ask Me Anything”,
-  a live Q&A with Julie Qiu, Rebecca Stambler, Russ Cox, Sameer Ajmani, and Van Riper,\
-  [Nov 12 3:00 PM](https://www.gophercon.com/agenda/session/420539).
-- “Pardon the Interruption: Loop Preemption in Go 1.14”,
-  a talk by Austin Clements,\
-  [Nov 12 4:45 PM](https://www.gophercon.com/agenda/session/233441);
-  [Q&A at 5:15 PM](https://www.gophercon.com/agenda/session/417943).
-- “Working with Errors”,
-  a talk by Jonathan Amsterdam,\
-  [Nov 13 1:00 PM](https://www.gophercon.com/agenda/session/233432);
-  [Q&A at 1:50 PM](https://www.gophercon.com/agenda/session/417945).
-- “Crossing the Chasm for Go: Two Million Users and Growing”,
-  a talk by Carmen Andoh,\
-  [Nov 13 5:55 PM](https://www.gophercon.com/agenda/session/233426).
-
-## Go Releases
-
-In February, the Go 1.16 release will include the new
-[file system interfaces](https://tip.golang.org/pkg/io/fs/)
-and
-[build-time file embedding](https://tip.golang.org/pkg/embed/).
-It will complete the linker rewrite, bringing additional performance improvements.
-And it will include support for the new Apple Silicon (`GOARCH=arm64`) Macs.
-
-In August, the Go 1.17 release will no doubt bring more features and improvements,
-although it’s far enough out that the exact details remain up in the air.
-It will include a new register-based calling convention for x86-64
-(without breaking existing assembly!),
-which will make programs faster across the board.
-(Other architectures will follow in later releases.)
-One nice feature that will definitely be included is the
-[new `//go:build` lines](https://golang.org/design/draft-gobuild),
-which are far less error-prone than the
-[current `//` `+build` lines](https://golang.org/cmd/go/#hdr-Build_constraints).
-Another highly anticipated feature we hope will be ready for beta testing next year
-is
-[support for fuzzing in the `go test` command](https://golang.org/design/draft-fuzzing).
-
-## Go Modules
-
-Over the next year, we will continue to work on developing support for Go modules
-and integrating them well into the entire Go ecosystem.
-Go 1.16 will include our smoothest Go modules experience yet.
-One preliminary result from our recent survey is that 96% of users
-have now adopted Go modules (up from 90% a year ago).
-
-We will also finally wind down support for GOPATH-based development:
-any programs using dependencies other than the standard library will need a `go.mod`.
-(If you haven’t switched to modules yet, see the
-[GOPATH wiki page](https://golang.org/wiki/GOPATH)
-for details about this final step in the journey from GOPATH to modules.)
-
-From the start, the [goal for Go modules](https://research.swtch.com/vgo-intro)
-has been “to add the concept of package versions to the working vocabulary
-of both Go developers and our tools,”
-to enable deep support for modules and versions throughout the Go ecosystem.
-The [Go module mirror, checksum database, and index](https://blog.golang.org/modules2019)
-were made possible by this ecosystem-wide understanding of what a package version is.
-Over the next year, we will see rich module support added to more tools and systems.
-For example, we plan to investigate new tooling to help module authors publish new versions
-(`go release`)
-as well as to help module consumers update their code to migrate away from
-deprecated APIs (a new `go fix`).
-
-As a larger example,
-[we created gopls](https://github.com/golang/tools/blob/master/gopls/README.md)
-to reduce many tools used by editors for Go support,
-none of which supported modules, down to a single one that did.
-Over the next year,
-we’ll be ready to make the VSCode Go extension use `gopls` by default,
-for an excellent module experience out of the box,
-and we’ll release gopls 1.0.
-Of course, one of the best things about gopls is that it is editor-neutral:
-any editor that understands the
-[language server protocol](https://langserver.org/)
-can use it.
-
-Another important use of version information is tracking whether
-any package in a build has a known vulnerability.
-Over the next year, we plan to develop a database of known vulnerabilities
-as well as tools to check your programs against that database.
-
-The Go package discovery site
-[pkg.go.dev](https://pkg.go.dev/)
-is another example of a version-aware system enabled by Go modules.
-We’ve been focused on getting the core functionality and user experience right,
-including a
-[redesign launching today](https://blog.golang.org/pkgsite-redesign).
-Over the next year,
-we will be unifying godoc.org into pkg.go.dev.
-We will also be expanding the version timeline for each package,
-showing important changes in each version,
-known vulnerabilities, and more,
-following the overall goal of surfacing what you need to make
-[informed decisions about adding dependencies](https://research.swtch.com/deps).
-
-We’re excited to see this journey from GOPATH to Go modules
-nearing completion and all the excellent dependency-aware tools
-that Go modules are enabling.
-
-## Generics
-
-The next feature on everyone’s minds is of course generics.
-As we mentioned above, we published the
-[latest design draft for generics](https://blog.golang.org/generics-next-step)
-back in June.
-Since then, we’ve continued to refine rough edges and have turned our
-attention to the details of implementing a production-ready version.
-We will be working on that throughout 2021, with a goal of having
-something for people to try out by the end of the year,
-perhaps a part of the Go 1.18 betas.
-
-## Thank You!
-
-Go is far more than just us on the Go team at Google.
-We are indebted to the contributors who work with us with the Go releases and tools.
-Beyond that, Go only succeeds because of all of you who work in
-and contribute to Go’s thriving ecosystem.
-It has been a difficult year in the world outside Go.
-More than ever, we appreciate you taking the time
-to join us and help make Go such a success.
-Thank you.
-We hope you are all staying safe and wish you all the best.
-
diff --git a/_content/11years/gophermask.jpg b/_content/11years/gophermask.jpg
deleted file mode 100644
index d6fc456..0000000
--- a/_content/11years/gophermask.jpg
+++ /dev/null
Binary files differ
diff --git a/_content/1year.article b/_content/1year.article
deleted file mode 100644
index cad82c6..0000000
--- a/_content/1year.article
+++ /dev/null
@@ -1,148 +0,0 @@
-# Go: one year ago today
-10 Nov 2010
-Tags: birthday
-Summary: Happy 1st birthday, Go!
-OldURL: /go-one-year-ago-today
-
-Andrew Gerrand
-
-##
-
-On the 10th of November 2009 we launched the Go project:
-an open-source programming language with a focus on simplicity and efficiency.
-The intervening year has seen a great many developments both in the Go project
-itself and in its community.
-
-We set out to build a language for systems programming - the kinds of programs
-one might typically write in C or C++ - and we were surprised by Go’s
-utility as a general purpose language.
-We had anticipated interest from C, C++, and Java programmers,
-but the flurry of interest from users of dynamically-typed languages like
-Python and JavaScript was unexpected.
-Go’s combination of native compilation,
-static typing, memory management, and lightweight syntax seemed to strike
-a chord with a broad cross-section of the programming community.
-
-That cross-section grew to become a dedicated community of enthusiastic Go coders.
-Our [mailing list](http://groups.google.com/group/golang-nuts) has over 3,800 members,
-with around 1,500 posts each month.
-The project has over 130 [contributors](https://golang.org/CONTRIBUTORS)
-(people who have submitted code or documentation),
-and of the 2,800 commits since launch almost one third were contributed
-by programmers outside the core team.
-To get all that code into shape, nearly 14,000 emails were exchanged on
-our [development mailing list](http://groups.google.com/group/golang-dev).
-
-Those numbers reflect a labor whose fruits are evident in the project’s code base.
-The compilers have improved substantially,
-with faster and more efficient code generation,
-more than one hundred reported bugs fixed,
-and support for a widening range of operating systems and architectures.
-The Windows port is approaching completion thanks to a dedicated group of
-contributors (one of whom became our first non-Google committer to the project).
-The ARM port has also made great progress,
-recently reaching the milestone of passing all tests.
-
-The Go tool set has been expanded and improved.
-The Go documentation tool, [godoc](https://golang.org/cmd/godoc/),
-now supports the documentation of other source trees (you can browse and
-search your own code) and provides a ["code walk"](https://golang.org/doc/codewalk/)
-interface for presenting tutorial materials (among many more improvements).
-[Goinstall](https://golang.org/cmd/goinstall/) ,
-a new package management tool, allows users to install and update external
-packages with a single command.
-[Gofmt](https://golang.org/cmd/gofmt/),
-the Go pretty-printer, now makes syntactic simplifications where possible.
-[Goplay](https://golang.org/misc/goplay/),
-a web-based “compile-as-you-type” tool,
-is a convenient way to experiment with Go for those times when you don’t
-have access to the [Go Playground](https://golang.org/doc/play/).
-
-The standard library has grown by over 42,000 lines of code and includes
-20 new [packages](https://golang.org/pkg/).
-Among the additions are the [jpeg](https://golang.org/pkg/image/jpeg/),
-[jsonrpc](https://golang.org/pkg/rpc/jsonrpc/),
-[mime](https://golang.org/pkg/mime/), [netchan](https://golang.org/pkg/netchan/),
-and [smtp](https://golang.org/pkg/smtp/) packages,
-as well as a slew of new [cryptography](https://golang.org/pkg/crypto/) packages.
-More generally, the standard library has been continuously refined and revised
-as our understanding of Go’s idioms deepens.
-
-The debugging story has gotten better, too.
-Recent improvements to the DWARF output of the gc compilers make the GNU debugger,
-GDB, useful for Go binaries, and we’re actively working on making that
-debugging information more complete.
-(See the [ recent blog post](https://blog.golang.org/2010/11/debugging-go-code-status-report.html) for details.)
-
-It’s now easier than ever to link against existing libraries written in
-languages other than Go.
-Go support is in the most recent [SWIG](http://www.swig.org/) release,
-version 2.0.1, making it easier to link against C and C++ code,
-and our [cgo](https://golang.org/cmd/cgo/) tool has seen many fixes and improvements.
-
-[Gccgo](https://golang.org/doc/gccgo_install.html),
-the Go front end for the GNU C Compiler, has kept pace with the gc compiler
-as a parallel Go implementation.
-It now has a working garbage collector, and has been accepted into the GCC core.
-We’re now working toward making [gofrontend](http://code.google.com/p/gofrontend/)
-available as a BSD-licensed Go compiler front end,
-fully decoupled from GCC.
-
-Outside the Go project itself Go is starting to be used to build real software.
-There are more than 200 Go programs and libraries listed on our [Project dashboard](http://godashboard.appspot.com/project),
-and hundreds more on [Google Code](http://code.google.com/hosting/search?q=label:Go)
-and [Github](https://github.com/search?q=language:Go).
-On our mailing list and IRC channel you can find coders from around the
-world who use Go for their programming projects.
-(See our [guest blog post](https://blog.golang.org/2010/10/real-go-projects-smarttwitter-and-webgo.html)
-from last month for a real-world example.) Internally at Google there are
-several teams that choose Go for building production software,
-and we have received reports from other companies that are developing sizable systems in Go.
-We have also been in touch with several educators who are using Go as a teaching language.
-
-The language itself has grown and matured, too.
-In the past year we have received many feature requests.
-But Go is a small language, and we’ve worked hard to ensure that any new
-feature strikes the right compromise between simplicity and utility.
-Since the launch we have made a number of language changes,
-many of which were driven by feedback from the community.
-
-  - Semicolons are now optional in almost all instances. [spec](https://golang.org/doc/go_spec.html#Semicolons)
-  - The new built-in functions `copy` and `append` make management of slices
-    more efficient and straightforward.
-    [spec](https://golang.org/doc/go_spec.html#Appending_and_copying_slices)
-  - The upper and lower bounds may be omitted when making a sub-slice.
-    This means that `s[:]` is shorthand for `s[0:len(s)]`.
-    [spec](https://golang.org/doc/go_spec.html#Slices)
-  - The new built-in function `recover` complements `panic` and `defer` as
-    an error handling mechanism.
-    [blog](https://blog.golang.org/2010/08/defer-panic-and-recover.html),
-    [spec](https://golang.org/doc/go_spec.html#Handling_panics)
-  - The new complex number types (`complex`,
-    `complex64`, and `complex128`) simplify certain mathematical operations.
-    [spec](https://golang.org/doc/go_spec.html#Complex_numbers),
-    [spec](https://golang.org/doc/go_spec.html#Imaginary_literals)
-  - The composite literal syntax permits the omission of redundant type information
-    (when specifying two-dimensional arrays, for example).
-    [release.2010-10-27](https://golang.org/doc/devel/release.html#2010-10-27),
-    [spec](https://golang.org/doc/go_spec.html#Composite_literals)
-  - A general syntax for variable function arguments (`...T`) and their propagation
-    (`v...`) is now specified.
-    [spec](https://golang.org/doc/go_spec.html#Function_Types),
-    [ spec](https://golang.org/doc/go_spec.html#Passing_arguments_to_..._parameters),
-    [release.2010-09-29](https://golang.org/doc/devel/release.html#2010-09-29)
-
-Go is certainly ready for production use,
-but there is still room for improvement.
-Our focus for the immediate future is making Go programs faster and more
-efficient in the context of high performance systems.
-This means improving the garbage collector,
-optimizing generated code, and improving the core libraries.
-We’re also exploring some further additions to the type system to make
-generic programming easier.
-A lot has happened in a year; it’s been both thrilling and satisfying.
-We hope that this coming year will be even more fruitful than the last.
-
-_If you’ve been meaning to get [back] into Go, now is a great time to do so! Check out the_
-[_Documentation_](https://golang.org/doc/docs.html) _and_ [_Getting Started_](https://golang.org/doc/install.html)
-_pages for more information, or just go nuts in the_ [_Go Playground_](https://golang.org/doc/play/).
diff --git a/_content/2years.article b/_content/2years.article
deleted file mode 100644
index 6dd1852..0000000
--- a/_content/2years.article
+++ /dev/null
@@ -1,76 +0,0 @@
-# The Go Programming Language turns two
-10 Nov 2011
-Tags: appengine, community, gopher
-Summary: Happy 2nd birthday, Go!
-OldURL: /go-programming-language-turns-two
-
-Andrew Gerrand
-
-##
-
-Two years ago a small team at Google went public with their fledgling project -
-the Go Programming Language.
-They presented a language spec, two compilers,
-a modest standard library, some novel tools,
-and plenty of accurate (albeit succinct) documentation.
-They watched with excitement as programmers around the world began to play with Go.
-The team continued to iterate and improve on what they had built,
-and were gradually joined by dozens - and then hundreds - of programmers
-from the open source community.
-The Go Authors went on to produce lots of libraries,
-new tools, and reams of [documentation](https://golang.org/doc/docs.html).
-They celebrated a successful year in the public eye with a [blog post](https://blog.golang.org/2010/11/go-one-year-ago-today.html)
-last November that concluded "Go is certainly ready for production use,
-but there is still room for improvement.
-Our focus for the immediate future is making Go programs faster and more
-efficient in the context of high performance systems."
-
-Today is the second anniversary of Go's release,
-and Go is faster and more stable than ever.
-Careful tuning of Go's code generators, concurrency primitives,
-garbage collector, and core libraries have increased the performance of Go programs,
-and native support for [profiling](https://blog.golang.org/2011/06/profiling-go-programs.html)
-and [debugging](http://blog.golang.org/2011/10/debugging-go-programs-with-gnu-debugger.html)
-makes it easier to detect and remove performance issues in user code.
-Go is also now easier to learn with [A Tour of Go](http://tour.golang.org/),
-an interactive tutorial you can take from the comfort of your web browser.
-
-This year we introduced the experimental [Go runtime](http://code.google.com/appengine/docs/go/)
-for Google's App Engine platform,
-and we have been steadily increasing the Go runtime's support for App Engine's APIs.
-Just this week we released [version 1.6.0](http://code.google.com/appengine/downloads.html)
-of the Go App Engine SDK,
-which includes support for [backends](http://code.google.com/appengine/docs/go/backends/overview.html)
-(long-running processes),
-finer control over datastore indexes, and various other improvements.
-Today, the Go runtime is near feature parity with - and is a viable alternative
-to - the Python and Java runtimes.
-In fact, we now serve [golang.org](https://golang.org/) by running a version
-of [godoc](https://golang.org/cmd/godoc/) on the App Engine service.
-
-While 2010 was a year of discovery and experimentation,
-2011 was a year of fine tuning and planning for the future.
-This year we issued several "[release](https://golang.org/doc/devel/release.html)"
-versions of Go that were more reliable and better supported than weekly snapshots.
-We also introduced [gofix](https://golang.org/cmd/gofix/) to take the
-pain out of migrating to newer releases.
-Furthermore, last month we announced a [plan for Go version 1](https://blog.golang.org/2011/10/preview-of-go-version-1.html) -
-a release that will be supported for years to come.
-Work toward Go 1 is already underway and you can observe our progress by
-the latest weekly snapshot at [weekly.golang.org](http://weekly.golang.org/pkg/).
-
-The plan is to launch Go 1 in early 2012.
-We hope to bring the Go App Engine runtime out of "experimental" status at the same time.
-
-But that's not all. 2011 was an exciting year for the gopher, too.
-He has manifested himself as a plush toy (a highly prized gift at Google
-I/O and other Go talks) and in vinyl form (received by every attendee at
-OSCON and now available at the [Google Store](http://www.googlestore.com/Fun/Go+Gopher+Figurine.axd)).
-
-.image 2years/2years-gophers.jpg
-
-And, most surprisingly, at Halloween he made an appearance with his gopher girlfriend!
-
-.image 2years/2years-costume.jpg
-
-Photograph by [Chris Nokleberg](https://plus.google.com/106640494112897458359/posts).
diff --git a/_content/2years/2years-costume.jpg b/_content/2years/2years-costume.jpg
deleted file mode 100644
index aa86a6c..0000000
--- a/_content/2years/2years-costume.jpg
+++ /dev/null
Binary files differ
diff --git a/_content/2years/2years-gophers.jpg b/_content/2years/2years-gophers.jpg
deleted file mode 100644
index 72075da..0000000
--- a/_content/2years/2years-gophers.jpg
+++ /dev/null
Binary files differ
diff --git a/_content/3years.article b/_content/3years.article
deleted file mode 100644
index 7ac1c78..0000000
--- a/_content/3years.article
+++ /dev/null
@@ -1,78 +0,0 @@
-# Go turns three
-10 Nov 2012
-Tags: community, birthday
-Summary: Happy 3rd birthday, Go!
-OldURL: /go-turns-three
-
-Russ Cox
-
-##
-
-The Go open source project is
-[three years old today](http://google-opensource.blogspot.com/2009/11/hey-ho-lets-go.html).
-
-It's great to look at how far Go has come in those three years.
-When we launched, Go was an idea backed by two implementations that worked on Linux and OS X.
-The syntax, semantics, and libraries changed regularly as we reacted to feedback from users
-and experience with the language.
-
-Since the open source launch,
-we've been joined by
-[hundreds of external contributors](https://golang.org/CONTRIBUTORS),
-who have extended and improved Go in myriad ways,
-including writing a Windows port from scratch.
-We added a package management system
-[goinstall](https://groups.google.com/d/msg/golang-nuts/8JFwR3ESjjI/cy7qZzN7Lw4J),
-which eventually became the
-[go command](https://golang.org/cmd/go/).
-We also added
-[support for Go on App Engine](https://blog.golang.org/2011/07/go-for-app-engine-is-now-generally.html).
-Over the past year we've also given [many talks](https://golang.org/doc/#talks), created an [interactive introductory tour](http://tour.golang.org/)
-and recently we added support for [executable examples in package documentation](https://golang.org/pkg/strings/#pkg-examples).
-
-Perhaps the most important development in the past year
-was the launch of the first stable version,
-[Go 1](https://blog.golang.org/2012/03/go-version-1-is-released.html).
-People who write Go 1 programs can now be confident that their programs will
-continue to compile and run without change, in many environments,
-on a time scale of years.
-As part of the Go 1 launch we spent months cleaning up the
-[language and libraries](https://golang.org/doc/go1.html)
-to make it something that will age well.
-
-We're working now toward the release of Go 1.1 in 2013. There will be some
-new functionality, but that release will focus primarily on making Go perform
-even better than it does today.
-
-We're especially happy about the community that has grown around Go:
-the mailing list and IRC channels seem like they are overflowing with discussion,
-and a handful of Go books were published this year. The community is thriving.
-Use of Go in production environments has also taken off, especially since Go 1.
-
-We use Go at Google in a variety of ways, many of them invisible to the outside world.
-A few visible ones include
-[serving Chrome and other downloads](https://groups.google.com/d/msg/golang-nuts/BNUNbKSypE0/E4qSfpx9qI8J),
-[scaling MySQL database at YouTube](http://code.google.com/p/vitess/),
-and of course running the
-[Go home page](https://golang.org/)
-on [App Engine](https://developers.google.com/appengine/docs/go/overview).
-Last year's
-[Thanksgiving Doodle](https://blog.golang.org/2011/12/from-zero-to-go-launching-on-google.html)
-and the recent
-[Jam with Chrome](http://www.jamwithchrome.com/technology)
-site are also served by Go programs.
-
-Other companies and projects are using Go too, including
-[BBC Worldwide](http://www.quora.com/Go-programming-language/Is-Google-Go-ready-for-production-use/answer/Kunal-Anand),
-[Canonical](http://dave.cheney.net/wp-content/uploads/2012/08/august-go-meetup.pdf),
-[CloudFlare](http://blog.cloudflare.com/go-at-cloudflare),
-[Heroku](https://blog.golang.org/2011/04/go-at-heroku.html),
-[Novartis](https://plus.google.com/114945221884326152379/posts/d1SVaqkRyTL),
-[SoundCloud](http://backstage.soundcloud.com/2012/07/go-at-soundcloud/),
-[SmugMug](http://sorcery.smugmug.com/2012/04/06/deriving-json-types-in-go/),
-[StatHat](https://blog.golang.org/2011/12/building-stathat-with-go.html),
-[Tinkercad](https://tinkercad.com/about/jobs),
-and
-[many others](https://golang.org/wiki/GoUsers).
-
-Here's to many more years of productive programming in Go.
diff --git a/_content/4years.article b/_content/4years.article
deleted file mode 100644
index 711714d..0000000
--- a/_content/4years.article
+++ /dev/null
@@ -1,163 +0,0 @@
-# Four years of Go
-10 Nov 2013
-Tags: community, birthday
-Summary: Happy 4th birthday, Go!
-
-Andrew Gerrand
-
-##
-
-Today marks the fourth anniversary of Go as an open source project.
-
-.image 4years/4years-gopher.png
-
-Rather than talk about our technical progress (there'll be much to talk about
-when we release Go 1.2 in a couple of weeks) we thought we would instead take
-this occasion to look at how the Go community has grown.
-
-Let's start with a chart:
-
-.image 4years/4years-graph.png
-
-This chart shows the growth of Google searches for the term
-"[golang](http://www.google.com/trends/explore?hl=en-US#q=golang&date=10/2009+50m&cmpt=q)"
-over the past four years.
-Notice the knee in the curve around March 2012, when Go 1.0 was released.
-If these searches are a decent proxy for interest, then it's clear that
-interest in Go has grown remarkably since launch, and particularly so in the
-last 2 years.
-
-But where is the interest coming from?
-
-The open source community has embraced Go,
-with our community wiki listing [hundreds of Go projects](https://golang.org/wiki/Projects). Some popular ones:
-
-  - [Docker](http://docker.io) is a tool for packaging and running applications
-    in lightweight containers.
-    Docker makes it easy to isolate, package,
-    and deploy applications, and is beloved by system administrators.
-    Its creator Solomon Hykes cited Go's standard library,
-    concurrency primitives, and ease of deployment as key factors,
-    and said "To put it simply, if Docker had not been written in Go,
-    it would not have been as successful."
-
-  - [Packer](http://packer.io) is a tool for automating the creation of
-    machine images for deployment to virtual machines or cloud services.
-    Its author, Mitchell Hashimoto, is now working on another Go project,
-    [serf](http://www.serfdom.io/), a decentralized discovery service.
-    Like Docker, these projects help with management of large-scale,
-    cluster-based services.
-
-  - [Bitly](http://bit.ly)'s [NSQ](http://bitly.github.io/nsq/) is a realtime
-    distributed messaging platform designed for fault-tolerance and high-availability,
-    and is used in production at bitly and a bunch of other companies.
-
-  - [Canonical](http://canonical.com/)'s [JuJu](https://juju.ubuntu.com/)
-    infrastructure automation system was rewritten in Go.
-    Project lead Gustavo Niemeyer said "It's not a single aspect of Go that
-    makes it a compelling choice,
-    but rather the careful organization of well-crafted small pieces."
-
-  - The [raft](https://github.com/goraft/raft) package provides an implementation
-    of the [Raft](https://ramcloud.stanford.edu/wiki/download/attachments/11370504/raft.pdf)
-    distributed consensus protocol.
-    It is the basis of Go projects like [etcd](https://github.com/coreos/etcd)
-    and [SkyDNS](https://github.com/skynetservices/skydns).
-
-  - Other popular projects include [biogo](https://github.com/biogo/biogo),
-    the [Gorilla Web Toolkit](http://www.gorillatoolkit.org/),
-    [groupcache](https://github.com/golang/groupcache),
-    Mozilla's [heka](https://github.com/mozilla-services/heka),
-    the [kv](https://github.com/cznic/kv) and [ql](https://github.com/cznic/ql)
-    lightweight storage systems,
-    and the [Sky](http://skydb.io/) behavioral database.
-
-But this is just the tip of the iceberg. The number of high-quality open
-source Go projects is phenomenal.
-Prolific Go hacker [Keith Rarick](http://xph.us/software/) put it well:
-"The state of the Go ecosystem after only four years is astounding.
-Compare Go in 2013 to Python in 1995 or Java in 1999. Or C++ in 1987!"
-
-Businesses are enjoying Go, too. The [Go Users wiki page](https://golang.org/wiki/GoUsers)
-lists dozens of success stories (and if you use Go,
-please add yourself to it). Some examples:
-
-  - [CloudFlare](https://blog.cloudflare.com/go-at-cloudflare) built their
-    distributed DNS service entirely with Go,
-    and are in the process of migrating their gigabytes-per-minute logging infrastructure to the language.
-    Programmer John Graham-Cumming said "We've found Go to be the perfect match for our needs:
-    the combination of familiar syntax, a powerful type system,
-    a strong network library and built-in concurrency means that more and more
-    projects are being built here in Go."
-
-  - [SoundCloud](http://soundcloud.com) is an audio distribution service
-    that has "dozens of [systems in Go](http://backstage.soundcloud.com/2012/07/go-at-soundcloud/),
-    touching almost every part of the site, and in many cases powering features
-    from top to bottom." Engineer Peter Bourgon said "Go demonstrates that the
-    cruft that burdens other languages and ecosystems—stuff that developers
-    have learned to deal with,
-    often in anger—is simply not a necessary part of modern programming.
-    With Go, I have a straightforward and non-adversarial relationship with my tools,
-    from development to production."
-
-  - The [ngrok](https://ngrok.com/) service allows web developers to provide
-    remote access to their development environments.
-    Its author Alan Shreve said that "ngrok's success as a project is due in
-    no small part to choosing Go as the implementation language," citing Go's HTTP libraries,
-    efficiency, cross-platform compatibility,
-    and ease of deployment as the major benefits.
-
-  - [Poptip](http://poptip.com) provides social analytics services,
-    and product engineer Andy Bonventre said "What started as an experiment
-    in writing a single service in Go turned into moving almost our entire infrastructure over to it.
-    What I love about Go the most is not necessarily the features of the language,
-    but the focus on tooling, testing, and other elements that make writing
-    large applications much more manageable."
-
-  - Music collaboration startup [Splice](http://splice.com) chose to build
-    their service with Go.
-    Co-founder Matt Aimonetti said "We seriously studied and considered many
-    programming languages,
-    but Go's simplicity, efficiency, philosophy and community won us over."
-
-  - And, of course, engineering teams across Google are moving to Go.
-    Engineer Matt Welsh recently [shared his experience](http://matt-welsh.blogspot.com.au/2013/08/rewriting-large-production-system-in-go.html)
-    rewriting a large production service in Go.
-    Other notable public examples include YouTube's [vitess project](https://github.com/youtube/vitess)
-    and [dl.google.com](https://talks.golang.org/2013/oscon-dl.slide).
-    We hope to share more stories like these soon.
-
-In September 2012, [Apcera](http://apcera.com/) CEO Derek Collison [predicted](https://twitter.com/derekcollison/status/245522124666716160)
-that "Go will become the dominant language for systems work in [Infastructure-as-a-Service],
-Orchestration, and [Platform-as-a-Service] in 24 months." Looking at the list above,
-it's easy to believe that prediction.
-
-So how can you get involved? Whether you're a seasoned Go programmer or just Go-curious,
-there are many ways to get started in the Go community:
-
-  - [Join your nearest Go User Group](https://blog.golang.org/getthee-to-go-meetup),
-    where your local gophers meet to share their knowledge and experience.
-    These groups are popping up all over the world.
-    I have personally spoken at Go groups in Amsterdam,
-    Berlin, Gothenburg, London, Moscow, Munich,
-    New York City, Paris, San Francisco, Seoul,
-    Stockholm, Sydney, Tokyo, and Warsaw;
-    but there are [many more](https://golang.org/wiki/GoUserGroups)!
-
-  - Create or contribute to an open source Go project (or [to Go itself](https://golang.org/doc/contribute.html)).
-    (And if you're building something, we'd love to hear from you on the [Go mailing list](http://groups.google.com/group/golang-nuts).)
-
-  - If you're in Europe in February 2014, come along to the [Go Devroom](https://code.google.com/p/go-wiki/wiki/Fosdem2014)
-    at [FOSDEM 2014](https://fosdem.org/2014/).
-
-  - Attend [GopherCon](http://gophercon.com),
-    the first major Go conference, in Denver in April 2014.
-    The event is organized by the [Gopher Academy](http://www.gopheracademy.com),
-    who also run a [Go job board](http://www.gopheracademy.com/jobs).
-
-The Go team has been amazed by the growth of the Go community over the past
-four years. We are thrilled to see so many great things being built with Go,
-and deeply grateful to work with our wonderful and dedicated contributors.
-Thank you, everyone.
-
-Here's to four more years!
diff --git a/_content/4years/4years-gopher.png b/_content/4years/4years-gopher.png
deleted file mode 100644
index a811015..0000000
--- a/_content/4years/4years-gopher.png
+++ /dev/null
Binary files differ
diff --git a/_content/4years/4years-graph.png b/_content/4years/4years-graph.png
deleted file mode 100644
index a5a26a1..0000000
--- a/_content/4years/4years-graph.png
+++ /dev/null
Binary files differ
diff --git a/_content/5years.article b/_content/5years.article
deleted file mode 100644
index 0d513d3..0000000
--- a/_content/5years.article
+++ /dev/null
@@ -1,104 +0,0 @@
-# Half a decade with Go
-10 Nov 2014
-Summary: Happy 5th birthday, Go!
-
-Andrew Gerrand
-adg@golang.org
-
-##
-
-Five years ago we launched the Go project. It seems like only yesterday that we
-were preparing the initial public release: our
-[website](https://web.archive.org/web/20091112094121/http://golang.org/) was
-a lovely shade of yellow, we were calling Go a "systems language", and you had
-to terminate statements with a semicolon and write Makefiles to build your
-code. We had no idea how Go would be received. Would people share our vision
-and goals? Would people find Go useful?
-
-At launch, there was a flurry of attention. Google had produced a new
-programming language, and everyone was eager to check it out. Some programmers
-were turned off by Go's conservative feature set—at first glance they saw
-"nothing to see here"—but a smaller group saw the beginnings of an ecosystem
-tailored to their needs as working software engineers. These few would form the
-kernel of the Go community.
-
-.image 5years/gophers5th.jpg _ 850
-
-[_Gopher_](/gopher) _illustration by_ [_Renee French_](http://reneefrench.blogspot.com.au/)
-
-After the initial release, it took us a while to properly communicate the
-goals and design ethos behind Go. Rob Pike did so eloquently in his 2012 essay
-[_Go at Google: Language Design in the Service of Software Engineering_](https://talks.golang.org/2012/splash.article) and
-more personally in his blog post
-[_Less is exponentially more_](https://commandcenter.blogspot.com.au/2012/06/less-is-exponentially-more.html).
-Andrew Gerrand's
-[_Code that grows with grace_](http://vimeo.com/53221560)
-([slides](https://talks.golang.org/2012/chat.slide)) and
-[_Go for Gophers_](https://www.youtube.com/watch?v=dKGmK_Z1Zl0)
-([slides](https://talks.golang.org/2014/go4gophers.slide)) give a
-more in-depth, technical take on Go's design philosophy.
-
-Over time, the few became many. The turning point for the project was the
-release of Go 1 in March 2012, which provided a stable language and standard
-library that developers could trust. By 2014, the project had hundreds of core
-contributors, the ecosystem had countless [libraries and tools](https://godoc.org/)
-maintained by thousands of developers, and the greater community had
-many passionate members (or, as we call them, "gophers"). Today, by our current
-metrics, the Go community is growing faster than we believed possible.
-
-Where can those gophers be found? They are at the many Go events that are
-popping up around the world. This year we saw several dedicated Go conferences:
-the inaugural [GopherCon](https://blog.golang.org/gophercon) and
-[dotGo](http://www.dotgo.eu/) conferences in Denver and Paris, the
-[Go DevRoom at FOSDEM](https://blog.golang.org/fosdem14) and two more
-instances of the biannual [GoCon](https://github.com/GoCon/GoCon) conference
-in Tokyo. At each event, gophers from around the globe eagerly presented their
-Go projects. For the Go team, it is very satisfying to meet so many programmers
-that share our vision and excitement.
-
-.image 5years/conferences.jpg
-
-_More than 1,200 gophers attended GopherCon in Denver and dotGo in Paris._
-
-There are also dozens of community-run
-[Go User Groups](https://golang.org/wiki/GoUserGroups) spread across cities
-worldwide. If you haven't visited your local group, consider going along. And
-if there isn't a group in your area, maybe you should
-[start one](https://blog.golang.org/getthee-to-go-meetup)?
-
-Today, Go has found a home in the cloud. Go arrived as the industry underwent a
-tectonic shift toward cloud computing, and we were thrilled to see it quickly
-become an important part of that movement. Its simplicity, efficiency, built-in
-concurrency primitives, and modern standard library make it a great fit for
-cloud software development (after all, that's what it was designed for).
-Significant open source cloud projects like
-[Docker](https://www.docker.com/) and
-[Kubernetes](https://github.com/GoogleCloudPlatform/kubernetes) have been
-written in Go, and infrastructure companies like Google, CloudFlare, Canonical,
-Digital Ocean, GitHub, Heroku, and Microsoft are now using Go to do some heavy
-lifting.
-
-So, what does the future hold? We think that 2015 will be Go's biggest year yet.
-
-Go 1.4—in addition to its [new features and fixes](https://golang.org/doc/go1.4)—lays
-the groundwork for a new low-latency garbage collector and support for running
-Go on mobile devices. It is due to be released on December 1st 2014.
-We expect the new GC to be available in Go 1.5, due June 1st 2015, which will
-make Go appealing for a broader range of applications.
-We can't wait to see where people take it.
-
-And there will be more great events, with [GothamGo](http://gothamgo.com/) in
-New York (15 Nov), another Go DevRoom at FOSDEM in Brussels (Jan 31 and Feb 1;
-[get involved!](https://groups.google.com/d/msg/golang-nuts/1xgBazQzs1I/hwrZ5ni8cTEJ)),
-[GopherCon India](http://www.gophercon.in/) in Bengaluru (19-21 Feb),
-the original [GopherCon](http://gophercon.com/) back at Denver in July, and
-[dotGo](http://www.dotgo.eu/) on again at Paris in November.
-
-The Go team would like to extend its thanks to all the gophers out there.
-Here's to the next five years.
-
-_To celebrate 5 years of Go, over the coming month the_
-[_Gopher Academy_](http://blog.gopheracademy.com/)
-_will publish a series of articles by prominent Go users. Be sure to check out_
-[_their blog_](http://blog.gopheracademy.com/)
-_for more Go action._
diff --git a/_content/5years/conferences.jpg b/_content/5years/conferences.jpg
deleted file mode 100644
index 55962bc..0000000
--- a/_content/5years/conferences.jpg
+++ /dev/null
Binary files differ
diff --git a/_content/5years/gophers5th.jpg b/_content/5years/gophers5th.jpg
deleted file mode 100644
index df10648..0000000
--- a/_content/5years/gophers5th.jpg
+++ /dev/null
Binary files differ
diff --git a/_content/6years.article b/_content/6years.article
deleted file mode 100644
index fa70b8e..0000000
--- a/_content/6years.article
+++ /dev/null
@@ -1,51 +0,0 @@
-# Six years of Go
-10 Nov 2015
-Summary: Happy 6th birthday, Go!
-
-Andrew Gerrand
-adg@golang.org
-
-##
-
-Six years ago today the Go language was released as an open source project.
-Since then, more than 780 contributors have made over 30,000 commits to the
-project's 22 repositories. The ecosystem continues to grow, with GitHub
-reporting more than 90,000 Go repositories. And, offline, we see new Go events
-and user groups pop up [around](https://blog.golang.org/gophercon2015)
-[the](https://blog.golang.org/gouk15)
-[world](https://blog.golang.org/gopherchina) with regularity.
-
-.image 6years/6years-gopher.png
-
-In August we [released Go 1.5](https://blog.golang.org/go1.5), the most
-significant release since Go 1. It features a completely
-[redesigned garbage collector](https://golang.org/doc/go1.5#gc) that makes
-the language more suitable for latency-sensitive applications; it marks the
-transition from a C-based compiler tool chain to one
-[written entirely in Go](https://golang.org/doc/go1.5#c); and it includes
-ports to [new architectures](https://golang.org/doc/go1.5#ports), with better
-support for ARM processors (the chips that power most smartphones).
-These improvements make Go better suited to a broader range of tasks, a trend
-that we hope will continue over the coming years.
-
-Improvements to tools continue to boost developer productivity.
-We introduced the [execution tracer](https://golang.org/cmd/trace/) and the
-"[go doc](https://golang.org/cmd/go/#hdr-Show_documentation_for_package_or_symbol)"
-command, as well as more enhancements to our various
-[static analysis tools](https://talks.golang.org/2014/static-analysis.slide).
-We are also working on an
-[official Go plugin for Sublime Text](https://groups.google.com/forum/#!topic/Golang-nuts/8oCSjAiKXUQ),
-with better support for other editors in the pipeline.
-
-Early next year we will release more improvements in Go 1.6, including
-HTTP/2 support for [net/http](https://golang.org/pkg/net/http/) servers and
-clients, an official package vendoring mechanism, support for blocks in text
-and HTML templates, a memory sanitizer that checks both Go and C/C++ code, and
-the usual assortment of other improvements and fixes.
-
-This is the sixth time we have had the pleasure of writing a birthday blog post
-for Go, and we would not be doing so if not for the wonderful and passionate
-people in our community. The Go team would like to thank everyone who has
-contributed code, written an open source library, authored a blog post, helped
-a new gopher, or just given Go a try. Without you, Go would not be as complete,
-useful, or successful as it is today. Thank you, and celebrate!
diff --git a/_content/6years/6years-gopher.png b/_content/6years/6years-gopher.png
deleted file mode 100644
index 7157563..0000000
--- a/_content/6years/6years-gopher.png
+++ /dev/null
Binary files differ
diff --git a/_content/7years.article b/_content/7years.article
deleted file mode 100644
index 2a1dae2..0000000
--- a/_content/7years.article
+++ /dev/null
@@ -1,52 +0,0 @@
-# Seven years of Go
-10 Nov 2016
-Summary: Happy 7th birthday, Go!
-
-The Go Team
-rsc@golang.org
-
-##
-
-<img src="7years/gopherbelly300.jpg" align="right">
-
-Today marks seven years since we open-sourced our preliminary sketch of Go.
-With the help of the open source community, including more than a thousand
-individual contributors to the Go source repositories,
-Go has matured into a language used all over the world.
-
-The most significant user-facing changes to Go over the past year are the
-addition of built-in support for
-[HTTP/2](https://www.youtube.com/watch?v=FARQMJndUn0#t=0m0s) in
-[Go 1.6](https://golang.org/doc/go1.6) and the integration of the
-[context package](https://blog.golang.org/context) into the standard library in [Go 1.7](https://golang.org/doc/go1.7).
-But we’ve been making many less visible improvements.
-Go 1.7 changed the x86-64 compiler to use a new SSA-based back end,
-improving the performance of most Go programs by 10–20%.
-For Go 1.8, planned for release next February,
-we have changed the compilers for the other architectures to use the new back end too.
-We’ve also added new ports, to Android on 32-bit x86, Linux on 64-bit MIPS,
-and Linux on IBM z Systems.
-And we’ve developed new garbage-collection techniques that reduce typical
-“stop the world” pauses to [under 100 microseconds](https://golang.org/design/17503-eliminate-rescan).
-(Contrast that with Go 1.5’s big news of [10 milliseconds or less](https://blog.golang.org/go15gc).)
-
-This year kicked off with a global Go hackathon,
-the [Gopher Gala](https://blog.golang.org/gophergala), in January.
-Then there were [Go conferences](https://golang.org/wiki/Conferences) in India and Dubai in February,
-China and Japan in April, San Francisco in May, Denver in July,
-London in August, Paris last month, and Brazil this past weekend.
-And GothamGo in New York is next week.
-This year also saw more than 30 new [Go user groups](https://golang.org/wiki/GoUserGroups),
-eight new [Women Who Go](http://www.womenwhogo.org/) chapters,
-and four [GoBridge](https://golangbridge.org/) workshops around the world.
-
-We continue to be overwhelmed by and grateful for
-the enthusiasm and support of the Go community.
-Whether you participate by contributing changes, reporting bugs,
-sharing your expertise in design discussions, writing blog posts or books,
-running meetups, helping others learn or improve,
-open sourcing Go packages you wrote, or just being part of the Go community,
-the Go team thanks you for your help, your time, and your energy.
-Go would not be the success it is today without you.
-
-Thank you, and here’s to another year of fun and success with Go!
diff --git a/_content/7years/gopherbelly300.jpg b/_content/7years/gopherbelly300.jpg
deleted file mode 100644
index 4c8a393..0000000
--- a/_content/7years/gopherbelly300.jpg
+++ /dev/null
Binary files differ
diff --git a/_content/8years.article b/_content/8years.article
deleted file mode 100644
index 4a9d39c..0000000
--- a/_content/8years.article
+++ /dev/null
@@ -1,160 +0,0 @@
-# Eight years of Go
-10 Nov 2017
-Tags: community, birthday
-Summary: Happy 8th birthday, Go!
-
-Steve Francia
-
-##
-
-Today we celebrate 8 years since Go was released as an open source project.
-During [Go’s 4th anniversary](https://blog.golang.org/4years), Andrew
-finished the post with “Here's to four more years!”. Now that we have reached
-that milestone, I cannot help but reflect on how much the project and
-ecosystem has grown since then. In our post 4 years ago we included a chart
-demonstrating Go's rising popularity on Google Trends with the search term
-"golang". Today, we’re including an updated chart. In this relative scale of
-popularity, what was 100 four years ago is now a mere 17. Go’s popularity has
-increased exponentially over the last 8 years and continues to grow.
-
-.image 8years/image1.png
-
-Source: [trends.google.com](https://trends.google.com/trends/explore?date=2009-10-01%202017-10-30&q=golang&hl=en-US)
-
-## Developers love Go
-
-Go has been embraced by developers all over the world with approximately one
-million users worldwide. In the [freshly published 2017 Octoverse](https://octoverse.github.com/)
-by GitHub, **Go has become the #9 most popular language**, surpassing C.
-**Go is the fastest growing language on GitHub in 2017** in the top 10 with
-**52% growth over the previous year**. In growth, Go swapped places with
-Javascript, which fell to the second spot with 44%.
-
-.image 8years/image2.png
-
-Source: [octoverse.github.com](https://octoverse.github.com/)
-
-In [Stack Overflow's 2017 developer survey](https://insights.stackoverflow.com/survey/2017#most-loved-dreaded-and-wanted)
-, Go was the only language that was both on the **top 5 most loved and top 5 most wanted** languages.
-People who use Go, love it, and the people who aren’t using Go, want to be.
-
-.image 8years/image3.png
-.image 8years/image4.png
-
-Source: [insights.stackoverflow.com/survey/2017](https://insights.stackoverflow.com/survey/2017#most-loved-dreaded-and-wanted)
-
-## Go: The language of Cloud Infrastructure
-
-In 2014, analyst Donnie Berkholz called Go
-[the emerging language of cloud infrastructure](http://redmonk.com/dberkholz/2014/03/18/go-the-emerging-language-of-cloud-infrastructure/).
-**By 2017, Go has emerged as the language of cloud infrastructure**.
-Today, **every single cloud company has critical components of their cloud infrastructure implemented in Go**
-including Google Cloud, AWS, Microsoft Azure, Digital Ocean, Heroku and many others. Go
-is a key part of cloud companies like Alibaba, Cloudflare, and Dropbox. Go is
-a critical part of open infrastructure including Kubernetes, Cloud Foundry,
-Openshift, NATS, Docker, Istio, Etcd, Consul, Juju and many more. Companies
-are increasingly choosing Go to build cloud infrastructure solutions.
-
-## Go’s Great Community
-
-It may be hard to imagine that only four years ago the Go community was
-transitioning from online-only to include in-person community with its first
-conference. Now the Go community has had over 30 conferences all around the
-world with hundreds of presentations and tens of thousands of attendees.
-There are hundreds of Go meetups meeting monthly covering much of the globe.
-Wherever you live, you are likely to find a Go meetup nearby.
-
-Two different organizations have been established to help with inclusivity in
-the Go community, Go Bridge and Women Who Go; the latter has grown to over 25
-chapters. Both have been instrumental in offering free trainings. In 2017
-alone over 50 scholarships to conferences have been given through efforts of
-Go Bridge and Women Who Go.
-
-This year we had two significant firsts for the Go project. We had our first
-[contributor summit](https://blog.golang.org/contributors-summit) where
-people from across the Go community came together to
-discuss the needs and future of the Go project. Shortly after, we had the
-first [Go contributor workshop](https://blog.golang.org/contributor-workshop)
-where hundreds of people came to make their first Go contribution.
-
-.image 8years/photo.jpg
-
-Photo by Sameer Ajmani
-
-## Go’s impact on open source
-
-Go has become a major force in the world of open source powering some of the
-most popular projects and enabling innovations across many industries. Find
-thousands of additional applications and libraries at [awesome-go](https://github.com/avelino/awesome-go). Here are
-just a handful of the most popular:
-
-  - [Moby](https://mobyproject.org/) (formerly Docker) is a tool for packaging
-    and running applications in lightweight containers.
-    Its creator Solomon Hykes cited Go's standard library,
-    concurrency primitives, and ease of deployment as key factors,
-    and said "To put it simply, if Docker had not been written in Go,
-    it would not have been as successful."
-
-  - [Kubernetes](https://kubernetes.io/) is a system for automating deployment,
-    scaling and management of containerized applications.
-    Initially designed by Google and used in the Google cloud,
-    Kubernetes now is a critical part of every major cloud offering.
-
-  - [Hugo](https://gohugo.io/) is now the most popular open-source static website engine.
-    With its amazing speed and flexibility, Hugo makes building websites fun again.
-    According to [w3techs](https://w3techs.com/technologies/overview/content_management/all),
-    Hugo now has nearly 3x the usage of Jekyll, the former leader.
-
-  - [Prometheus](https://prometheus.io/) is an open source monitoring solution
-    and time series database that powers metrics and alerting designed to be
-    the system you go to during an outage to allow you to quickly diagnose problems.
-
-  - [Grafana](https://grafana.com/) is an open source,
-    feature-rich metrics dashboard and graph editor for Graphite,
-    Elasticsearch, OpenTSDB, Prometheus and InfluxDB.
-
-  - [Lantern](https://getlantern.org/) delivers fast, reliable and secure access to blocked websites and apps.
-
-  - [Syncthing](https://syncthing.net/) is an open-source cross platform
-    peer-to-peer continuous file synchronization application
-
-  - [Keybase](https://keybase.io/) is a new and free security app for mobile
-    phones and computers.
-    Think of it as an open source Dropbox & Slack with end-to-end encryption
-    public-key cryptography.
-
-  - [Fzf](https://github.com/junegunn/fzf) is an interactive Unix filter
-    for command-line that can be used with any list;
-    files, command history, processes, hostnames,
-    bookmarks, git commits, etc.
-    Fzf supports Unix, macOS and has beta support for Windows.
-    It also can operate as a vim plugin.
-
-Many of these authors have said that their projects would not exist without
-Go. Some like Kubernetes and Docker created entirely new solutions. Others
-like Hugo, Syncthing and Fzf created more refined experiences where many
-solutions already existed. The popularity of these applications alone is
-proof that Go is a ideal language for a broad set of use cases.
-
-## Thank You
-
-This is the eighth time we have had the pleasure of writing a birthday blog
-post for Go and we continue to be overwhelmed by and grateful for the
-enthusiasm and support of the Go community.
-
-Since Go was first open sourced we have had 10 releases of the language,
-libraries and tooling with more than 1680 contributors making over 50,000
-commits to the project's 34 repositories; More than double the number of
-contributors and nearly double the number of commits from only [two years ago](https://blog.golang.org/6years).
-This year we announced that we have begun planning [Go 2](https://blog.golang.org/toward-go2), our first major
-revision of the language and tooling.
-
-The Go team would like to thank everyone who has contributed to the project,
-whether you participate by contributing changes, reporting bugs, sharing your
-expertise in design discussions, writing blog posts or books, running events,
-attending or speaking at events, helping others learn or improve, open
-sourcing Go packages you wrote, contributing artwork, introducing Go to
-someone, or being part of the Go community. Without you, Go would not be as
-complete, useful, or successful as it is today.
-
-Thank you, and here’s to eight more years!
diff --git a/_content/8years/image1.png b/_content/8years/image1.png
deleted file mode 100644
index 947b965..0000000
--- a/_content/8years/image1.png
+++ /dev/null
Binary files differ
diff --git a/_content/8years/image2.png b/_content/8years/image2.png
deleted file mode 100755
index 71219d7..0000000
--- a/_content/8years/image2.png
+++ /dev/null
Binary files differ
diff --git a/_content/8years/image3.png b/_content/8years/image3.png
deleted file mode 100755
index f37d27d..0000000
--- a/_content/8years/image3.png
+++ /dev/null
Binary files differ
diff --git a/_content/8years/image4.png b/_content/8years/image4.png
deleted file mode 100755
index b9d46fe..0000000
--- a/_content/8years/image4.png
+++ /dev/null
Binary files differ
diff --git a/_content/8years/photo.jpg b/_content/8years/photo.jpg
deleted file mode 100644
index e0e3104..0000000
--- a/_content/8years/photo.jpg
+++ /dev/null
Binary files differ
diff --git a/_content/9years.article b/_content/9years.article
deleted file mode 100644
index 71b3137..0000000
--- a/_content/9years.article
+++ /dev/null
@@ -1,100 +0,0 @@
-# Nine years of Go
-10 Nov 2018
-Tags: community, birthday
-Summary: Happy 9th birthday, Go!
-
-Steve Francia
-
-## Introduction
-
-Today marks the ninth anniversary of the day we open-sourced our initial sketch of Go.
-On each anniversary we like to take time to reflect on what has happened over the past year.
-The past 12 months have been a breakout year for the Go language and community.
-
-## Go Love & Adoption
-
-Thanks to all of you, 2018 was an amazing year for Go!
-In multiple industry surveys Gophers expressed how happy they were using Go,
-and many non-Go developers indicated they intended to learn Go before any other language.
-
-In [Stack Overflow’s 2018 Developer Survey](https://insights.stackoverflow.com/survey/2018#most-loved-dreaded-and-wanted),
-Go retained its coveted spot in both the top 5 most loved and top 5 most wanted languages.
-People who use Go love it, and people who aren’t using Go want to.
-
-In [ActiveState’s 2018 Developer Survey](https://www.activestate.com/developer-survey-2018-open-source-runtime-pains),
-Go topped the charts with 36% of users responding they were “Extremely Satisfied” using Go
-and 61% responding “Very Satisfied” or better.
-
-[JetBrains’s 2018 Developer Survey](https://www.jetbrains.com/research/devecosystem-2018/) awarded Go
-the “Most promising language” with 12% of respondents using Go today and 16% intending to use Go in the future.
-
-In [HackerRank’s 2018 Developer Survey](https://research.hackerrank.com/developer-skills/2018/),
-38% of developers responded that they were intending to learn Go next.
-
-We are excited about all of our new gophers and actively working to improve our educational and community resources.
-
-## Go Community
-
-It’s hard to believe that it’s only been five years since
-the first Go conferences and Go meetups.
-We’ve seen major growth in this area of community leadership over the last year.
-There are now over 20 [Go conferences](https://github.com/golang/go/wiki/Conferences)
-and over 300 [Go-related meetups](https://www.meetup.com/topics/golang/) spanning the globe.
-
-Thanks to the hard work put into these many conferences and meetups,
-there have been hundreds of great talks this year.
-Here are a few of our favorite talks specifically discussing the growth of our community
-and how we can better support gophers worldwide.
-
-  - [Writing Accessible Go](https://www.youtube.com/watch?v=cVaDY0ChvOQ), by Julia Ferraioli at GopherCon
-  - [The Importance of Beginners](https://www.youtube.com/watch?v=7yMXs9TRvVI), by Natalie Pistunovich at GopherCon
-  - [The Legacy of Go, Part 2](https://www.youtube.com/watch?v=I_KcpgxcFyU), by Carmen Andoh at GothamGo
-  - [Growing a Community of Gophers](https://www.youtube.com/watch?v=dl1mCGKwlYY), by Cassandra Salisbury at Gopherpalooza
-
-On that theme, this year we also [revised our code of conduct](https://blog.golang.org/conduct-2018)
-to better support inclusivity in the Go community.
-
-The Go community is truly global.
-At GopherCon Europe in Iceland this past summer, gophers literally spanned the gap between the continents.
-
-.image 9years/9years-iceland.jpg _ 800
-
-_(Photo by Winter Francia.)_
-
-## Go 2
-
-After five years of experience with Go 1, we’ve started looking at
-what we should change about Go to better support
-[programming at scale](https://talks.golang.org/2012/splash.article).
-
-Last spring, we published a [draft design for Go modules](https://blog.golang.org/versioning-proposal),
-which provide an integrated mechanism for versioning and package distribution.
-The most recent Go release, Go 1.11, included
-[preliminary support for modules](https://golang.org/doc/go1.11#modules).
-
-Last summer we published
-[early draft designs](https://blog.golang.org/go2draft)
-for how Go 2 might better support error values, error handling, and generic programming.
-
-We are excited about refining these designs with the community’s help as we work
-[toward Go 2](https://blog.golang.org/toward-go2).
-
-## Go Contributors
-
-The Go project has been increasing in the number of contributions from the community for several years.
-The project hit a major milestone in mid-2018 when, for the first time,
-we had more contributions coming from the community than the Go team.
-
-.image 9years/9years-graph.png _ 600
-
-## Thank You
-
-On a personal note, from the entire Go team,
-we want to sincerely thank all of you.
-We feel privileged to be able to work on the Go project
-and are grateful to the many gophers around the world who have joined us.
-
-We are especially thankful for the thousands of volunteers
-who help through mentorship, organizing, contributing,
-and supporting your fellow gophers.
-You have made Go what it is today.
diff --git a/_content/9years/9years-graph.png b/_content/9years/9years-graph.png
deleted file mode 100644
index 812d4f0..0000000
--- a/_content/9years/9years-graph.png
+++ /dev/null
Binary files differ
diff --git a/_content/9years/9years-iceland.jpg b/_content/9years/9years-iceland.jpg
deleted file mode 100644
index 376b8ed..0000000
--- a/_content/9years/9years-iceland.jpg
+++ /dev/null
Binary files differ
diff --git a/_content/README b/_content/README
deleted file mode 100644
index 30e149c..0000000
--- a/_content/README
+++ /dev/null
@@ -1,27 +0,0 @@
-This directory holds Go blog articles, in *.article.
-See https://pkg.go.dev/golang.org/x/tools/present?tab=doc
-for documentation of the file format or look at any of the
-articles for examples.
-
-Article file names should be short, amenable to being typed by hand in URLs.
-Typically article file names are up to three words, separated by dashes.
-A trailing year in the name typically does not have a dash before it.
-
-All supporting files for an article, even if there's only one, should be
-placed in a directory named for the article (minus the .article suffix).
-
-If your article has code that is meant to be a working program, please use
-.code, or ideally .play, to load the lines from a supporting .go file.
-That way you can easily check that the .go file, and therefore the code
-in your article, still works.
-
-Please use .image and .video to embed images and videos,
-instead of using raw HTML tags. The .image and .video commands
-provide a way to adjust the implementation of those embeddings
-all in one place.
-
-Please use .html when it is necessary to add large blocks of HTML,
-keeping article text in the main .article file. Another important use of
-.html is to factor out an HTML snippet that appears multiple times.
-Short HTML sequences, like <div><center> or </div></center>,
-are fine to put directly in the article files.
diff --git a/_content/appengine-155.article b/_content/appengine-155.article
deleted file mode 100644
index 37cf290..0000000
--- a/_content/appengine-155.article
+++ /dev/null
@@ -1,44 +0,0 @@
-# Go App Engine SDK 1.5.5 released
-11 Oct 2011
-Tags: appengine, gofix, release
-Summary: Go App Engine SDK 1.5.5 includes Go release.r60.2.
-OldURL: /go-app-engine-sdk-155-released
-
-Andrew Gerrand
-
-##
-
-Today we released version 1.5.5 the Go App Engine SDK.
-You can download it from the [App Engine downloads page](http://code.google.com/appengine/downloads.html).
-
-This release includes changes and improvements to the App Engine APIs and
-brings the supporting Go tool chain to [release.r60.2](https://golang.org/doc/devel/release.html#r60)
-(the current stable release).
-Also included in this release are the [godoc](https://golang.org/cmd/godoc/),
-[gofmt](https://golang.org/cmd/gofmt/),
-and [gofix](https://golang.org/cmd/gofix/) tools from the Go tool chain.
-They can be found in the root directory of the SDK.
-
-Some changes made in this release are backwards-incompatible,
-so we have incremented the SDK `api_version` to 3.
-Existing apps will require code changes when migrating to `api_version` 3.
-
-The gofix tool that ships with the SDK has been customized with App Engine-specific modules.
-It can be used to automatically update Go apps to work with the latest appengine
-packages and the updated Go standard library.
-To update your apps, run:
-
-	/path/to/sdk/gofix /path/to/your/app
-
-The SDK now includes the appengine package source code,
-so you can use the local godoc to read App Engine API documentation:
-
-	/path/to/sdk/godoc appengine/datastore Get
-
-**Important note:** We have deprecated `api_version` 2.
-Go apps that use `api_version` 2 will stop working after 16 December 2011.
-Please update your apps to use `api_version` 3 before then.
-
-See the [release notes](http://code.google.com/p/googleappengine/wiki/SdkForGoReleaseNotes)
-for a full list of changes.
-Please direct any questions about the new SDK to the [Go App Engine discussion group](http://groups.google.com/group/google-appengine-go).
diff --git a/_content/appengine-171.article b/_content/appengine-171.article
deleted file mode 100644
index 57c047d..0000000
--- a/_content/appengine-171.article
+++ /dev/null
@@ -1,45 +0,0 @@
-# Go updates in App Engine 1.7.1
-22 Aug 2012
-Tags: appengine, release
-Summary: App Engine SDK 1.7.1 adds memcache and other functionality for Go.
-OldURL: /go-updates-in-app-engine-171
-
-Andrew Gerrand
-
-##
-
-This week we released version 1.7.1 of the App Engine SDK.
-It includes some significant updates specific to the App Engine runtime for Go.
-
-The [memcache package](https://developers.google.com/appengine/docs/go/memcache/reference) has
-had some additions to its [Codec](https://developers.google.com/appengine/docs/go/memcache/reference#Codec) convenience type.
-The SetMulti, AddMulti, CompareAndSwap, and CompareAndSwapMulti methods
-make it easier to store and update encoded data in the [Memcache Service](https://developers.google.com/appengine/docs/go/memcache/overview).
-
-The [bulkloader tool](https://developers.google.com/appengine/docs/go/tools/uploadingdata) can
-now be used with Go apps,
-allowing users to upload and download datastore records in bulk.
-This is useful for backups and offline processing,
-and a great help when migrating Python or Java apps to the Go runtime.
-
-The [Images Service](https://developers.google.com/appengine/docs/go/images/overview) is
-now available to Go users.
-The new [appengine/image package](https://developers.google.com/appengine/docs/go/images/reference) supports serving
-images directly from Blobstore and resizing or cropping those images on the fly.
-Note that this is not the full image service as provided by the Python and Java SDKs,
-as much of the equivalent functionality is available in the [standard Go image package](https://golang.org/pkg/image/) and
-external packages such as [graphics-go](http://code.google.com/p/graphics-go/).
-
-The new [runtime.RunInBackground](https://developers.google.com/appengine/docs/go/backends/runtime#RunInBackground) function
-allows backend requests to spawn a new request independent of the initial request.
-These can run in the background as long as the backend stays alive.
-
-Finally, we have filled in some missing functionality:
-the [xmpp package](https://developers.google.com/appengine/docs/go/xmpp/reference) now
-supports sending presence updates and chat invitations and retrieving the
-presence state of another user,
-and the [user package](https://developers.google.com/appengine/docs/go/users/reference) supports
-authenticating clients with OAuth.
-
-You can grab the new SDK from the [App Engine downloads page](https://developers.google.com/appengine/downloads#Google_App_Engine_SDK_for_Go) and
-browse the [updated documentation](https://developers.google.com/appengine/docs/go).
diff --git a/_content/appengine-dec2013.article b/_content/appengine-dec2013.article
deleted file mode 100644
index 030323f..0000000
--- a/_content/appengine-dec2013.article
+++ /dev/null
@@ -1,111 +0,0 @@
-# Go on App Engine: tools, tests, and concurrency
-13 Dec 2013
-Tags: appengine
-Summary: Announcing improvements to Go on App Engine.
-
-Andrew Gerrand
-
-Johan Euphrosine
-
-## Background
-
-When we [launched Go for App Engine](https://blog.golang.org/go-and-google-app-engine)
-in May 2011 the SDK was just a modified version of the Python SDK.
-At the time, there was no canonical way to build or organize Go programs, so it
-made sense to take the Python approach. Since then Go 1.0 was released,
-including the [go tool](https://golang.org/cmd/go/) and a
-[convention](https://golang.org/doc/code.html) for organizing Go programs.
-
-In January 2013 we announced
-[better integration](https://blog.golang.org/the-app-engine-sdk-and-workspaces-gopath)
-between the Go App Engine SDK and the go tool, promoting the use of
-conventional import paths in App Engine apps and making it possible to use "go
-get" to fetch app dependencies.
-
-With the recent release of App Engine 1.8.8 we are pleased to announce more
-improvements to the developer experience for Go on App Engine.
-
-## The goapp tool
-
-The Go App Engine SDK now includes the "goapp" tool, an App Engine-specific
-version of the "go" tool. The new name permits users to keep both the regular
-"go" tool and the "goapp" tool in their system PATH.
-
-In addition to the existing "go" tool [commands](https://golang.org/cmd/go/),
-the "goapp" tool provides new commands for working with App Engine apps.
-The "[goapp serve](https://developers.google.com/appengine/docs/go/tools/devserver)"
-command starts the local development server and the
-"[goapp deploy](https://developers.google.com/appengine/docs/go/tools/uploadinganapp)"
-command uploads an app to App Engine.
-
-The main advantages offered by the "goapp serve" and "goapp deploy" commands
-are a simplified user interface and consistency with existing commands like
-"go get" and "go fmt".
-For example, to run a local instance of the app in the current directory, run:
-
-	$ goapp serve
-
-To upload it to App Engine:
-
-	$ goapp deploy
-
-You can also specify the Go import path to serve or deploy:
-
-	$ goapp serve github.com/user/myapp
-
-You can even specify a YAML file to serve or deploy a specific
-[module](https://developers.google.com/appengine/docs/go/modules/):
-
-	$ goapp deploy mymodule.yaml
-
-These commands can replace most uses of `dev_appserver.py` and `appcfg.py`,
-although the Python tools are still available for their less common uses.
-
-## Local unit testing
-
-The Go App Engine SDK now supports local unit testing, using Go's native
-[testing package](https://developers.google.com/appengine/docs/go/tools/localunittesting)
-and the "[go test](https://golang.org/cmd/go/#hdr-Test_packages)" command
-(provided as "goapp test" by the SDK).
-
-Furthermore, you can now write tests that use App Engine services.
-The [aetest package](https://developers.google.com/appengine/docs/go/tools/localunittesting#Go_Introducing_the_aetest_package)
-provides an appengine.Context value that delegates requests to a temporary
-instance of the development server.
-
-For more information about using "goapp test" and the aetest package, see the
-[Local Unit Testing for Go documentation](https://developers.google.com/appengine/docs/go/tools/localunittesting).
-Note that the aetest package is still in its early days;
-we hope to add more features over time.
-
-## Better concurrency support
-
-It is now possible to configure the number of concurrent requests served by
-each of your app's dynamic instances by setting the
-[`max_concurrent_requests`](https://developers.google.com/appengine/docs/go/modules/#max_concurrent_requests) option
-(available to [Automatic Scaling modules](https://developers.google.com/appengine/docs/go/modules/#automatic_scaling) only).
-
-Here's an example `app.yaml` file:
-
-	application: maxigopher
-	version: 1
-	runtime: go
-	api_version: go1
-	automatic_scaling:
-	  max_concurrent_requests: 100
-
-This configures each instance of the app to serve up to 100 requests
-concurrently (up from the default of 10). You can configure Go instances to
-serve up to a maximum of 500 concurrent requests.
-
-This setting allows your instances to handle more simultaneous requests by
-taking advantage of Go's efficient handling of concurrency, which should yield
-better instance utilization and ultimately fewer billable instance hours.
-
-## Conclusion
-
-With these changes Go on App Engine is more convenient and efficient than ever,
-and we hope you enjoy the improvements. Please join the
-[google-appengine-go group](http://groups.google.com/group/google-appengine-go/)
-to raise questions or discuss these changes with the engineering team and the
-rest of the community.
diff --git a/_content/appengine-ga.article b/_content/appengine-ga.article
deleted file mode 100644
index 964efc1..0000000
--- a/_content/appengine-ga.article
+++ /dev/null
@@ -1,36 +0,0 @@
-# Go for App Engine is now generally available
-21 Jul 2011
-Tags: appengine, release
-Summary: You can use Go on App Engine now!
-OldURL: /go-for-app-engine-is-now-generally
-
-Andrew Gerrand
-
-##
-
-The Go and App Engine teams are excited to announce that the Go runtime
-for App Engine is now generally available.
-This means you can take that Go app you've been working on (or meaning to
-work on) and deploy it to App Engine right now with the new [1.5.2 SDK](http://code.google.com/appengine/downloads.html).
-
-Since we announced the Go runtime at Google I/O we have continued to [improve and extend](http://code.google.com/p/googleappengine/wiki/SdkForGoReleaseNotes)
-Go support for the App Engine APIs and have added the Channels API.
-The Go Datastore API now supports transactions and ancestor queries, too.
-See the [Go App Engine documentation](https://code.google.com/appengine/docs/go/)
-for all the details.
-
-For those who have been using the Go SDK already,
-please note that the 1.5.2 release introduces `api_version` 2.
-This is because the new SDK is based on Go `release.r58.1` (the current
-stable version of Go) and is not backwards compatible with the previous release.
-Existing apps may require changes as per the [r58 release notes](https://golang.org/doc/devel/release.html#r58).
-Once you've updated your code, you should redeploy your app with the line
-`api_version: 2` in its `app.yaml` file.
-Apps written against `api_version` 1 will stop working after the 18th of August.
-
-Finally, we owe a huge thanks to our trusted testers and their many bug reports.
-Their help was invaluable in reaching this important milestone.
-
-_The fastest way to get started with Go on App Engine is with the_ [_Getting Started guide_](http://code.google.com/appengine/docs/go/gettingstarted/).
-
-_Note that the Go runtime is still considered experimental; it is not as well-supported as the Python and Java runtimes._
diff --git a/_content/appengine-go111.article b/_content/appengine-go111.article
deleted file mode 100644
index 7d0dd8a..0000000
--- a/_content/appengine-go111.article
+++ /dev/null
@@ -1,77 +0,0 @@
-# Announcing App Engine’s New Go 1.11 Runtime
-16 Oct 2018
-Tags: appengine
-Summary: Google Cloud is announcing a new Go 1.11 runtime for App Engine, with fewer limits on app structure.
-
-Eno Compton
-
-Tyler Bui-Palsulich
-
-##
-
-[App Engine](https://cloud.google.com/appengine/) launched
-[experimental support for Go](https://blog.golang.org/go-and-google-app-engine)
-in 2011. In the subsequent years, the Go community has grown significantly and
-has settled on idiomatic
-patterns for cloud-based applications. Today, Google Cloud is
-[announcing a new Go 1.11 runtime](https://cloud.google.com/blog/products/application-development/go-1-11-is-now-available-on-app-engine)
-for the App Engine standard environment that provides all the
-power of App Engine—things like paying only for what you use, automatic scaling,
-and managed infrastructure—while supporting idiomatic Go.
-
-Starting with Go 1.11, Go on App Engine has no limits on application structure,
-supported packages, `context.Context` values, or HTTP clients. Write your Go
-application however you prefer, add an `app.yaml` file, and your app is ready
-to deploy on App Engine.
-[Specifying Dependencies](https://cloud.google.com/appengine/docs/standard/go111/specifying-dependencies)
-describes how the new runtime
-supports [vendoring](https://golang.org/cmd/go/#hdr-Vendor_Directories) and
-[modules](https://golang.org/doc/go1.11#modules) (experimental) for dependency
-management.
-
-Along with [Cloud Functions support for Go](https://twitter.com/kelseyhightower/status/1035278586754813952)
-(more on that in a future post), App Engine provides a compelling way to run Go
-code on Google Cloud Platform (GCP) with no concern for the underlying
-infrastructure.
-
-Let’s take a look at creating a small application for App Engine. For the
-example here, we assume a `GOPATH`-based workflow, although Go modules have
-[experimental support](https://cloud.google.com/appengine/docs/standard/go111/specifying-dependencies)
-as well.
-
-First, you create the application in your `GOPATH`:
-
-.code appengine/main.go
-
-The code contains an idiomatic setup for a small HTTP server that responds with
-“Hello, 世界.” If you have previous App Engine experience, you’ll notice the
-absence of any call to `appengine.Main()`, which is now entirely optional.
-Furthermore, the application code is completely portable—there are no ties to
-the infrastructure that your application is deployed on.
-
-If you need to use external dependencies, you can add those dependencies to a
-`vendor` directory or to a `go.mod` file, both of which the new runtime
-supports.
-
-With the application code complete, create an `app.yaml` file to specify
-the runtime:
-
-	runtime: go111
-
-Finally, set your machine up with a Google Cloud Platform account:
-
-  - Create an account with [https://cloud.google.com](GCP).
-  - [Create a project](https://cloud.google.com/resource-manager/docs/creating-managing-projects).
-  - Install the [Cloud SDK](https://cloud.google.com/sdk/) on your system.
-
-With all the setup complete, you can deploy using one command:
-
-	gcloud app deploy
-
-We think Go developers will find the new Go 1.11 runtime for App Engine an
-exciting addition to the available options to run Go applications. There is a
-[free tier](https://cloud.google.com/free/). Check out the
-[getting started guide](https://cloud.google.com/appengine/docs/standard/go111/building-app/)
-or the
-[migration guide](https://cloud.google.com/appengine/docs/standard/go111/go-differences)
-and deploy an app to the new runtime today!
diff --git a/_content/appengine-gopath.article b/_content/appengine-gopath.article
deleted file mode 100644
index d9f995b..0000000
--- a/_content/appengine-gopath.article
+++ /dev/null
@@ -1,157 +0,0 @@
-# The App Engine SDK and workspaces (GOPATH)
-9 Jan 2013
-Tags: appengine, tools, gopath
-Summary: App Engine SDK 1.7.4 adds support for GOPATH-style workspaces.
-OldURL: /the-app-engine-sdk-and-workspaces-gopath
-
-Andrew Gerrand
-
-## Introduction
-
-When we released Go 1 we introduced the [go tool](https://golang.org/cmd/go/) and,
-with it, the concept of workspaces.
-Workspaces (specified by the GOPATH environment variable) are a convention
-for organizing code that simplifies fetching,
-building, and installing Go packages.
-If you're not familiar with workspaces, please read [this article](https://golang.org/doc/code.html)
-or watch [this screencast](http://www.youtube.com/watch?v=XCsL89YtqCs) before reading on.
-
-Until recently, the tools in the App Engine SDK were not aware of workspaces.
-Without workspaces the "[go get](https://golang.org/cmd/go/#hdr-Download_and_install_packages_and_dependencies)"
-command cannot function,
-and so app authors had to install and update their app dependencies manually. It was a pain.
-
-This has all changed with version 1.7.4 of the App Engine SDK.
-The [dev\_appserver](https://developers.google.com/appengine/docs/go/tools/devserver)
-and [appcfg](https://developers.google.com/appengine/docs/go/tools/uploadinganapp)
-tools are now workspace-aware.
-When running locally or uploading an app,
-these tools now search for dependencies in the workspaces specified by the
-GOPATH environment variable.
-This means you can now use "go get" while building App Engine apps,
-and switch between normal Go programs and App Engine apps without changing
-your environment or habits.
-
-For example, let's say you want to build an app that uses OAuth 2.0 to authenticate
-with a remote service.
-A popular OAuth 2.0 library for Go is the [oauth2](https://godoc.org/golang.org/x/oauth2) package,
-which you can install to your workspace with this command:
-
-	go get golang.org/x/oauth2
-
-When writing your App Engine app, import the oauth package just as you would in a regular Go program:
-
-	import "golang.org/x/oauth2"
-
-Now, whether running your app with the dev\_appserver or deploying it with appcfg,
-the tools will find the oauth package in your workspace. It just works.
-
-## Hybrid stand-alone/App Engine apps
-
-The Go App Engine SDK builds on Go's standard [net/http](https://golang.org/pkg/net/http/)
-package to serve web requests and,
-as a result, many Go web servers can be run on App Engine with only a few changes.
-For example, [godoc](https://golang.org/cmd/godoc/) is included in the
-Go distribution as a stand-alone program,
-but it can also run as an App Engine app (godoc serves [golang.org](https://golang.org/) from App Engine).
-
-But wouldn't it be nice if you could write a program that is both a stand-alone
-web server and an App Engine app? By using [build constraints](https://golang.org/pkg/go/build/#hdr-Build_Constraints), you can.
-
-Build constraints are line comments that determine whether a file should
-be included in a package.
-They are most often used in code that handles a variety of operating systems
-or processor architectures.
-For instance, the [path/filepath](https://golang.org/pkg/path/filepath/)
-package includes the file [symlink.go](https://golang.org/src/pkg/path/filepath/symlink.go),
-which specifies a build constraint to ensure that it is not built on Windows
-systems (which do not have symbolic links):
-
-	// +build !windows
-
-The App Engine SDK introduces a new build constraint term: "appengine". Files that specify
-
-	// +build appengine
-
-will be built by the App Engine SDK and ignored by the go tool. Conversely, files that specify
-
-	// +build !appengine
-
-are ignored by the App Engine SDK, while the go tool will happily build them.
-
-The [goprotobuf](http://code.google.com/p/goprotobuf/) library uses this
-mechanism to provide two implementations of a key part of its encode/decode machinery:
-[pointer\_unsafe.go](http://code.google.com/p/goprotobuf/source/browse/proto/pointer_unsafe.go)
-is the faster version that cannot be used on App Engine because it uses
-the [unsafe package](https://golang.org/pkg/unsafe/),
-while [pointer\_reflect.go](http://code.google.com/p/goprotobuf/source/browse/proto/pointer_reflect.go)
-is a slower version that avoids unsafe by using the [reflect package](https://golang.org/pkg/reflect/) instead.
-
-Let's take a simple Go web server and turn it into a hybrid app. This is main.go:
-
-	package main
-
-	import (
-	    "fmt"
-	    "net/http"
-	)
-
-	func main() {
-	    http.HandleFunc("/", handler)
-	    http.ListenAndServe("localhost:8080", nil)
-	}
-
-	func handler(w http.ResponseWriter, r *http.Request) {
-	    fmt.Fprint(w, "Hello!")
-	}
-
-Build this with the go tool and you'll get a stand-alone web server executable.
-
-The App Engine infrastructure provides its own main function that runs its
-equivalent to ListenAndServe.
-To convert main.go to an App Engine app, drop the call to ListenAndServe
-and register the handler in an init function (which runs before main). This is app.go:
-
-	package main
-
-	import (
-	    "fmt"
-	    "net/http"
-	)
-
-	func init() {
-	    http.HandleFunc("/", handler)
-	}
-
-	func handler(w http.ResponseWriter, r *http.Request) {
-	    fmt.Fprint(w, "Hello!")
-	}
-
-To make this a hybrid app, we need to split it into an App Engine-specific part,
-an stand-alone binary-specific part, and the parts common to both versions.
-In this case, there is no App Engine-specific part,
-so we split it into just two files:
-
-app.go specifies and registers the handler function.
-It is identical to the code listing above,
-and requires no build constraints as it should be included in all versions of the program.
-
-main.go runs the web server. It includes the "!appengine" build constraint,
-as it must only included when building the stand-alone binary.
-
-	// +build !appengine
-
-	package main
-
-	import "net/http"
-
-	func main() {
-	    http.ListenAndServe("localhost:8080", nil)
-	}
-
-To see a more complex hybrid app, take a look at the [present tool](https://godoc.org/golang.org/x/tools/present).
-
-## Conclusions
-
-We hope these changes will make it easier to work on apps with external dependencies,
-and to maintain code bases that contain both stand-alone programs and App Engine apps.
diff --git a/_content/appengine-scalable.article b/_content/appengine-scalable.article
deleted file mode 100644
index 4a91040..0000000
--- a/_content/appengine-scalable.article
+++ /dev/null
@@ -1,35 +0,0 @@
-# Writing scalable App Engine applications
-1 Nov 2011
-Tags: appengine, optimization
-Summary: How to build scalable web applications using Go with Google App Engine.
-OldURL: /writing-scalable-app-engine
-
-David Symonds
-
-##
-
-Back in May, we [announced](https://blog.golang.org/2011/05/go-and-google-app-engine.html)
-the Go runtime for App Engine.
-Since then, we've opened it up for everyone to use,
-added many new APIs, and improved performance.
-We have been thrilled by all the interesting ways that people are using Go on App Engine.
-One of the key benefits of the Go runtime,
-apart from working in a fantastic language,
-is that it has high performance.
-Go applications compile to native code, with no interpreter or virtual machine
-getting between your program and the machine.
-
-Making your web application fast is important because it is well known that
-a web site's latency has a measurable impact on user happiness,
-and [Google web search uses it as a ranking factor](https://googlewebmastercentral.blogspot.com/2010/04/using-site-speed-in-web-search-ranking.html).
-Also announced in May was that App Engine would be [leaving its Preview status](http://googleappengine.blogspot.com/2011/05/year-ahead-for-google-app-engine.html)
-and transitioning to a [new pricing model](https://www.google.com/enterprise/cloud/appengine/pricing.html),
-providing another reason to write efficient App Engine applications.
-
-To make it easier for Go developers using App Engine to write highly efficient,
-scalable applications, we recently updated some existing App Engine articles
-to include snippets of Go source code and to link to relevant Go documentation.
-
-  - [Best practices for writing scalable applications](http://code.google.com/appengine/articles/scaling/overview.html)
-
-  - [Managing Your App's Resource Usage](http://code.google.com/appengine/articles/managing-resources.html)
diff --git a/_content/appengine.article b/_content/appengine.article
deleted file mode 100644
index 89b8244..0000000
--- a/_content/appengine.article
+++ /dev/null
@@ -1,77 +0,0 @@
-# Go and Google App Engine
-10 May 2011
-Tags: appengine, release
-Summary: Announcing support for Go in Google App Engine.
-OldURL: /go-and-google-app-engine
-
-David Symonds
-
-Nigel Tao
-
-Andrew Gerrand
-
-##
-
-Google’s App Engine provides a reliable,
-scalable, easy way to build and deploy applications for the web.
-Over a hundred thousand apps are hosted at appspot.com and custom domains
-using the App Engine infrastructure.
-Originally written for Python apps, in 2009 the system added a Java runtime.
-And today, at Google I/O, we’re thrilled to announce that Go will be next.
-It’s marked as an experimental App Engine feature for now,
-because it’s early days, but both the App Engine and Go teams are very
-excited about this milestone.
-
-By early days, we mean that it’s still rolling out.
-As of today, the App Engine SDK for Go is [available for download](http://code.google.com/p/googleappengine/downloads/list),
-and we will soon enable deployment of Go apps into the App Engine hosting infrastructure.
-Today, through the SDK, you’ll be able to write web apps,
-learn about the APIs (and the language, if it’s new to you),
-and run your web app locally.
-Once full deployment is enabled, it’ll be easy to push your app to Google’s cloud.
-
-One of the cool but less obvious things about this news is that it provides
-a very easy way to play with Go.
-You don’t even need to have Go installed beforehand because the SDK is
-fully self-contained.
-Just download the SDK, unzip it, and start coding.
-Moreover, the SDK’s “dev app server” means you don’t even need to
-run the compiler yourself;
-everything is delightfully automatic.
-
-What you’ll find in the SDK is many of the standard App Engine APIs,
-custom designed in good Go style, including Datastore,
-Blobstore, URL Fetch, Mail, Users, and so on.
-More APIs will be added as the environment develops.
-The runtime provides the full Go language and almost all the standard libraries,
-except for a few things that don’t make sense in the App Engine environment.
-For instance, there is no `unsafe` package and the `syscall` package is trimmed.
-(The implementation uses an expanded version of the setup in the [Go Playground](https://golang.org/doc/play/)
-on [golang.org](https://golang.org/).)
-
-Also, although goroutines and channels are present,
-when a Go app runs on App Engine only one thread is run in a given instance.
-That is, all goroutines run in a single operating system thread,
-so there is no CPU parallelism available for a given client request.
-We expect this restriction will be lifted at some point.
-
-Despite these minor restrictions, it’s the real language:
-Code is deployed in source form and compiled in the cloud using the 64-bit x86 compiler (6g),
-making it the first true compiled language that runs on App Engine.
-Go on App Engine makes it possible to deploy efficient,
-CPU-intensive web applications.
-
-If you want to know more, read the [documentation](http://code.google.com/appengine/docs/go/)
-(start with “[Getting Started](http://code.google.com/appengine/docs/go/gettingstarted/)”).
-The libraries and SDK are open source, hosted at [http://code.google.com/p/appengine-go/](http://code.google.com/p/appengine-go/).
-We’ve created a new [google-appengine-go](http://groups.google.com/group/google-appengine-go) mailing list;
-feel free to contact us there with App Engine-specific questions.
-The [issue tracker for App Engine](http://code.google.com/p/googleappengine/issues/list)
-is the place for reporting issues related to the new Go SDK.
-
-The Go App Engine SDK is [available](http://code.google.com/p/googleappengine/downloads/list)
-for Linux and Mac OS X (10.5 or greater);
-we hope a Windows version will also be available soon.
-
-We’d like to offer our thanks for all the help and enthusiasm we received
-from Google’s App Engine team in making this happen.
diff --git a/_content/appengine/main.go b/_content/appengine/main.go
deleted file mode 100644
index ac8feda..0000000
--- a/_content/appengine/main.go
+++ /dev/null
@@ -1,23 +0,0 @@
-// This server can run on App Engine.
-package main
-
-import (
-	"fmt"
-	"log"
-	"net/http"
-	"os"
-)
-
-func main() {
-	port := os.Getenv("PORT")
-	if port == "" {
-		port = "8080"
-	}
-	http.HandleFunc("/", hello)
-
-	log.Fatal(http.ListenAndServe(fmt.Sprintf(":%s", port), nil))
-}
-
-func hello(w http.ResponseWriter, r *http.Request) {
-	w.Write([]byte("Hello, 世界"))
-}
diff --git a/_content/bossie.article b/_content/bossie.article
deleted file mode 100644
index bff5a23..0000000
--- a/_content/bossie.article
+++ /dev/null
@@ -1,28 +0,0 @@
-# Go Wins 2010 Bossie Award
-6 Sep 2010
-Summary: Go wins a 2010 Bossie Award for “best open source application development software.” 
-OldURL: /go-wins-2010-bossie-award
-
-Andrew Gerrand
-
-##
-
-The Go project has been awarded a [Bossie Award](http://www.infoworld.com/d/open-source/bossie-awards-2010-the-best-open-source-application-development-software-140&current=2&last=1)
-for "best open source application development software." The [Bossie Awards](http://www.infoworld.com/d/open-source/bossie-awards-2010-the-best-open-source-software-the-year-115)
-have been given each year since 2007 by [InfoWorld](http://infoworld.com/)
-to recognize the best Open Source projects.
-Their citation reads:
-
-Google's Go language tries to restore simplicity to programming.
-It does away with numerous constructs that have crept into all OO languages
-by re-imagining how to simplify and improve the conversation between a developer and the code.
-Go provides garbage collection, type safety,
-memory safety, and built-in support for concurrency and for Unicode characters.
-In addition, it compiles (fast!) to binaries for multiple platforms.
-Go is still in development (new features are being added) and it has limitations,
-notably poor support for Windows.
-But it shows a new, exciting direction in programming languages.
-
-The Go team are pleased to accept this award.
-It reflects not only our hard work, but also the efforts of the growing
-community of Go developers to whom we must extend our sincere thanks.
diff --git a/_content/cgo.article b/_content/cgo.article
deleted file mode 100644
index 66988fa..0000000
--- a/_content/cgo.article
+++ /dev/null
@@ -1,151 +0,0 @@
-# C? Go? Cgo!
-17 Mar 2011
-Tags: cgo, technical
-Summary: How to use cgo to let Go packages call C code.
-OldURL: /c-go-cgo
-
-Andrew Gerrand
-
-## Introduction
-
-Cgo lets Go packages call C code. Given a Go source file written with some special features,
-cgo outputs Go and C files that can be combined into a single Go package.
-
-To lead with an example, here's a Go package that provides two functions -
-`Random` and `Seed` - that wrap C's `random` and `srandom` functions.
-
-	package rand
-
-	/*
-	#include <stdlib.h>
-	*/
-	import "C"
-
-	func Random() int {
-	    return int(C.random())
-	}
-
-	func Seed(i int) {
-	    C.srandom(C.uint(i))
-	}
-
-Let's look at what's happening here, starting with the import statement.
-
-The `rand` package imports `"C"`, but you'll find there's no such package
-in the standard Go library.
-That's because `C` is a "pseudo-package",
-a special name interpreted by cgo as a reference to C's name space.
-
-The `rand` package contains four references to the `C` package:
-the calls to `C.random` and `C.srandom`, the conversion `C.uint(i)`,
-and the `import` statement.
-
-The `Random` function calls the standard C library's `random` function and returns the result.
-In C, `random` returns a value of the C type `long`,
-which cgo represents as the type `C.long`.
-It must be converted to a Go type before it can be used by Go code outside this package,
-using an ordinary Go type conversion:
-
-	func Random() int {
-	    return int(C.random())
-	}
-
-Here's an equivalent function that uses a temporary variable to illustrate the type conversion more explicitly:
-
-	func Random() int {
-	    var r C.long = C.random()
-	    return int(r)
-	}
-
-The `Seed` function does the reverse, in a way.
-It takes a regular Go `int`, converts it to the C `unsigned int` type,
-and passes it to the C function `srandom`.
-
-	func Seed(i int) {
-	    C.srandom(C.uint(i))
-	}
-
-Note that cgo knows the `unsigned int` type as `C.uint`;
-see the [cgo documentation](https://golang.org/cmd/cgo) for a complete
-list of these numeric type names.
-
-The one detail of this example we haven't examined yet is the comment above the `import` statement.
-
-	/*
-	#include <stdlib.h>
-	*/
-	import "C"
-
-Cgo recognizes this comment.  Any lines starting with `#cgo` followed by
-a space character are removed;
-these become directives for cgo.
-The remaining lines are used as a header when compiling the C parts of the package.
-In this case those lines are just a single `#include` statement,
-but they can be almost any C code.
-The `#cgo` directives are used to provide flags for the compiler and linker
-when building the C parts of the package.
-
-There is a limitation: if your program uses any `//export` directives,
-then the C code in the comment may only include declarations (`extern int f();`),
-not definitions (`int f() { return 1; }`).
-You can use `//export` directives to make Go functions accessible to C code.
-
-The `#cgo` and `//export` directives are documented in the [cgo documentation](https://golang.org/cmd/cgo/).
-
-## Strings and things
-
-Unlike Go, C doesn't have an explicit string type. Strings in C are represented by a zero-terminated array of chars.
-
-Conversion between Go and C strings is done with the `C.CString`,
-`C.GoString`, and `C.GoStringN` functions.
-These conversions make a copy of the string data.
-
-This next example implements a `Print` function that writes a string to
-standard output using C's `fputs` function from the `stdio` library:
-
-	package print
-
-	// #include <stdio.h>
-	// #include <stdlib.h>
-	import "C"
-	import "unsafe"
-
-	func Print(s string) {
-	    cs := C.CString(s)
-	    C.fputs(cs, (*C.FILE)(C.stdout))
-	    C.free(unsafe.Pointer(cs))
-	}
-
-Memory allocations made by C code are not known to Go's memory manager.
-When you create a C string with `C.CString` (or any C memory allocation)
-you must remember to free the memory when you're done with it by calling `C.free`.
-
-The call to `C.CString` returns a pointer to the start of the char array,
-so before the function exits we convert it to an [`unsafe.Pointer`](https://golang.org/pkg/unsafe/#Pointer)
-and release the memory allocation with `C.free`.
-A common idiom in cgo programs is to [`defer`](https://golang.org/doc/articles/defer_panic_recover.html)
-the free immediately after allocating (especially when the code that follows
-is more complex than a single function call),
-as in this rewrite of `Print`:
-
-	func Print(s string) {
-	    cs := C.CString(s)
-	    defer C.free(unsafe.Pointer(cs))
-	    C.fputs(cs, (*C.FILE)(C.stdout))
-	}
-
-## Building cgo packages
-
-To build cgo packages, just use [`go build`](https://golang.org/cmd/go/#hdr-Compile_packages_and_dependencies)
-or [`go install`](https://golang.org/cmd/go/#hdr-Compile_and_install_packages_and_dependencies) as usual.
-The go tool recognizes the special `"C"` import and automatically uses cgo for those files.
-
-## More cgo resources
-
-The [cgo command](https://golang.org/cmd/cgo/) documentation has more
-detail about the C pseudo-package and the build process.
-The [cgo examples](https://golang.org/misc/cgo/) in the Go tree demonstrate
-more advanced concepts.
-
-Finally, if you're curious as to how all this works internally,
-take a look at the introductory comment of the runtime package's [cgocall.go](https://golang.org/src/runtime/cgocall.go).
diff --git a/_content/codelab-share.article b/_content/codelab-share.article
deleted file mode 100644
index 03fbab6..0000000
--- a/_content/codelab-share.article
+++ /dev/null
@@ -1,107 +0,0 @@
-# Share Memory By Communicating
-13 Jul 2010
-Tags: concurrency, technical
-Summary: A preview of the new Go codelab, Share Memory by Communicating.
-OldURL: /share-memory-by-communicating
-
-Andrew Gerrand
-
-##
-
-Traditional threading models (commonly used when writing Java,
-C++, and Python programs, for example) require the programmer to communicate
-between threads using shared memory.
-Typically, shared data structures are protected by locks,
-and threads will contend over those locks to access the data.
-In some cases, this is made easier by the use of thread-safe data structures
-such as Python's Queue.
-
-Go's concurrency primitives - goroutines and channels - provide an elegant
-and distinct means of structuring concurrent software.
-(These concepts have an [interesting history](https://swtch.com/~rsc/thread/) that begins with C.
-A. R. Hoare's [Communicating Sequential Processes](http://www.usingcsp.com/).)
-Instead of explicitly using locks to mediate access to shared data,
-Go encourages the use of channels to pass references to data between goroutines.
-This approach ensures that only one goroutine has access to the data at a given time.
-The concept is summarized in the document [Effective Go](https://golang.org/doc/effective_go.html)
-(a must-read for any Go programmer):
-
-_Do not communicate by sharing memory; instead, share memory by communicating._
-
-Consider a program that polls a list of URLs.
-In a traditional threading environment, one might structure its data like so:
-
-	type Resource struct {
-	    url        string
-	    polling    bool
-	    lastPolled int64
-	}
-
-	type Resources struct {
-	    data []*Resource
-	    lock *sync.Mutex
-	}
-
-And then a Poller function (many of which would run in separate threads) might look something like this:
-
-	func Poller(res *Resources) {
-	    for {
-	        // get the least recently-polled Resource
-	        // and mark it as being polled
-	        res.lock.Lock()
-	        var r *Resource
-	        for _, v := range res.data {
-	            if v.polling {
-	                continue
-	            }
-	            if r == nil || v.lastPolled < r.lastPolled {
-	                r = v
-	            }
-	        }
-	        if r != nil {
-	            r.polling = true
-	        }
-	        res.lock.Unlock()
-	        if r == nil {
-	            continue
-	        }
-
-	        // poll the URL
-
-	        // update the Resource's polling and lastPolled
-	        res.lock.Lock()
-	        r.polling = false
-	        r.lastPolled = time.Nanoseconds()
-	        res.lock.Unlock()
-	    }
-	}
-
-This function is about a page long, and requires more detail to make it complete.
-It doesn't even include the URL polling logic (which,
-itself, would only be a few lines), nor will it gracefully handle exhausting
-the pool of Resources.
-
-Let's take a look at the same functionality implemented using Go idiom.
-In this example, Poller is a function that receives Resources to be polled
-from an input channel,
-and sends them to an output channel when they're done.
-
-	type Resource string
-
-	func Poller(in, out chan *Resource) {
-	    for r := range in {
-	        // poll the URL
-
-	        // send the processed Resource to out
-	        out <- r
-	    }
-	}
-
-The delicate logic from the previous example is conspicuously absent,
-and our Resource data structure no longer contains bookkeeping data.
-In fact, all that's left are the important parts.
-This should give you an inkling as to the power of these simple language features.
-
-There are many omissions from the above code snippets.
-For a walkthrough of a complete, idiomatic Go program that uses these ideas,
-see the Codewalk [_Share Memory By Communicating_](https://golang.org/doc/codewalk/sharemem/).
diff --git a/_content/concurrency-timeouts.article b/_content/concurrency-timeouts.article
deleted file mode 100644
index 8237e7d..0000000
--- a/_content/concurrency-timeouts.article
+++ /dev/null
@@ -1,84 +0,0 @@
-# Go Concurrency Patterns: Timing out, moving on
-23 Sep 2010
-Tags: concurrency, technical
-Summary: How to implement timeouts using Go's concurrency support.
-OldURL: /go-concurrency-patterns-timing-out-and
-
-Andrew Gerrand
-
-##
-
-Concurrent programming has its own idioms.
-A good example is timeouts. Although Go's channels do not support them directly,
-they are easy to implement.
-Say we want to receive from the channel `ch`,
-but want to wait at most one second for the value to arrive.
-We would start by creating a signalling channel and launching a goroutine
-that sleeps before sending on the channel:
-
-	timeout := make(chan bool, 1)
-	go func() {
-	    time.Sleep(1 * time.Second)
-	    timeout <- true
-	}()
-
-We can then use a `select` statement to receive from either `ch` or `timeout`.
-If nothing arrives on `ch` after one second,
-the timeout case is selected and the attempt to read from ch is abandoned.
-
-	select {
-	case <-ch:
-	    // a read from ch has occurred
-	case <-timeout:
-	    // the read from ch has timed out
-	}
-
-The `timeout` channel is buffered with space for 1 value,
-allowing the timeout goroutine to send to the channel and then exit.
-The goroutine doesn't know (or care) whether the value is received.
-This means the goroutine won't hang around forever if the `ch` receive happens
-before the timeout is reached.
-The `timeout` channel will eventually be deallocated by the garbage collector.
-
-(In this example we used `time.Sleep` to demonstrate the mechanics of goroutines and channels.
-In real programs you should use ` [time.After](https://golang.org/pkg/time/#After)`,
-a function that returns a channel and sends on that channel after the specified duration.)
-
-Let's look at another variation of this pattern.
-In this example we have a program that reads from multiple replicated databases simultaneously.
-The program needs only one of the answers,
-and it should accept the answer that arrives first.
-
-The function `Query` takes a slice of database connections and a `query` string.
-It queries each of the databases in parallel and returns the first response it receives:
-
-	func Query(conns []Conn, query string) Result {
-	    ch := make(chan Result)
-	    for _, conn := range conns {
-	        go func(c Conn) {
-	            select {
-	            case ch <- c.DoQuery(query):
-	            default:
-	            }
-	        }(conn)
-	    }
-	    return <-ch
-	}
-
-In this example, the closure does a non-blocking send,
-which it achieves by using the send operation in `select` statement with a `default` case.
-If the send cannot go through immediately the default case will be selected.
-Making the send non-blocking guarantees that none of the goroutines launched
-in the loop will hang around.
-However, if the result arrives before the main function has made it to the receive,
-the send could fail since no one is ready.
-
-This problem is a textbook example of what is known as a [race condition](https://en.wikipedia.org/wiki/Race_condition),
-but the fix is trivial.
-We just make sure to buffer the channel `ch` (by adding the buffer length
-as the second argument to [make](https://golang.org/pkg/builtin/#make)),
-guaranteeing that the first send has a place to put the value.
-This ensures the send will always succeed,
-and the first value to arrive will be retrieved regardless of the order of execution.
-
-These two examples demonstrate the simplicity with which Go can express complex interactions between goroutines.
diff --git a/_content/conduct-2018.article b/_content/conduct-2018.article
deleted file mode 100644
index 2fb5ffa..0000000
--- a/_content/conduct-2018.article
+++ /dev/null
@@ -1,96 +0,0 @@
-# Updating the Go Code of Conduct
-23 May 2018
-Tags: conduct
-Summary: Revising the Go Code of Conduct.
-
-Steve Francia
-
-##
-
-In November 2015, we introduced the Go Code of Conduct.
-It was developed in a collaboration between
-the Go team members at Google and the Go community.
-I was fortunate to be one of the community members
-invited to participate in both drafting and then enforcing
-the Go Code of Conduct.
-Since then, we have learned two lessons about
-limitations in our code of conduct that restricted us from
-being able to cultivate the safe culture
-essential to Go’s success.
-
-The first lesson we learned is that toxic behaviors by
-project participants in non-project spaces can have a
-negative impact on the project affecting the security and safety of
-community members. There were a few reported
-incidents where actions took place outside of project spaces
-but the impact was felt inside our community. The specific
-language in our code of conduct restricted our ability to
-respond only to actions happening “in the official
-forums operated by the Go project”. We needed a way
-to protect our community members wherever they are.
-
-The second lesson we learned is that the demands required
-to enforce the code
-of conduct place too heavy of a burden on volunteers.
-The initial version of the code of conduct presented the
-working group as disciplinarians. It was soon clear
-that this was too much, so in early 2017 [we changed the group’s role](https://golang.org/cl/37014)
-to that of advisors and mediators.
-Still, working group community members
-reported feeling overwhelmed, untrained, and vulnerable.
-This well-intentioned shift left us without an enforcement mechanism
-without solving the issue with overburdened volunteers.
-
-In mid-2017, I represented the Go project in a meeting with
-Google’s Open Source Programs Office and Open Source Strategy Team
-to address the shortcomings in our respective
-codes of conduct, particularly in their enforcement.
-It quickly became clear that our problems had a lot in common,
-and that working together on a single code of conduct for all
-of Google’s open source projects made sense.
-We started with the text from the
-Contributor Covenant Code of Conduct v1.4
-and then made changes, influenced by
-our experiences in Go community and our collective experiences in open source.
-This resulted in the Google [code of conduct template](https://opensource.google.com/docs/releasing/template/CODE_OF_CONDUCT/).
-
-Today the Go project is adopting this new code of conduct,
-and we’ve updated [golang.org/conduct](https://golang.org/conduct).
-This revised code of conduct retains much of the intent, structure and
-language of the original Go code of conduct while making two critical
-changes that address the shortcomings identified above.
-
-First, [the new code of conduct makes clear](https://golang.org/conduct/#scope) that people who
-participate in any kind of harassment or inappropriate behavior,
-even outside our project spaces, are not welcome in our project spaces.
-This means that the Code of Conduct applies outside
-the project spaces when there is a reasonable belief that
-an individual’s behavior may have a negative
-impact on the project or its community.
-
-Second, in the place of the working group,
-[the new code of conduct introduces a single Project Steward](https://golang.org/conduct/#reporting)
-who will have explicit training and support for this role.
-The Project Steward will receive reported violations
-and then work with a committee,
-consisting of representatives from the Open Source Programs Office
-and the Google Open Source Strategy team,
-to find a resolution.
-
-Our first Project Steward will be [Cassandra Salisbury](https://twitter.com/cassandraoid).
-She is well known to the Go community as a member of Go Bridge,
-an organizer of many Go meetups and conferences,
-and as a lead of the Go community outreach working group.
-Cassandra now works on the Go team at Google
-with a focus on advocating for and supporting the Go community.
-
-We are grateful to everyone who served on the original Code of
-Conduct Working Group. Your efforts were essential in creating an
-inclusive and safe community.
-
-We believe the code of conduct has contributed to the
-Go project becoming more welcoming now than it was in 2015,
-and we should all be proud of that.
-
-We hope that the new code of conduct will help protect our community
-members even more effectively.
diff --git a/_content/constants.article b/_content/constants.article
deleted file mode 100644
index 51308d6..0000000
--- a/_content/constants.article
+++ /dev/null
@@ -1,515 +0,0 @@
-# Constants
-25 Aug 2014
-Tags: constants
-Summary: An introduction to constants in Go.
-
-Rob Pike
-
-## Introduction
-
-Go is a statically typed language that does not permit operations that mix numeric types.
-You can't add a `float64` to an `int`, or even an `int32` to an `int`.
-Yet it is legal to write `1e6*time.Second` or `math.Exp(1)` or even `1<<('\t'+2.0)`.
-In Go, constants, unlike variables, behave pretty much like regular numbers.
-This post explains why that is and what it means.
-
-## Background: C
-
-In the early days of thinking about Go, we talked about a number of problems
-caused by the way C and its descendants let you mix and match numeric types.
-Many mysterious bugs, crashes, and portability problems are caused by expressions
-that combine integers of different sizes and "signedness".
-Although to a seasoned C programmer the result of a calculation like
-
-	unsigned int u = 1e9;
-	long signed int i = -1;
-	... i + u ...
-
-may be familiar, it isn't _a priori_ obvious.
-How big is the result?
-What is its value?
-Is it signed or unsigned?
-
-Nasty bugs lurk here.
-
-C has a set of rules called "the usual arithmetic conversions" and it is
-an indicator of their subtlety that they have changed over the years (introducing
-yet more bugs, retroactively).
-
-When designing Go, we decided to avoid this minefield by mandating that there is _no_ mixing of numeric types.
-If you want to add `i` and `u`, you must be explicit about what you want the result to be.
-Given
-
-	var u uint
-	var i int
-
-you can write either `uint(i)+u` or `i+int(u)`,
-with both the meaning and type of the addition clearly expressed,
-but unlike in C you cannot write `i+u`.
-You can't even mix `int` and `int32`, even when `int` is a 32-bit type.
-
-This strictness eliminates a common cause of bugs and other failures.
-It is a vital property of Go.
-But it has a cost: it sometimes requires programmers to decorate their code
-with clumsy numeric conversions to express their meaning clearly.
-
-And what about constants?
-Given the declarations above, what would make it legal to write `i` `=` `0` or `u` `=` `0`?
-What is the _type_ of `0`?
-It would be unreasonable to require constants to have type conversions in simple contexts such as `i` `=` `int(0)`.
-
-We soon realized the answer lay in making numeric constants work differently
-from how they behave in other C-like languages.
-After much thinking and experimentation, we came up with a design that we
-believe feels right almost always,
-freeing the programmer from converting constants all the time yet being
-able to write things like `math.Sqrt(2)` without being chided by the compiler.
-
-In short, constants in Go just work, most of the time anyway.
-Let's see how that happens.
-
-## Terminology
-
-First, a quick definition.
-In Go, `const` is a keyword introducing a name for a scalar value such as `2` or `3.14159` or `"scrumptious"`.
-Such values, named or otherwise, are called _constants_ in Go.
-Constants can also be created by expressions built from constants,
-such as `2+3` or `2+3i` or `math.Pi/2` or `("go"+"pher")`.
-
-Some languages don't have constants, and others have a more general definition
-of constant or application of the word `const`.
-In C and C++, for instance, `const` is a type qualifier that can codify
-more intricate properties of more intricate values.
-
-But in Go, a constant is just a simple, unchanging value, and from here on we're talking only about Go.
-
-## String constants
-
-There are many kinds of numeric constants—integers,
-floats, runes, signed, unsigned, imaginary,
-complex—so let's start with a simpler form of constant: strings.
-String constants are easy to understand and provide a smaller space in which
-to explore the type issues of constants in Go.
-
-A string constant encloses some text between double quotes.
-(Go also has raw string literals, enclosed by backquotes <code>``</code>,
-but for the purpose of this discussion they have all the same properties.)
-Here is a string constant:
-
-	"Hello, 世界"
-
-(For much more detail about the representation and interpretation of strings,
-see [this blog post](https://blog.golang.org/strings).)
-
-What type does this string constant have?
-The obvious answer is `string`, but that is _wrong_.
-
-This is an _untyped string constant_, which is to say it is a constant textual
-value that does not yet have a fixed type.
-Yes, it's a string, but it's not a Go value of type `string`.
-It remains an untyped string constant even when given a name:
-
-	const hello = "Hello, 世界"
-
-After this declaration, `hello` is also an untyped string constant.
-An untyped constant is just a value, one not yet given a defined type that
-would force it to obey the strict rules that prevent combining differently typed values.
-
-It is this notion of an _untyped_ constant that makes it possible for us to use constants in Go with great freedom.
-
-So what, then, is a _typed_ string constant?
-It's one that's been given a type, like this:
-
-	const typedHello string = "Hello, 世界"
-
-Notice that the declaration of `typedHello` has an explicit `string` type before the equals sign.
-This means that `typedHello` has Go type `string`, and cannot be assigned to a Go variable of a different type.
-That is to say, this code works:
-
-.play -edit constants/string1.go /START/,/STOP/
-
-but this does not:
-
-.play -edit constants/string2.go /START/,/STOP/
-
-The variable `m` has type `MyString` and cannot be assigned a value of a different type.
-It can only be assigned values of type `MyString`, like this:
-
-.play -edit constants/string3.go /START/,/STOP/
-
-or by forcing the issue with a conversion, like this:
-
-.play -edit constants/string4.go /START/,/STOP/
-
-Returning to our _untyped_ string constant,
-it has the helpful property that, since it has no type,
-assigning it to a typed variable does not cause a type error.
-That is, we can write
-
-	m = "Hello, 世界"
-
-or
-
-	m = hello
-
-because, unlike the typed constants `typedHello` and `myStringHello`,
-the untyped constants `"Hello, 世界"` and `hello` _have no type_.
-Assigning them to a variable of any type compatible with strings works without error.
-
-These untyped string constants are strings,
-of course, so they can only be used where a string is allowed,
-but they do not have _type_ `string`.
-
-## Default type
-
-As a Go programmer, you have certainly seen many declarations like
-
-	str := "Hello, 世界"
-
-and by now you might be asking, "if the constant is untyped, how does `str` get a type in this variable declaration?"
-The answer is that an untyped constant has a default type,
-an implicit type that it transfers to a value if a type is needed where none is provided.
-For untyped string constants, that default type is obviously `string`, so
-
-	str := "Hello, 世界"
-
-or
-
-	var str = "Hello, 世界"
-
-means exactly the same as
-
-	var str string = "Hello, 世界"
-
-One way to think about untyped constants is that they live in a kind of
-ideal space of values,
-a space less restrictive than Go's full type system.
-But to do anything with them, we need to assign them to variables,
-and when that happens the _variable_ (not the constant itself) needs a type,
-and the constant can tell the variable what type it should have.
-In this example, `str` becomes a value of type `string` because the untyped
-string constant gives the declaration its default type, `string`.
-
-In such a declaration, a variable is declared with a type and initial value.
-Sometimes when we use a constant, however, the destination of the value is not so clear.
-For instance consider this statement:
-
-.play -edit constants/default1.go /START/,/STOP/
-
-The signature of `fmt.Printf` is
-
-	func Printf(format string, a ...interface{}) (n int, err error)
-
-which is to say its arguments (after the format string) are interface values.
-What happens when `fmt.Printf` is called with an untyped constant is that an interface value is created
-to pass as an argument, and the concrete type stored for that argument is the default type of the constant.
-This process is analogous to what we saw earlier when declaring an initialized value using an untyped string constant.
-
-You can see the result in this example, which uses the format `%v` to print
-the value and `%T` to print the type of the value being passed to `fmt.Printf`:
-
-.play -edit constants/default2.go /START/,/STOP/
-
-If the constant has a type, that goes into the interface, as this example shows:
-
-.play -edit constants/default3.go /START/,/STOP/
-
-(For more information about how interface values work,
-see the first sections of [this blog post](https://blog.golang.org/laws-of-reflection).)
-
-In summary, a typed constant obeys all the rules of typed values in Go.
-On the other hand, an untyped constant does not carry a Go type in the same
-way and can be mixed and matched more freely.
-It does, however, have a default type that is exposed when, and only when, no other type information is available.
-
-## Default type determined by syntax
-
-The default type of an untyped constant is determined by its syntax.
-For string constants, the only possible implicit type is `string`.
-For [numeric constants](https://golang.org/ref/spec#Numeric_types), the implicit type has more variety.
-Integer constants default to `int`, floating-point constants `float64`,
-rune constants to `rune` (an alias for `int32`),
-and imaginary constants to `complex128`.
-Here's our canonical print statement used repeatedly to show the default types in action:
-
-.play -edit constants/syntax.go /START/,/STOP/
-
-(Exercise: Explain the result for `'x'`.)
-
-## Booleans
-
-Everything we said about untyped string constants can be said for untyped boolean constants.
-The values `true` and `false` are untyped boolean constants that can be assigned to any boolean variable,
-but once given a type, boolean variables cannot be mixed:
-
-.play -edit constants/bool.go /START/,/STOP/
-
-Run the example and see what happens, then comment out the "Bad" line and run it again.
-The pattern here follows exactly that of string constants.
-
-## Floats
-
-Floating-point constants are just like boolean constants in most respects.
-Our standard example works as expected in translation:
-
-.play -edit constants/float1.go /START/,/STOP/
-
-One wrinkle is that there are _two_ floating-point types in Go: `float32` and `float64`.
-The default type for a floating-point constant is `float64`, although an untyped floating-point
-constant can be assigned to a `float32` value just fine:
-
-.play -edit constants/float2.go /START/,/STOP/
-
-Floating-point values are a good place to introduce the concept of overflow, or the range of values.
-
-Numeric constants live in an arbitrary-precision numeric space; they are just regular numbers.
-But when they are assigned to a variable the value must be able to fit in the destination.
-We can declare a constant with a very large value:
-
-.code constants/float3.go /Huge/
-
-—that's just a number, after all—but we can't assign it or even print it. This statement won't even compile:
-
-.play -edit constants/float3.go /Println/
-
-The error is, "constant 1.00000e+1000 overflows float64", which is true.
-But `Huge` might be useful: we can use it in expressions with other constants
-and use the value of those expressions if the result
-can be represented in the range of a `float64`.
-The statement,
-
-.play -edit constants/float4.go /Println/
-
-prints `10`, as one would expect.
-
-In a related way, floating-point constants may have very high precision,
-so that arithmetic involving them is more accurate.
-The constants defined in the [math](https://golang.org/pkg/math) package are given with many more digits than are
-available in a `float64`. Here is the definition of `math.Pi`:
-
-	Pi	= 3.14159265358979323846264338327950288419716939937510582097494459
-
-When that value is assigned to a variable,
-some of the precision will be lost;
-the assignment will create the `float64` (or `float32`)
-value closest to the high-precision value. This snippet
-
-.play -edit constants/float5.go /START/,/STOP/
-
-prints `3.141592653589793`.
-
-Having so many digits available means that calculations like `Pi/2` or other
-more intricate evaluations can carry more precision
-until the result is assigned, making calculations involving constants easier to write without losing precision.
-It also means that there is no occasion in which the floating-point corner cases like infinities,
-soft underflows, and `NaNs` arise in constant expressions.
-(Division by a constant zero is a compile-time error,
-and when everything is a number there's no such thing as "not a number".)
-
-## Complex numbers
-
-Complex constants behave a lot like floating-point constants.
-Here's a version of our now-familiar litany translated into complex numbers:
-
-.play -edit constants/complex1.go /START/,/STOP/
-
-The default type of a complex number is `complex128`, the larger-precision version composed of two `float64` values.
-
-For clarity in our example, we wrote out the full expression `(0.0+1.0i)`,
-but this value can be shortened to `0.0+1.0i`,
-`1.0i` or even `1i`.
-
-Let's play a trick.
-We know that in Go, a numeric constant is just a number.
-What if that number is a complex number with no imaginary part, that is, a real?
-Here's one:
-
-.code constants/complex2.go /const Two/
-
-That's an untyped complex constant.
-Even though it has no imaginary part, the _syntax_ of the expression defines it to have default type `complex128`.
-Therefore, if we use it to declare a variable, the default type will be `complex128`. The snippet
-
-.play -edit constants/complex2.go /START/,/STOP/
-
-prints `complex128:` `(2+0i)`.
-But numerically, `Two` can be stored in a scalar floating-point number,
-a `float64` or `float32`, with no loss of information.
-Thus we can assign `Two` to a `float64`, either in an initialization or an assignment, without problems:
-
-.play -edit constants/complex3.go /START/,/STOP/
-
-The output is `2` `and` `2`.
-Even though `Two` is a complex constant, it can be assigned to scalar floating-point variables.
-This ability for a constant to "cross" types like this will prove useful.
-
-## Integers
-
-At last we come to integers.
-They have more moving parts—[many sizes, signed or unsigned, and more](https://golang.org/ref/spec#Numeric_types)—but
-they play by the same rules.
-For the last time, here is our familiar example, using just `int` this time:
-
-.play -edit constants/int1.go /START/,/STOP/
-
-The same example could be built for any of the integer types, which are:
-
-	int int8 int16 int32 int64
-	uint uint8 uint16 uint32 uint64
-	uintptr
-
-(plus the aliases `byte` for `uint8` and `rune` for `int32`).
-That's a lot, but the pattern in the way constants work should be familiar
-enough by now that you can see how things will play out.
-
-As mentioned above, integers come in a couple of forms and each form has
-its own default type:
-`int` for simple constants like `123` or `0xFF` or `-14`
-and `rune` for quoted characters like 'a', '世' or '\r'.
-
-No constant form has as its default type an unsigned integer type.
-However, the flexibility of untyped constants means we can initialize unsigned
-integer variables using simple constants as long as we are clear about the type.
-It's analogous to how we can initialize a `float64` using a complex number with zero imaginary part.
-Here are several different ways to initialize a `uint`;
-all are equivalent, but all must mention the type explicitly for the result to be unsigned.
-
-	var u uint = 17
-	var u = uint(17)
-	u := uint(17)
-
-Similarly to the range issue mentioned in the section on floating-point values,
-not all integer values can fit in all integer types.
-There are two problems that might arise: the value might be too large,
-or it might be a negative value being assigned to an unsigned integer type.
-For instance, `int8` has range -128 through 127,
-so constants outside of that range can never be assigned to a variable of type `int8`:
-
-.play -edit constants/int2.go /var/
-
-Similarly, `uint8`, also known as `byte`,
-has range 0 through 255, so a large or negative constant cannot be assigned to a `uint8`:
-
-.play -edit constants/int3.go /var/
-
-This type-checking can catch mistakes like this one:
-
-.play -edit constants/int4.go /START/,/STOP/
-
-If the compiler complains about your use of a constant, it's likely a real bug like this.
-
-## An exercise: The largest unsigned int
-
-Here is an informative little exercise.
-How do we express a constant representing the largest value that fits in a `uint`?
-If we were talking about `uint32` rather than `uint`, we could write
-
-	const MaxUint32 = 1<<32 - 1
-
-but we want `uint`, not `uint32`.
-The `int` and `uint` types have equal unspecified numbers of bits, either 32 or 64.
-Since the number of bits available depends on the architecture, we can't just write down a single value.
-
-Fans of [two's-complement arithmetic](http://en.wikipedia.org/wiki/Two's_complement),
-which Go's integers are defined to use, know that the representation of `-1` has all its bits set to 1,
-so the bit pattern of `-1` is internally the same as that of the
-largest unsigned integer.
-We therefore might think we could write
-
-.play -edit constants/exercise1.go /const/
-
-but that is illegal because -1 cannot be represented by an unsigned variable;
-`-1` is not in the range of unsigned values.
-A conversion won't help either, for the same reason:
-
-.play -edit constants/exercise2.go /const/
-
-Even though at run-time a value of -1 can be converted to an unsigned integer, the rules
-for constant [conversions](https://golang.org/ref/spec#Conversions) forbid this kind of coercion at compile time.
-That is to say, this works:
-
-.play -edit constants/exercise3.go /START/,/STOP/
-
-but only because `v` is a variable; if we made `v` a constant,
-even an untyped constant, we'd be back in forbidden territory:
-
-.play -edit constants/exercise4.go /START/,/STOP/
-
-We return to our previous approach, but instead of `-1` we try `^0`,
-the bitwise negation of an arbitrary number of zero bits.
-But that fails too, for a similar reason:
-In the space of numeric values,
-`^0` represents an infinite number of ones, so we lose information if we assign that to any fixed-size integer:
-
-.play -edit constants/exercise5.go /const/
-
-How then do we represent the largest unsigned integer as a constant?
-
-The key is to constrain the operation to the number of bits in a `uint` and avoiding
-values, such as negative numbers, that are not representable in a `uint`.
-The simplest `uint` value is the typed constant `uint(0)`.
-If `uints` have 32 or 64 bits, `uint(0)` has 32 or 64 zero bits accordingly.
-If we invert each of those bits, we'll get the correct number of one bits, which is the largest `uint` value.
-
-Therefore we don't flip the bits of the untyped constant `0`, we flip the bits of the typed constant `uint(0)`.
-Here, then, is our constant:
-
-.play -edit constants/exercise6.go /START/,/STOP/
-
-Whatever the number of bits it takes to represent a `uint` in the current execution environment
-(on the [playground](https://blog.golang.org/playground), it's 32),
-this constant correctly represents the largest value a variable of type `uint` can hold.
-
-If you understand the analysis that got us to this result,
-you understand all the important points about constants in Go.
-
-## Numbers
-
-The concept of untyped constants in Go means that all the numeric constants,
-whether integer, floating-point, complex,
-or even character values,
-live in a kind of unified space.
-It's when we bring them to the computational world of variables,
-assignments, and operations that the actual types matter.
-But as long as we stay in the world of numeric constants, we can mix and match values as we like.
-All these constants have numeric value 1:
-
-	1
-	1.000
-	1e3-99.0*10-9
-	'\x01'
-	'\u0001'
-	'b' - 'a'
-	1.0+3i-3.0i
-
-Therefore, although they have different implicit default types,
-written as untyped constants they can be assigned to a variable of any integer type:
-
-.play -edit constants/numbers1.go /START/,/STOP/
-
-The output from this snippet is: `1 1 1 1 1 (1+0i) 1`.
-
-You can even do nutty stuff like
-
-.play -edit constants/numbers2.go /START/,/STOP/
-
-which yields 145.5, which is pointless except to prove a point.
-
-But the real point of these rules is flexibility.
-That flexibility means that, despite the fact that in Go it is illegal in
-the same expression to mix floating-point and integer variables,
-or even `int` and `int32` variables, it is fine to write
-
-	sqrt2 := math.Sqrt(2)
-
-or
-
-	const millisecond = time.Second/1e3
-
-or
-
-	bigBufferWithHeader := make([]byte, 512+1e6)
-
-and have the results mean what you expect.
-
-Because in Go, numeric constants work as you expect: like numbers.
diff --git a/_content/constants/bool.go b/_content/constants/bool.go
deleted file mode 100644
index 7578d4a..0000000
--- a/_content/constants/bool.go
+++ /dev/null
@@ -1,18 +0,0 @@
-// +build OMIT
-
-package main
-
-import "fmt"
-
-func main() {
-	// START OMIT
-	type MyBool bool
-	const True = true
-	const TypedTrue bool = true
-	var mb MyBool
-	mb = true      // OK
-	mb = True      // OK
-	mb = TypedTrue // Bad
-	fmt.Println(mb)
-	// STOP OMIT
-}
diff --git a/_content/constants/complex1.go b/_content/constants/complex1.go
deleted file mode 100644
index ea45921..0000000
--- a/_content/constants/complex1.go
+++ /dev/null
@@ -1,18 +0,0 @@
-// +build OMIT
-
-package main
-
-import "fmt"
-
-func main() {
-	// START OMIT
-	type MyComplex128 complex128
-	const I = (0.0 + 1.0i)
-	const TypedI complex128 = (0.0 + 1.0i)
-	var mc MyComplex128
-	mc = (0.0 + 1.0i) // OK
-	mc = I            // OK
-	mc = TypedI       // Bad
-	fmt.Println(mc)
-	// STOP OMIT
-}
diff --git a/_content/constants/complex2.go b/_content/constants/complex2.go
deleted file mode 100644
index 5dd4f73..0000000
--- a/_content/constants/complex2.go
+++ /dev/null
@@ -1,13 +0,0 @@
-// +build OMIT
-
-package main
-
-import "fmt"
-
-func main() {
-	const Two = 2.0 + 0i
-	// START OMIT
-	s := Two
-	fmt.Printf("%T: %v\n", s, s)
-	// STOP OMIT
-}
diff --git a/_content/constants/complex3.go b/_content/constants/complex3.go
deleted file mode 100644
index 95e9e41..0000000
--- a/_content/constants/complex3.go
+++ /dev/null
@@ -1,15 +0,0 @@
-// +build OMIT
-
-package main
-
-import "fmt"
-
-func main() {
-	const Two = 2.0 + 0i
-	// START OMIT
-	var f float64
-	var g float64 = Two
-	f = Two
-	fmt.Println(f, "and", g)
-	// STOP OMIT
-}
diff --git a/_content/constants/default1.go b/_content/constants/default1.go
deleted file mode 100644
index 0f7909c..0000000
--- a/_content/constants/default1.go
+++ /dev/null
@@ -1,11 +0,0 @@
-// +build OMIT
-
-package main
-
-import "fmt"
-
-func main() {
-	// START OMIT
-	fmt.Printf("%s", "Hello, 世界")
-	// STOP OMIT
-}
diff --git a/_content/constants/default2.go b/_content/constants/default2.go
deleted file mode 100644
index 2183cf0..0000000
--- a/_content/constants/default2.go
+++ /dev/null
@@ -1,14 +0,0 @@
-// +build OMIT
-
-package main
-
-import "fmt"
-
-const hello = "Hello, 世界"
-
-func main() {
-	// START OMIT
-	fmt.Printf("%T: %v\n", "Hello, 世界", "Hello, 世界")
-	fmt.Printf("%T: %v\n", hello, hello)
-	// STOP OMIT
-}
diff --git a/_content/constants/default3.go b/_content/constants/default3.go
deleted file mode 100644
index 246ae45..0000000
--- a/_content/constants/default3.go
+++ /dev/null
@@ -1,15 +0,0 @@
-// +build OMIT
-
-package main
-
-import "fmt"
-
-type MyString string
-
-const myStringHello MyString = "Hello, 世界"
-
-func main() {
-	// START OMIT
-	fmt.Printf("%T: %v\n", myStringHello, myStringHello)
-	// STOP OMIT
-}
diff --git a/_content/constants/exercise1.go b/_content/constants/exercise1.go
deleted file mode 100644
index 881d1d0..0000000
--- a/_content/constants/exercise1.go
+++ /dev/null
@@ -1,9 +0,0 @@
-// +build OMIT
-
-package main
-
-func main() {
-	// START OMIT
-	const MaxUint uint = -1 // Error: negative value
-	// STOP OMIT
-}
diff --git a/_content/constants/exercise2.go b/_content/constants/exercise2.go
deleted file mode 100644
index db7d8c1..0000000
--- a/_content/constants/exercise2.go
+++ /dev/null
@@ -1,9 +0,0 @@
-// +build OMIT
-
-package main
-
-func main() {
-	// START OMIT
-	const MaxUint uint = uint(-1) // Error: negative value
-	// STOP OMIT
-}
diff --git a/_content/constants/exercise3.go b/_content/constants/exercise3.go
deleted file mode 100644
index dbe7595..0000000
--- a/_content/constants/exercise3.go
+++ /dev/null
@@ -1,12 +0,0 @@
-// +build OMIT
-
-package main
-
-func main() {
-	// START OMIT
-	var u uint
-	var v = -1
-	u = uint(v)
-	// STOP OMIT
-	_ = u
-}
diff --git a/_content/constants/exercise4.go b/_content/constants/exercise4.go
deleted file mode 100644
index 3acc664..0000000
--- a/_content/constants/exercise4.go
+++ /dev/null
@@ -1,12 +0,0 @@
-// +build OMIT
-
-package main
-
-func main() {
-	// START OMIT
-	var u uint
-	const v = -1
-	u = uint(v) // Error: negative value
-	// STOP OMIT
-	_ = u
-}
diff --git a/_content/constants/exercise5.go b/_content/constants/exercise5.go
deleted file mode 100644
index 2fca330..0000000
--- a/_content/constants/exercise5.go
+++ /dev/null
@@ -1,9 +0,0 @@
-// +build OMIT
-
-package main
-
-func main() {
-	// START OMIT
-	const MaxUint uint = ^0 // Error: overflow
-	// STOP OMIT
-}
diff --git a/_content/constants/exercise6.go b/_content/constants/exercise6.go
deleted file mode 100644
index ce6478c..0000000
--- a/_content/constants/exercise6.go
+++ /dev/null
@@ -1,12 +0,0 @@
-// +build OMIT
-
-package main
-
-import "fmt"
-
-func main() {
-	// START OMIT
-	const MaxUint = ^uint(0)
-	fmt.Printf("%x\n", MaxUint)
-	// STOP OMIT
-}
diff --git a/_content/constants/float1.go b/_content/constants/float1.go
deleted file mode 100644
index 96b3bb9..0000000
--- a/_content/constants/float1.go
+++ /dev/null
@@ -1,18 +0,0 @@
-// +build OMIT
-
-package main
-
-import "fmt"
-
-func main() {
-	// START OMIT
-	type MyFloat64 float64
-	const Zero = 0.0
-	const TypedZero float64 = 0.0
-	var mf MyFloat64
-	mf = 0.0       // OK
-	mf = Zero      // OK
-	mf = TypedZero // Bad
-	fmt.Println(mf)
-	// STOP OMIT
-}
diff --git a/_content/constants/float2.go b/_content/constants/float2.go
deleted file mode 100644
index f43feb6..0000000
--- a/_content/constants/float2.go
+++ /dev/null
@@ -1,17 +0,0 @@
-// +build OMIT
-
-package main
-
-import "fmt"
-
-func main() {
-	const Zero = 0.0
-	const TypedZero float64 = 0.0
-	// START OMIT
-	var f32 float32
-	f32 = 0.0
-	f32 = Zero      // OK: Zero is untyped
-	f32 = TypedZero // Bad: TypedZero is float64 not float32.
-	fmt.Println(f32)
-	// STOP OMIT
-}
diff --git a/_content/constants/float3.go b/_content/constants/float3.go
deleted file mode 100644
index d862acc..0000000
--- a/_content/constants/float3.go
+++ /dev/null
@@ -1,12 +0,0 @@
-// +build OMIT
-
-package main
-
-import "fmt"
-
-func main() {
-	const Huge = 1e1000
-	// START OMIT
-	fmt.Println(Huge)
-	// STOP OMIT
-}
diff --git a/_content/constants/float4.go b/_content/constants/float4.go
deleted file mode 100644
index 206d215..0000000
--- a/_content/constants/float4.go
+++ /dev/null
@@ -1,12 +0,0 @@
-// +build OMIT
-
-package main
-
-import "fmt"
-
-func main() {
-	const Huge = 1e1000
-	// START OMIT
-	fmt.Println(Huge / 1e999)
-	// STOP OMIT
-}
diff --git a/_content/constants/float5.go b/_content/constants/float5.go
deleted file mode 100644
index 2d62872..0000000
--- a/_content/constants/float5.go
+++ /dev/null
@@ -1,15 +0,0 @@
-// +build OMIT
-
-package main
-
-import (
-	"fmt"
-	"math"
-)
-
-func main() {
-	// START OMIT
-	pi := math.Pi
-	fmt.Println(pi)
-	// STOP OMIT
-}
diff --git a/_content/constants/int1.go b/_content/constants/int1.go
deleted file mode 100644
index 913ad78..0000000
--- a/_content/constants/int1.go
+++ /dev/null
@@ -1,18 +0,0 @@
-// +build OMIT
-
-package main
-
-import "fmt"
-
-func main() {
-	// START OMIT
-	type MyInt int
-	const Three = 3
-	const TypedThree int = 3
-	var mi MyInt
-	mi = 3          // OK
-	mi = Three      // OK
-	mi = TypedThree // Bad
-	fmt.Println(mi)
-	// STOP OMIT
-}
diff --git a/_content/constants/int2.go b/_content/constants/int2.go
deleted file mode 100644
index 0e974ef..0000000
--- a/_content/constants/int2.go
+++ /dev/null
@@ -1,10 +0,0 @@
-// +build OMIT
-
-package main
-
-func main() {
-	// START OMIT
-	var i8 int8 = 128 // Error: too large.
-	// STOP OMIT
-	_ = i8
-}
diff --git a/_content/constants/int3.go b/_content/constants/int3.go
deleted file mode 100644
index c2cec6e..0000000
--- a/_content/constants/int3.go
+++ /dev/null
@@ -1,10 +0,0 @@
-// +build OMIT
-
-package main
-
-func main() {
-	// START OMIT
-	var u8 uint8 = -1 // Error: negative value.
-	// STOP OMIT
-	_ = u8
-}
diff --git a/_content/constants/int4.go b/_content/constants/int4.go
deleted file mode 100644
index caff695..0000000
--- a/_content/constants/int4.go
+++ /dev/null
@@ -1,11 +0,0 @@
-// +build OMIT
-
-package main
-
-func main() {
-	// START OMIT
-	type Char byte
-	var c Char = '世' // Error: '世' has value 0x4e16, too large.
-	// STOP OMIT
-	_ = c
-}
diff --git a/_content/constants/numbers1.go b/_content/constants/numbers1.go
deleted file mode 100644
index ea35a51..0000000
--- a/_content/constants/numbers1.go
+++ /dev/null
@@ -1,19 +0,0 @@
-// +build OMIT
-
-package main
-
-import "fmt"
-
-func main() {
-	// START OMIT
-	var f float32 = 1
-	var i int = 1.000
-	var u uint32 = 1e3 - 99.0*10.0 - 9
-	var c float64 = '\x01'
-	var p uintptr = '\u0001'
-	var r complex64 = 'b' - 'a'
-	var b byte = 1.0 + 3i - 3.0i
-
-	fmt.Println(f, i, u, c, p, r, b)
-	// STOP OMIT
-}
diff --git a/_content/constants/numbers2.go b/_content/constants/numbers2.go
deleted file mode 100644
index 33b7de0..0000000
--- a/_content/constants/numbers2.go
+++ /dev/null
@@ -1,12 +0,0 @@
-// +build OMIT
-
-package main
-
-import "fmt"
-
-func main() {
-	// START OMIT
-	var f = 'a' * 1.5
-	fmt.Println(f)
-	// STOP OMIT
-}
diff --git a/_content/constants/string1.go b/_content/constants/string1.go
deleted file mode 100644
index 3b83851..0000000
--- a/_content/constants/string1.go
+++ /dev/null
@@ -1,15 +0,0 @@
-// +build OMIT
-
-package main
-
-import "fmt"
-
-const typedHello string = "Hello, 世界"
-
-func main() {
-	// START OMIT
-	var s string
-	s = typedHello
-	fmt.Println(s)
-	// STOP OMIT
-}
diff --git a/_content/constants/string2.go b/_content/constants/string2.go
deleted file mode 100644
index 362b484..0000000
--- a/_content/constants/string2.go
+++ /dev/null
@@ -1,16 +0,0 @@
-// +build OMIT
-
-package main
-
-import "fmt"
-
-const typedHello string = "Hello, 世界"
-
-func main() {
-	// START OMIT
-	type MyString string
-	var m MyString
-	m = typedHello // Type error
-	fmt.Println(m)
-	// STOP OMIT
-}
diff --git a/_content/constants/string3.go b/_content/constants/string3.go
deleted file mode 100644
index 72de35f..0000000
--- a/_content/constants/string3.go
+++ /dev/null
@@ -1,17 +0,0 @@
-// +build OMIT
-
-package main
-
-import "fmt"
-
-const typedHello string = "Hello, 世界"
-
-func main() {
-	type MyString string
-	var m MyString
-	// START OMIT
-	const myStringHello MyString = "Hello, 世界"
-	m = myStringHello // OK
-	fmt.Println(m)
-	// STOP OMIT
-}
diff --git a/_content/constants/string4.go b/_content/constants/string4.go
deleted file mode 100644
index 4c35f29..0000000
--- a/_content/constants/string4.go
+++ /dev/null
@@ -1,16 +0,0 @@
-// +build OMIT
-
-package main
-
-import "fmt"
-
-const typedHello string = "Hello, 世界"
-
-func main() {
-	type MyString string
-	var m MyString
-	// START OMIT
-	m = MyString(typedHello)
-	fmt.Println(m)
-	// STOP OMIT
-}
diff --git a/_content/constants/syntax.go b/_content/constants/syntax.go
deleted file mode 100644
index 16e7e64..0000000
--- a/_content/constants/syntax.go
+++ /dev/null
@@ -1,14 +0,0 @@
-// +build OMIT
-
-package main
-
-import "fmt"
-
-func main() {
-	// START OMIT
-	fmt.Printf("%T %v\n", 0, 0)
-	fmt.Printf("%T %v\n", 0.0, 0.0)
-	fmt.Printf("%T %v\n", 'x', 'x')
-	fmt.Printf("%T %v\n", 0i, 0i)
-	// STOP OMIT
-}
diff --git a/_content/context-and-structs.article b/_content/context-and-structs.article
deleted file mode 100644
index a4242ef..0000000
--- a/_content/context-and-structs.article
+++ /dev/null
@@ -1,142 +0,0 @@
-# Contexts and structs
-24 Feb 2021
-Tags: context, cancelation, cancellation
-
-Jean de Klerk, Matt T. Proud
-
-## Introduction
-
-In many Go APIs, especially modern ones, the first argument to functions and methods is often [`context.Context`](https://golang.org/pkg/context/). Context provides a means of transmitting deadlines, caller cancellations, and other request-scoped values across API boundaries and between processes. It is often used when a library interacts — directly or transitively — with remote servers, such as databases, APIs, and the like.
-
-The [documentation for context](https://golang.org/pkg/context/) states:
-
-> Contexts should not be stored inside a struct type, but instead passed to each function that needs it.
-
-This article expands on that advice with reasons and examples describing why it's important to pass Context rather than store it in another type. It also highlights a rare case where storing Context in a struct type may make sense, and how to do so safely.
-
-## Prefer contexts passed as arguments
-
-To understand the advice to not store context in structs, let's consider the preferred context-as-argument approach:
-
-```
-// Worker fetches and adds works to a remote work orchestration server.
-type Worker struct { /* … */ }
-
-type Work struct { /* … */ }
-
-func New() *Worker {
-  return &Worker{}
-}
-
-func (w *Worker) Fetch(ctx context.Context) (*Work, error) {
-  _ = ctx // A per-call ctx is used for cancellation, deadlines, and metadata.
-}
-
-func (w *Worker) Process(ctx context.Context, work *Work) error {
-  _ = ctx // A per-call ctx is used for cancellation, deadlines, and metadata.
-}
-```
-
-Here, the `(*Worker).Fetch` and `(*Worker).Process` methods both accept a context directly. With this pass-as-argument design, users can set per-call deadlines, cancellation, and metadata. And, it's clear how the `context.Context` passed to each method will be used: there's no expectation that a `context.Context` passed to one method will be used by any other method. This is because the context is scoped to as small an operation as it needs to be, which greatly increases the utility and clarity of `context` in this package.
-
-## Storing context in structs leads to confusion
-
-Let's inspect again the `Worker` example above with the disfavored context-in-struct approach. The problem with it is that when you store the context in a struct, you obscure lifetime to the callers, or worse intermingle two scopes together in unpredictable ways:
-
-```
-type Worker struct {
-  ctx context.Context
-}
-
-func New(ctx context.Context) *Worker {
-  return &Worker{ctx: ctx}
-}
-
-func (w *Worker) Fetch() (*Work, error) {
-  _ = w.ctx // A shared w.ctx is used for cancellation, deadlines, and metadata.
-}
-
-func (w *Worker) Process(work *Work) error {
-  _ = w.ctx // A shared w.ctx is used for cancellation, deadlines, and metadata.
-}
-```
-
-The `(*Worker).Fetch` and `(*Worker).Process` method both use a context stored in Worker. This prevents the callers of Fetch and Process (which may themselves have different contexts) from specifying a deadline, requesting cancellation, and attaching metadata on a per-call basis. For example: the user is unable to provide a deadline just for `(*Worker).Fetch`, or cancel just the `(*Worker).Process` call. The caller's lifetime is intermingled with a shared context, and the context is scoped to the lifetime where the `Worker` is created.
-
-The API is also much more confusing to users compared to the pass-as-argument approach. Users might ask themselves:
-
-- Since `New` takes a `context.Context`, is the constructor doing work that needs cancelation or deadlines?
-- Does the `context.Context` passed in to `New` apply to work in `(*Worker).Fetch` and `(*Worker).Process`? Neither? One but not the other?
-
-The API would need a good deal of documentation to explicitly tell the user exactly what the `context.Context` is used for. The user might also have to read code rather than being able to rely on the structure of the API conveys.
-
-And, finally, it can be quite dangerous to design a production-grade server whose requests don't each have a context and thus can't adequately honor cancellation. Without the ability to set per-call deadlines, [your process could backlog](https://sre.google/sre-book/handling-overload/) and exhaust its resources (like memory)!
-
-## Exception to the rule: preserving backwards compatibility
-
-When Go 1.7 — which [introduced context.Context](https://golang.org/doc/go1.7) — was released, a large number of APIs had to add context support in backwards compatible ways. For example, [`net/http`'s `Client` methods](https://golang.org/pkg/net/http/), like `Get` and `Do`, were excellent candidates for context. Each external request sent with these methods would benefit from having the deadline, cancellation, and metadata support that came with `context.Context`.
-
-There are two approaches for adding support for `context.Context` in backwards compatible ways: including a context in a struct, as we'll see in a moment, and duplicating functions, with duplicates accepting `context.Context` and having `Context` as their function name suffix. The duplicate approach should be preferred over the context-in-struct, and is further discussed in [Keeping your modules compatible](https://blog.golang.org/module-compatibility). However, in some cases it's impractical: for example, if your API exposes a large number of functions, then duplicating them all might be infeasible.
-
-The `net/http` package chose the context-in-struct approach, which provides a useful case study. Let's look at `net/http`'s `Do`. Prior to the introduction of `context.Context`, `Do` was defined as follows:
-
-```
-// Do sends an HTTP request and returns an HTTP response [...]
-func (c *Client) Do(req *Request) (*Response, error)
-```
-
-After Go 1.7, `Do` might have looked like the following, if not for the fact that it would break backwards compatibility:
-
-```
-// Do sends an HTTP request and returns an HTTP response [...]
-func (c *Client) Do(ctx context.Context, req *Request) (*Response, error)
-```
-
-But, preserving the backwards compatibility and adhering to the [Go 1 promise of compatibility](https://golang.org/doc/go1compat) is crucial for the standard library. So, instead, the maintainers chose to add a `context.Context` on the `http.Request` struct in order to allow support `context.Context` without breaking backwards compatibility:
-
-```
-// A Request represents an HTTP request received by a server or to be sent by a client.
-// ...
-type Request struct {
-  ctx context.Context
-
-  // ...
-}
-
-// NewRequestWithContext returns a new Request given a method, URL, and optional
-// body.
-// [...]
-// The given ctx is used for the lifetime of the Request.
-func NewRequestWithContext(ctx context.Context, method, url string, body io.Reader) (*Request, error) {
-  // Simplified for brevity of this article.
-  return &Request{
-    ctx: ctx,
-    // ...
-  }
-}
-
-// Do sends an HTTP request and returns an HTTP response [...]
-func (c *Client) Do(req *Request) (*Response, error)
-```
-
-When retrofitting your API to support context, it may make sense to add a `context.Context` to a struct, as above. However, remember to first consider duplicating your functions, which allows retrofitting `context.Context` in a backwards compatibility without sacrificing utility and comprehension. For example:
-
-```
-// Call uses context.Background internally; to specify the context, use
-// CallContext.
-func (c *Client) Call() error {
-  return c.CallContext(context.Background())
-}
-
-func (c *Client) CallContext(ctx context.Context) error {
-  // ...
-}
-```
-
-## Conclusion
-
-Context makes it easy to propagate important cross-library and cross-API information down a calling stack. But, it must be used consistently and clearly in order to remain comprehensible, easy to debug, and effective.
-
-When passed as the first argument in a method rather than stored in a struct type, users can take full advantage of its extensibility in order to build a powerful tree of cancelation, deadline, and metadata information through the call stack. And, best of all, its scope is clearly understood when it's passed in as an argument, leading to clear comprehension and debuggability up and down the stack.
-
-When designing an API with context, remember the advice: pass `context.Context` in as an argument; don't store it in structs.
diff --git a/_content/context.article b/_content/context.article
deleted file mode 100644
index 1d888f9..0000000
--- a/_content/context.article
+++ /dev/null
@@ -1,225 +0,0 @@
-# Go Concurrency Patterns: Context
-29 Jul 2014
-Tags: concurrency, cancelation, cancellation, context
-Summary: An introduction to the Go context package.
-
-Sameer Ajmani
-
-## Introduction
-
-In Go servers, each incoming request is handled in its own goroutine.
-Request handlers often start additional goroutines to access backends such as
-databases and RPC services.
-The set of goroutines working on a request typically needs access to
-request-specific values such as the identity of the end user, authorization
-tokens, and the request's deadline.
-When a request is canceled or times out, all the goroutines working on that
-request should exit quickly so the system can reclaim any resources they are
-using.
-
-At Google, we developed a `context` package that makes it easy to pass
-request-scoped values, cancelation signals, and deadlines across API boundaries
-to all the goroutines involved in handling a request.
-The package is publicly available as
-[context](https://golang.org/pkg/context).
-This article describes how to use the package and provides a complete working
-example.
-
-## Context
-
-The core of the `context` package is the `Context` type:
-
-.code context/interface.go /A Context/,/^}/
-
-(This description is condensed; the
-[godoc](https://golang.org/pkg/context) is authoritative.)
-
-The `Done` method returns a channel that acts as a cancelation signal to
-functions running on behalf of the `Context`: when the channel is closed, the
-functions should abandon their work and return.
-The `Err` method returns an error indicating why the `Context` was canceled.
-The [Pipelines and Cancelation](/pipelines) article discusses the `Done`
-channel idiom in more detail.
-
-A `Context` does _not_ have a `Cancel` method for the same reason the `Done`
-channel is receive-only: the function receiving a cancelation signal is usually
-not the one that sends the signal.
-In particular, when a parent operation starts goroutines for sub-operations,
-those sub-operations should not be able to cancel the parent.
-Instead, the `WithCancel` function (described below) provides a way to cancel a
-new `Context` value.
-
-A `Context` is safe for simultaneous use by multiple goroutines.
-Code can pass a single `Context` to any number of goroutines and cancel that
-`Context` to signal all of them.
-
-The `Deadline` method allows functions to determine whether they should start
-work at all; if too little time is left, it may not be worthwhile.
-Code may also use a deadline to set timeouts for I/O operations.
-
-`Value` allows a `Context` to carry request-scoped data.
-That data must be safe for simultaneous use by multiple goroutines.
-
-### Derived contexts
-
-The `context` package provides functions to _derive_ new `Context` values from
-existing ones.
-These values form a tree: when a `Context` is canceled, all `Contexts` derived
-from it are also canceled.
-
-`Background` is the root of any `Context` tree; it is never canceled:
-
-.code context/interface.go /Background returns/,/func Background/
-
-`WithCancel` and `WithTimeout` return derived `Context` values that can be
-canceled sooner than the parent `Context`.
-The `Context` associated with an incoming request is typically canceled when the
-request handler returns.
-`WithCancel` is also useful for canceling redundant requests when using multiple
-replicas.
-`WithTimeout` is useful for setting a deadline on requests to backend servers:
-
-.code context/interface.go /WithCancel/,/func WithTimeout/
-
-`WithValue` provides a way to associate request-scoped values with a `Context`:
-
-.code context/interface.go /WithValue/,/func WithValue/
-
-The best way to see how to use the `context` package is through a worked
-example.
-
-## Example: Google Web Search
-
-Our example is an HTTP server that handles URLs like
-`/search?q=golang&timeout=1s` by forwarding the query "golang" to the
-[Google Web Search API](https://developers.google.com/web-search/docs/) and
-rendering the results.
-The `timeout` parameter tells the server to cancel the request after that
-duration elapses.
-
-The code is split across three packages:
-
-  - [server](context/server/server.go) provides the `main` function and the handler for `/search`.
-  - [userip](context/userip/userip.go) provides functions for extracting a user IP address from a request and associating it with a `Context`.
-  - [google](context/google/google.go) provides the `Search` function for sending a query to Google.
-
-### The server program
-
-The [server](context/server/server.go) program handles requests like
-`/search?q=golang` by serving the first few Google search results for `golang`.
-It registers `handleSearch` to handle the `/search` endpoint.
-The handler creates an initial `Context` called `ctx` and arranges for it to be
-canceled when the handler returns.
-If the request includes the `timeout` URL parameter, the `Context` is canceled
-automatically when the timeout elapses:
-
-.code context/server/server.go /func handleSearch/,/defer cancel/
-
-The handler extracts the query from the request and extracts the client's IP
-address by calling on the `userip` package.
-The client's IP address is needed for backend requests, so `handleSearch`
-attaches it to `ctx`:
-
-.code context/server/server.go /Check the search query/,/userip.NewContext/
-
-The handler calls `google.Search` with `ctx` and the `query`:
-
-.code context/server/server.go /Run the Google search/,/elapsed/
-
-If the search succeeds, the handler renders the results:
-
-.code context/server/server.go /resultsTemplate/,/}$/
-
-### Package userip
-
-The [userip](context/userip/userip.go) package provides functions for
-extracting a user IP address from a request and associating it with a `Context`.
-A `Context` provides a key-value mapping, where the keys and values are both of
-type `interface{}`.
-Key types must support equality, and values must be safe for simultaneous use by
-multiple goroutines.
-Packages like `userip` hide the details of this mapping and provide
-strongly-typed access to a specific `Context` value.
-
-To avoid key collisions, `userip` defines an unexported type `key` and uses
-a value of this type as the context key:
-
-.code context/userip/userip.go /The key type/,/const userIPKey/
-
-`FromRequest` extracts a `userIP` value from an `http.Request`:
-
-.code context/userip/userip.go /func FromRequest/,/}/
-
-`NewContext` returns a new `Context` that carries a provided `userIP` value:
-
-.code context/userip/userip.go /func NewContext/,/}/
-
-`FromContext` extracts a `userIP` from a `Context`:
-
-.code context/userip/userip.go /func FromContext/,/}/
-
-### Package google
-
-The [google.Search](context/google/google.go) function makes an HTTP request
-to the [Google Web Search API](https://developers.google.com/web-search/docs/)
-and parses the JSON-encoded result.
-It accepts a `Context` parameter `ctx` and returns immediately if `ctx.Done` is
-closed while the request is in flight.
-
-The Google Web Search API request includes the search query and the user IP as
-query parameters:
-
-.code context/google/google.go /func Search/,/q.Encode/
-
-`Search` uses a helper function, `httpDo`, to issue the HTTP request and cancel
-it if `ctx.Done` is closed while the request or response is being processed.
-`Search` passes a closure to `httpDo` handle the HTTP response:
-
-.code context/google/google.go /var results/,/return results/
-
-The `httpDo` function runs the HTTP request and processes its response in a new
-goroutine.
-It cancels the request if `ctx.Done` is closed before the goroutine exits:
-
-.code context/google/google.go /func httpDo/,/^}/
-
-## Adapting code for Contexts
-
-Many server frameworks provide packages and types for carrying request-scoped
-values.
-We can define new implementations of the `Context` interface to bridge between
-code using existing frameworks and code that expects a `Context` parameter.
-
-For example, Gorilla's
-[github.com/gorilla/context](http://www.gorillatoolkit.org/pkg/context)
-package allows handlers to associate data with incoming requests by providing a
-mapping from HTTP requests to key-value pairs.
-In [gorilla.go](context/gorilla/gorilla.go), we provide a `Context`
-implementation whose `Value` method returns the values associated with a
-specific HTTP request in the Gorilla package.
-
-Other packages have provided cancelation support similar to `Context`.
-For example, [Tomb](https://godoc.org/gopkg.in/tomb.v2) provides a `Kill`
-method that signals cancelation by closing a `Dying` channel.
-`Tomb` also provides methods to wait for those goroutines to exit, similar to
-`sync.WaitGroup`.
-In [tomb.go](context/tomb/tomb.go), we provide a `Context` implementation that
-is canceled when either its parent `Context` is canceled or a provided `Tomb` is
-killed.
-
-## Conclusion
-
-At Google, we require that Go programmers pass a `Context` parameter as the
-first argument to every function on the call path between incoming and outgoing
-requests.
-This allows Go code developed by many different teams to interoperate well.
-It provides simple control over timeouts and cancelation and ensures that
-critical values like security credentials transit Go programs properly.
-
-Server frameworks that want to build on `Context` should provide implementations
-of `Context` to bridge between their packages and those that expect a `Context`
-parameter.
-Their client libraries would then accept a `Context` from the calling code.
-By establishing a common interface for request-scoped data and cancelation,
-`Context` makes it easier for package developers to share code for creating
-scalable services.
diff --git a/_content/context/google/google.go b/_content/context/google/google.go
deleted file mode 100644
index e25cfc1..0000000
--- a/_content/context/google/google.go
+++ /dev/null
@@ -1,94 +0,0 @@
-// +build OMIT
-
-// Package google provides a function to do Google searches using the Google Web
-// Search API. See https://developers.google.com/web-search/docs/
-//
-// This package is an example to accompany https://blog.golang.org/context.
-// It is not intended for use by others.
-//
-// Google has since disabled its search API,
-// and so this package is no longer useful.
-package google
-
-import (
-	"context"
-	"encoding/json"
-	"net/http"
-
-	"golang.org/x/blog/content/context/userip"
-)
-
-// Results is an ordered list of search results.
-type Results []Result
-
-// A Result contains the title and URL of a search result.
-type Result struct {
-	Title, URL string
-}
-
-// Search sends query to Google search and returns the results.
-func Search(ctx context.Context, query string) (Results, error) {
-	// Prepare the Google Search API request.
-	req, err := http.NewRequest("GET", "https://ajax.googleapis.com/ajax/services/search/web?v=1.0", nil)
-	if err != nil {
-		return nil, err
-	}
-	q := req.URL.Query()
-	q.Set("q", query)
-
-	// If ctx is carrying the user IP address, forward it to the server.
-	// Google APIs use the user IP to distinguish server-initiated requests
-	// from end-user requests.
-	if userIP, ok := userip.FromContext(ctx); ok {
-		q.Set("userip", userIP.String())
-	}
-	req.URL.RawQuery = q.Encode()
-
-	// Issue the HTTP request and handle the response. The httpDo function
-	// cancels the request if ctx.Done is closed.
-	var results Results
-	err = httpDo(ctx, req, func(resp *http.Response, err error) error {
-		if err != nil {
-			return err
-		}
-		defer resp.Body.Close()
-
-		// Parse the JSON search result.
-		// https://developers.google.com/web-search/docs/#fonje
-		var data struct {
-			ResponseData struct {
-				Results []struct {
-					TitleNoFormatting string
-					URL               string
-				}
-			}
-		}
-		if err := json.NewDecoder(resp.Body).Decode(&data); err != nil {
-			return err
-		}
-		for _, res := range data.ResponseData.Results {
-			results = append(results, Result{Title: res.TitleNoFormatting, URL: res.URL})
-		}
-		return nil
-	})
-	// httpDo waits for the closure we provided to return, so it's safe to
-	// read results here.
-	return results, err
-}
-
-// httpDo issues the HTTP request and calls f with the response. If ctx.Done is
-// closed while the request or f is running, httpDo cancels the request, waits
-// for f to exit, and returns ctx.Err. Otherwise, httpDo returns f's error.
-func httpDo(ctx context.Context, req *http.Request, f func(*http.Response, error) error) error {
-	// Run the HTTP request in a goroutine and pass the response to f.
-	c := make(chan error, 1)
-	req = req.WithContext(ctx)
-	go func() { c <- f(http.DefaultClient.Do(req)) }()
-	select {
-	case <-ctx.Done():
-		<-c // Wait for f to return.
-		return ctx.Err()
-	case err := <-c:
-		return err
-	}
-}
diff --git a/_content/context/gorilla/gorilla.go b/_content/context/gorilla/gorilla.go
deleted file mode 100644
index 4698dce..0000000
--- a/_content/context/gorilla/gorilla.go
+++ /dev/null
@@ -1,51 +0,0 @@
-// +build OMIT
-
-// Package gorilla provides a go.net/context.Context implementation whose Value
-// method returns the values associated with a specific HTTP request in the
-// github.com/gorilla/context package.
-package gorilla
-
-import (
-	"net/http"
-
-	gcontext "github.com/gorilla/context"
-	"golang.org/x/net/context"
-)
-
-// NewContext returns a Context whose Value method returns values associated
-// with req using the Gorilla context package:
-// http://www.gorillatoolkit.org/pkg/context
-func NewContext(parent context.Context, req *http.Request) context.Context {
-	return &wrapper{parent, req}
-}
-
-type wrapper struct {
-	context.Context
-	req *http.Request
-}
-
-type key int
-
-const reqKey key = 0
-
-// Value returns Gorilla's context package's value for this Context's request
-// and key. It delegates to the parent Context if there is no such value.
-func (ctx *wrapper) Value(key interface{}) interface{} {
-	if key == reqKey {
-		return ctx.req
-	}
-	if val, ok := gcontext.GetOk(ctx.req, key); ok {
-		return val
-	}
-	return ctx.Context.Value(key)
-}
-
-// HTTPRequest returns the *http.Request associated with ctx using NewContext,
-// if any.
-func HTTPRequest(ctx context.Context) (*http.Request, bool) {
-	// We cannot use ctx.(*wrapper).req to get the request because ctx may
-	// be a Context derived from a *wrapper. Instead, we use Value to
-	// access the request if it is anywhere up the Context tree.
-	req, ok := ctx.Value(reqKey).(*http.Request)
-	return req, ok
-}
diff --git a/_content/context/interface.go b/_content/context/interface.go
deleted file mode 100644
index 838c7da..0000000
--- a/_content/context/interface.go
+++ /dev/null
@@ -1,46 +0,0 @@
-// +build OMIT
-
-package context
-
-import "time"
-
-// A Context carries a deadline, cancelation signal, and request-scoped values
-// across API boundaries. Its methods are safe for simultaneous use by multiple
-// goroutines.
-type Context interface {
-	// Done returns a channel that is closed when this Context is canceled
-	// or times out.
-	Done() <-chan struct{}
-
-	// Err indicates why this context was canceled, after the Done channel
-	// is closed.
-	Err() error
-
-	// Deadline returns the time when this Context will be canceled, if any.
-	Deadline() (deadline time.Time, ok bool)
-
-	// Value returns the value associated with key or nil if none.
-	Value(key interface{}) interface{}
-}
-
-// WithCancel returns a copy of parent whose Done channel is closed as soon as
-// parent.Done is closed or cancel is called.
-func WithCancel(parent Context) (ctx Context, cancel CancelFunc)
-
-// A CancelFunc cancels a Context.
-type CancelFunc func()
-
-// WithTimeout returns a copy of parent whose Done channel is closed as soon as
-// parent.Done is closed, cancel is called, or timeout elapses. The new
-// Context's Deadline is the sooner of now+timeout and the parent's deadline, if
-// any. If the timer is still running, the cancel function releases its
-// resources.
-func WithTimeout(parent Context, timeout time.Duration) (Context, CancelFunc)
-
-// WithValue returns a copy of parent whose Value method returns val for key.
-func WithValue(parent Context, key interface{}, val interface{}) Context
-
-// Background returns an empty Context. It is never canceled, has no deadline,
-// and has no values. Background is typically used in main, init, and tests,
-// and as the top-level Context for incoming requests.
-func Background() Context
diff --git a/_content/context/server/server.go b/_content/context/server/server.go
deleted file mode 100644
index ebee9a1..0000000
--- a/_content/context/server/server.go
+++ /dev/null
@@ -1,100 +0,0 @@
-// +build OMIT
-
-// The server program issues Google search requests and demonstrates the use of
-// the go.net Context API. It serves on port 8080.
-//
-// The /search endpoint accepts these query params:
-//   q=the Google search query
-//   timeout=a timeout for the request, in time.Duration format
-//
-// For example, http://localhost:8080/search?q=golang&timeout=1s serves the
-// first few Google search results for "golang" or a "deadline exceeded" error
-// if the timeout expires.
-package main
-
-import (
-	"context"
-	"html/template"
-	"log"
-	"net/http"
-	"time"
-
-	"golang.org/x/blog/content/context/google"
-	"golang.org/x/blog/content/context/userip"
-)
-
-func main() {
-	http.HandleFunc("/search", handleSearch)
-	log.Fatal(http.ListenAndServe(":8080", nil))
-}
-
-// handleSearch handles URLs like /search?q=golang&timeout=1s by forwarding the
-// query to google.Search. If the query param includes timeout, the search is
-// canceled after that duration elapses.
-func handleSearch(w http.ResponseWriter, req *http.Request) {
-	// ctx is the Context for this handler. Calling cancel closes the
-	// ctx.Done channel, which is the cancellation signal for requests
-	// started by this handler.
-	var (
-		ctx    context.Context
-		cancel context.CancelFunc
-	)
-	timeout, err := time.ParseDuration(req.FormValue("timeout"))
-	if err == nil {
-		// The request has a timeout, so create a context that is
-		// canceled automatically when the timeout expires.
-		ctx, cancel = context.WithTimeout(context.Background(), timeout)
-	} else {
-		ctx, cancel = context.WithCancel(context.Background())
-	}
-	defer cancel() // Cancel ctx as soon as handleSearch returns.
-
-	// Check the search query.
-	query := req.FormValue("q")
-	if query == "" {
-		http.Error(w, "no query", http.StatusBadRequest)
-		return
-	}
-
-	// Store the user IP in ctx for use by code in other packages.
-	userIP, err := userip.FromRequest(req)
-	if err != nil {
-		http.Error(w, err.Error(), http.StatusBadRequest)
-		return
-	}
-	ctx = userip.NewContext(ctx, userIP)
-
-	// Run the Google search and print the results.
-	start := time.Now()
-	results, err := google.Search(ctx, query)
-	elapsed := time.Since(start)
-	if err != nil {
-		http.Error(w, err.Error(), http.StatusInternalServerError)
-		return
-	}
-	if err := resultsTemplate.Execute(w, struct {
-		Results          google.Results
-		Timeout, Elapsed time.Duration
-	}{
-		Results: results,
-		Timeout: timeout,
-		Elapsed: elapsed,
-	}); err != nil {
-		log.Print(err)
-		return
-	}
-}
-
-var resultsTemplate = template.Must(template.New("results").Parse(`
-<html>
-<head/>
-<body>
-  <ol>
-  {{range .Results}}
-    <li>{{.Title}} - <a href="{{.URL}}">{{.URL}}</a></li>
-  {{end}}
-  </ol>
-  <p>{{len .Results}} results in {{.Elapsed}}; timeout {{.Timeout}}</p>
-</body>
-</html>
-`))
diff --git a/_content/context/tomb/tomb.go b/_content/context/tomb/tomb.go
deleted file mode 100644
index da94dc9..0000000
--- a/_content/context/tomb/tomb.go
+++ /dev/null
@@ -1,24 +0,0 @@
-// +build OMIT
-
-// Package tomb provides a Context implementation that is canceled when either
-// its parent Context is canceled or a provided Tomb is killed.
-package tomb
-
-import (
-	"golang.org/x/net/context"
-	tomb "gopkg.in/tomb.v2"
-)
-
-// NewContext returns a Context that is canceled either when parent is canceled
-// or when t is Killed.
-func NewContext(parent context.Context, t *tomb.Tomb) context.Context {
-	ctx, cancel := context.WithCancel(parent)
-	go func() {
-		select {
-		case <-t.Dying():
-			cancel()
-		case <-ctx.Done():
-		}
-	}()
-	return ctx
-}
diff --git a/_content/context/userip/userip.go b/_content/context/userip/userip.go
deleted file mode 100644
index 06d3245..0000000
--- a/_content/context/userip/userip.go
+++ /dev/null
@@ -1,51 +0,0 @@
-// +build OMIT
-
-// Package userip provides functions for extracting a user IP address from a
-// request and associating it with a Context.
-//
-// This package is an example to accompany https://blog.golang.org/context.
-// It is not intended for use by others.
-package userip
-
-import (
-	"context"
-	"fmt"
-	"net"
-	"net/http"
-)
-
-// FromRequest extracts the user IP address from req, if present.
-func FromRequest(req *http.Request) (net.IP, error) {
-	ip, _, err := net.SplitHostPort(req.RemoteAddr)
-	if err != nil {
-		return nil, fmt.Errorf("userip: %q is not IP:port", req.RemoteAddr)
-	}
-
-	userIP := net.ParseIP(ip)
-	if userIP == nil {
-		return nil, fmt.Errorf("userip: %q is not IP:port", req.RemoteAddr)
-	}
-	return userIP, nil
-}
-
-// The key type is unexported to prevent collisions with context keys defined in
-// other packages.
-type key int
-
-// userIPkey is the context key for the user IP address.  Its value of zero is
-// arbitrary.  If this package defined other context keys, they would have
-// different integer values.
-const userIPKey key = 0
-
-// NewContext returns a new Context carrying userIP.
-func NewContext(ctx context.Context, userIP net.IP) context.Context {
-	return context.WithValue(ctx, userIPKey, userIP)
-}
-
-// FromContext extracts the user IP address from ctx, if present.
-func FromContext(ctx context.Context) (net.IP, bool) {
-	// ctx.Value returns nil if ctx has no value for the key;
-	// the net.IP type assertion returns ok=false for nil.
-	userIP, ok := ctx.Value(userIPKey).(net.IP)
-	return userIP, ok
-}
diff --git a/_content/contributor-workshop.article b/_content/contributor-workshop.article
deleted file mode 100644
index 1254bb9..0000000
--- a/_content/contributor-workshop.article
+++ /dev/null
@@ -1,395 +0,0 @@
-# Contribution Workshop
-9 Aug 2017
-Tags: community
-Summary: The Go contributor workshop trained new contributors at GopherCon.
-
-Steve Francia
-
-Cassandra Salisbury
-
-Matt Broberg
-
-Dmitri Shuralyov
-
-## Event Overview
-
-by [Steve](https://twitter.com/spf13)
-
-During the community day at GopherCon, the Go team held two workshops
-where we worked with people to help them make their first contribution to the
-Go project. This was the first time the Go project has ever attempted anything
-like this. We had about 140 participants and about 35 people who volunteered as
-mentors. Mentors not only received warm fuzzy feelings for helping others, but
-also a very stylish Go Mentor trucker hat. We had contributors of all
-ages and experience levels coming from North and South America, Africa, Europe,
-Asia, and Australia. It was truly a worldwide effort of Gophers coming together
-at GopherCon.
-
-One of our reasons for running the workshop was for it to act as a forcing
-function to make us improve our contributor experience. In preparation for the
-workshop, we rewrote our contributor guide, including adding a "troubleshooting"
-section and built a tool `go-contrib-init`, which automated the process of
-setting up a development environment to be able to contribute to Go.
-
-For the workshop itself, we developed a presentation _"Contributing to Go,"_
-and a dashboard / scoreboard that was presented during the event. The
-scoreboard was designed to encourage us all to work together towards a common
-goal of seeing our collective score increase. Participants added 1, 2 or 3 points to
-the total score when they performed actions like registering an account, making
-a change list (also known as a CL, similar to a pull request),
-amending a CL, or submitting a CL.
-
-.image contributor-workshop/image17.png
-
-Brad Fitzpatrick, who stayed home from GopherCon this year, was ready and
-waiting to review all CLs submitted. He was so quick to review that many people
-thought he was an automated bot. Internally our team is now calling him
-"BradBot" mostly because we are in awe and a bit jealous.
-
-.image contributor-workshop/image9.jpg
-.image contributor-workshop/image6.png
-
-### Impact
-
-We had a total of 65 CLs submitted from the people who participated in the
-workshop (within a week of the workshop). Of these, 44 were from contributors
-who had never previously contributed to any of the repos in the Go project.
-Half (22) of these contributions were already merged. Many of the others are
-waiting on the codebase to thaw as we are in the middle of a freeze for the
-upcoming 1.9 release. In addition to CLs, many contributed to the project in
-the form of bug reports,
-[gardening tasks](https://golang.org/wiki/Gardening), and other types
-of contributions.
-
-The most common type of contribution was an example function to be used in the
-documentation. The [Go User survey](https://blog.golang.org/survey2016-results)
-identified that our documentation was significantly lacking examples. In the
-presentation, we asked users to find a package they loved and to add an example. In
-the Go project, examples are written as code in Go files
-(with specific naming) and the `go doc` tool displays them along side the documentation.
-This is a perfect first contribution as it's something that can be merged
-during a freeze, it's of critical importance to our users, and it's an addition
-that has a relatively narrow scope.
-
-One of the examples added is that of creating a Stringer, one of the more
-widely used interfaces in Go.
-[CL 49270](https://golang.org/cl/49270/)
-
-In addition to examples, many people contributed critical bug fixes including:
-
-  - [CL 48988](https://golang.org/cl/48988/) fixing [issue #21029](https://golang.org/issue/21029)
-  - [CL 49050](https://golang.org/cl/49050/) fixing [issue #20054](https://golang.org/issue/20054)
-  - [CL 49031](https://golang.org/cl/49031/) fixing [issue #20166](https://golang.org/issue/20166)
-  - [CL 49170](https://golang.org/cl/49170/) fixing [issue #20877](https://golang.org/issue/20877)
-
-Some people even surprised us by arriving with a bug in mind that they wanted
-to fix. Nikhita arrived ready to tackle
-[issue #20786](https://golang.org/issue/20786)
-and she did submitting
-[CL 48871](https://golang.org/cl/48871/),
-after which she tweeted:
-
-.image contributor-workshop/image19.png
-
-Not only were some great improvements made, but most importantly, we narrowed
-the gap between the core Go team and the broader community members. Many people
-on the Go team remarked that the community members were teaching them things
-about the Go project. People in the community (in person, and on Twitter)
-remarked that felt welcome to participate in the project.
-
-.image contributor-workshop/image12.png
-.image contributor-workshop/image13.png
-.image contributor-workshop/image3.png
-
-### Future
-
-The event was successful well beyond our expectations. Sameer Ajmani, Go team
-manager said, "The contributor workshop was incredibly fun and educational–for
-the Go team.  We cringed as users hit the rough edges in our process, and
-celebrated when they got up on the dashboard. The cheer when the group score
-hit 1000 was awesome."
-
-We are looking into ways to make this workshop easier to run for future events
-(like meetups and conferences). Our biggest challenge is providing enough
-mentorship so that users feel supported. If you have any ideas or would like to
-help with this process please [let me know](mailto:spf@golang.org).
-
-I've asked a few participants of the event to share their experiences below:
-
-## My Contribution Experience
-
-by [Cassandra](https://twitter.com/cassandraoid)
-
-When I heard about the go-contrib workshop I was very excited and then I was
-extremely intimidated. I was encouraged by a member of the Go team to
-participate, so I thought what the heck.
-
-As I walked into the room (let's be real, I ran into the room because I was
-running late) I was pleased to see the room was jam-packed. I looked around for
-people in Gopher caps, which was the main indicator they were teachers. I sat
-down at one of the 16 round tables that had two hats and three non-hats.
-Brought up my screen and was ready to roll…
-
-Jess Frazelle stood up and started the presentation and provided the group with
-[a link](https://docs.google.com/presentation/d/1ap2fycBSgoo-jCswhK9lqgCIFroE1pYpsXC1ffYBCq4/edit#slide=id.p)
-to make it easy to follow.
-
-.image contributor-workshop/image16.png
-
-The murmurs grew from a deep undercurrent to a resounding melody of voices,
-people were getting their computers set up with Go, they were skipping ahead to
-make sure their GOPATH was set, and were… wait what's Gerrit?
-
-Most of us had to get a little intro to Gerrit. I had no clue what it was, but
-luckily there was a handy slide. Jess explained that it was an alternative to
-GitHub with slightly more advanced code review tools. We then went through
-GitHub vs Geritt terminology, so we had better understanding of the process.
-
-.image contributor-workshop/image10.png
-
-Ok, now it was time to become a **freaking Go contributor**.
-
-To make this more exciting than it already is, the Go team set up a game where
-we could track as a group how many points we could rack up based on the Gerrit
-score system.
-
-.image contributor-workshop/image7.png
-
-Seeing your name pop up on the board and listening to everyone's excitement was
-intoxicating. It also invoked a sense of teamwork that lead to a feeling of
-inclusion and feeling like you were truly a part of the Go community.
-
-.image contributor-workshop/image11.png
-
-In 6 steps a room of around 80 people were able to learn how to contribute to
-go within an hour. That's a feat!
-
-It wasn't nearly as difficult as I anticipated and it wasn't out of scope for a
-total newbie. It fostered a sense of community in an active and tangible way as
-well as a sense of inclusion in the illustrious process of Go contributions.
-
-I'd personally like to thank the Go Team, the Gopher mentors in hats, and my
-fellow participants for making it one of my most memorable moments at
-GopherCon.
-
-## My Contribution Experience
-
-by [Matt](https://twitter.com/mbbroberg)
-
-I've always found programming languages to be intimidating. It's the code that
-enables the world to write code. Given the impact, surely smarter people than
-me should be working on it... but that fear was something to overcome. So when
-the opportunity to join a workshop to contribute to my new favorite programming
-language came up, I was excite to see how I could and how I could help. A month
-later, I'm now certain that anyone and everyone can (and should) contribute back to Go.
-
-Here are my very verbose steps to go from 0 to 2 contributions to Go:
-
-### The Setup
-
-Given Go's use of Gerrit, I started by setting up my environment for it. [Jess Frazzelle's guide](https://docs.google.com/presentation/d/1ap2fycBSgoo-jCswhK9lqgCIFroE1pYpsXC1ffYBCq4/edit#slide=id.g1f953ef7df_0_9)
-is a great place to start to not miss a step.
-
-The real fun starts when you clone the Go repo. Ironically, you don't hack on
-Go under `$GOPATH`, so I put it in my other workspace (which is `~/Develop`).
-
-	cd $DEV # That's my source code folder outside of $GOPATH
-	git clone --depth 1 https://go.googlesource.com/go
-
-Then install the handy dandy helper tool, `go-contrib-init`:
-
-	go get -u golang.org/x/tools/cmd/go-contrib-init
-
-Now you can run `go-contrib-init` from the `go/` folder we cloned above and see
-whether or not we're ready to contribute. But hold on if you're following along,
-you're not ready just yet.
-
-Next, install `codereview` so you can participate in a Gerrit code review:
-
-	go get -u golang.org/x/review/git-codereview
-
-This package includes `git change` and `git mail` which will replace your
-normal workflow of `git commit` and `git push` respectively.
-
-Okay, installations are out of the way. Now setup your [Gerrit account here](https://go-review.googlesource.com/settings/#Profile),
-then [sign the CLA](https://go-review.googlesource.com/settings#Agreements) appropriate for
-you (I signed a personal one for all Google projects, but choose the right option for you.
-You can see all CLAs you've signed at [cla.developers.google.com/clas](https://cla.developers.google.com/clas)).
-
-AND BAM. You're good (to go)! But where to contribute?
-
-### Contributing
-
-In the workshop, they sent us into the `scratch` repository, which is a safe place to
-fool around in order to master the workflow:
-
-	cd $(go env GOPATH)/src/golang.org/x
-	git clone --depth 1 [[https://go.googlesource.com/scratch][go.googlesource.com/scratch]]
-
-First stop is to `cd` in and run `go-contrib-init` to make sure you're ready to contribute:
-
-	go-contrib-init
-	All good. Happy hacking!
-
-From there, I made a folder named after my GitHub account, did a `git add -u`
-then took `git change` for a spin. It has a hash that keeps track of your work,
-which is the one line you shouldn't touch. Other than that, it feels just like
-`git commit`. Once I got the commit message matching the format of
-`package: description` (description begins with a lowercase), I used
-`git mail` to send it over to Gerrit.
-
-Two good notes to take at this point: `git change` also works like `git commit --amend`, so
-if you need to update your patch you can `add` then `change` and it will all
-link to the same patch. Secondly, you can always review your patch from your
-[personal Gerrit dashboard](https://go-review.googlesource.com/dashboard/).
-
-After a few back and forths, I officially had a contribute to Go! And if Jaana
-is right, it might be the first with emojis ✌️.
-
-.image contributor-workshop/image15.png
-.image contributor-workshop/image23.png
-
-### Contributing, For Real
-
-The scratch repo is fun and all, but there's a ton of ways to get into the
-depths of Go's packages and give back. It's at this point where I cruised
-around the many packages available to see what was available and interesting to
-me. And by "cruised around" I mean attempted to find a list of packages, then
-went to my source code to see what's around under the `go/src/` folder:
-
-.image contributor-workshop/image22.png
-
-I decided to see what I can do in the `regexp` package, maybe out of love and
-fear of regex. Here's where I switched to the
-[website's view of the package](https://godoc.org/regexp) (it's good to know
-that each standard package can be found at https://godoc.org/$PACKAGENAME). In
-there I noticed that `QuoteMeta` was missing the same level of detailed examples
-other functions have (and I could use the practice using Gerrit).
-
-.image contributor-workshop/image1.png
-
-I started looking at `go/src/regexp` to try to find where to add examples and I
-got lost pretty quickly. Lucky for me, [Francesc](https://twitter.com/francesc) was around that day. He walked
-me through how all examples are actually in-line tests in a `example_test.go`
-file. They follow the format of test cases followed by "Output" commented out
-and then the answers to the tests. For example:
-
-	func ExampleRegexp_FindString() {
-		re := regexp.MustCompile("fo.?")
-		fmt.Printf("%q\n", re.FindString("seafood"))
-		fmt.Printf("%q\n", re.FindString("meat"))
-		// Output:
-		// "foo"
-		// ""
-	}
-
-Kind of cool, right?? I followed Francesc's lead and added a function
-`ExampleQuoteMeta` and added a few I thought would be helpful. From there it's
-a `git change` and `git mail` to Gerrit!
-
-I have to say that Steve Francia challenged me to "find something that isn't an
-open issue and fix it," so I included some documentation changes for QuoteMeta
-in my patch. It's going to be open for a bit longer given the additional scope,
-but I think it's worth it on this one.
-
-I can hear your question already: how did I verify it worked? Well it wasn't
-easy to be honest. Running `go test example_test.go -run QuoteMeta -v` won't do
-it since we're working outside of our $GOPATH. I struggled to figure it out
-until [Kale Blakenship wrote this awesome post on testing in Go](https://medium.com/@vCabbage/go-testing-standard-library-changes-1e9cbed11339).
-Bookmark this one for later.
-
-You can see my completed [contribution here](https://go-review.googlesource.com/c/49130/). What I also hope you see is
-how simple it is to get into the flow of contributing. If you're like me,
-you'll be good at finding a small typo or missing example in the docs to start to
-get used to the `git codereview` workflow. After that, you'll be ready to find
-an open issue, ideally one [tagged for an upcoming release](https://github.com/golang/go/milestones), and give it a go. No matter
-what you choose to do, definitely go forth and do it. The Go team proved to me
-just how much they care about helping us all contribute back. I can't wait for
-my next `git mail`.
-
-## My Mentorship Experience
-
-by [Dmitri](https://twitter.com/dmitshur)
-
-I was looking forward to participating in the Contribution Workshop event as a
-mentor. I had high expectations for the event, and thought it was a great idea
-before it started.
-
-I made my first contribution to Go on May 10th, 2014. I remember it was about
-four months from the moment I wanted to contribute, until that day, when I
-actually sent my first CL. It took that long to build up the courage and fully
-commit to figuring out the process. I was an experienced software engineer at
-the time. Despite that, the Go contribution process felt alien—being unlike all
-other processes I was already familiar with—and therefore seemed intimidating.
-It was well documented though, so I knew it would be just a matter of finding
-the time, sitting down, and doing it. The "unknown" factor kept me from giving
-it a shot.
-
-After a few months passed, I thought "enough is enough," and decided to
-dedicate an entire day of an upcoming weekend to figuring out the process. I
-set aside all of Saturday for doing one thing: sending my first CL to Go. I
-opened up [the Contribution Guide](https://golang.org/doc/contribute.html)
-and started following all the steps, from the very top. Within an hour, I was
-done. I had send my first CL. I was both in awe and shock. In awe, because I
-had finally sent a contribution to Go, and it was accepted! In shock, because,
-why did I wait so long to finally do this? Following the steps in
-[the Contribution Guide](https://golang.org/doc/contribute.html) was very
-easy, and the entire process went completely smoothly. If only someone had told
-me that I'd be done within an hour and nothing would go wrong, I would've done
-it much sooner!
-
-Which brings me to this event and why I thought it was such a good idea. For
-anyone who ever wanted to contribute to Go, but felt daunted by the unfamiliar
-and seemingly lengthy process (like I was during those four months), this was
-their chance! Not only is it easy to commit to figuring it out by attending the
-event, but also the Go team and helpful volunteer mentors would be there to
-help you along the way.
-
-Despite the already high expectations I had for the event, my expectations were
-exceeded. For one, the Go team had prepared really well and invested a lot in
-making the event that much more enjoyable for everyone. There was a very fun
-presentation that went over all the contributing steps quickly. There was a
-dashboard made for the event, where everyone's successfully completed steps
-were rewarded with points towards a global score. That made it into a very
-collaborative and social event! Finally, and most importantly, they were Go
-team members like Brad Fitzpatrick behind the scenes, helping review CLs
-promptly! That meant the CLs that were submitted received reviews quickly, with
-actionable next steps, so everyone could move forward and learn more.
-
-I originally anticipated the event to be somewhat dull, in that the
-contribution steps are extremely simple to follow. However, I found that wasn't
-always the case, and I was able to use my expertise in Go to help out people
-who got stuck in various unexpected places. It turns out, the real world is
-filled with edge cases. For instance, someone had two git emails, one personal
-and another for work. There was a delay with signing the CLA for the work
-email, so they tried to use their personal email instead. That meant each
-commit had to be amended to use the right email, something the tools didn't
-take into account. (Luckily, there is a troubleshooting section in the
-contribution guide covering this exact issue!) There were other subtle mistakes
-or environment misconfiguration that some people ran into, because having more
-than one Go installation was a bit unusual. Sometimes, the GOROOT environment
-variable had to be explicitly set, temporarily, to get godoc to show changes in
-the right standard library (I was tongue-in-cheek looking over my shoulder to
-check for Dave Cheney as I uttered those words).
-
-Overall, I oversaw a few new gophers make their first Go contributions. They
-sent the CLs, responded to review feedback, made edits, iterated until everyone
-was happy, and eventually saw their first Go contributions get merged to
-master! It was very rewarding to see the happiness on their faces, because the
-joy of making one's first contribution is something I can relate to myself. It
-was also great to be able to help them out, and explain tricky situations that
-they sometimes found themselves. From what I can tell, many happy gophers
-walked away from the event, myself included!
-
-## Photos from the event
-
-.image contributor-workshop/image2.jpg
-.image contributor-workshop/image4.jpg
-.image contributor-workshop/image5.jpg
-.image contributor-workshop/image8.jpg
-.image contributor-workshop/image14.jpg
-.image contributor-workshop/image18.jpg
-.image contributor-workshop/image20.jpg
-.image contributor-workshop/image21.jpg
-
-Photos by Sameer Ajmani & Steve Francia
diff --git a/_content/contributor-workshop/image1.png b/_content/contributor-workshop/image1.png
deleted file mode 100755
index 4985756..0000000
--- a/_content/contributor-workshop/image1.png
+++ /dev/null
Binary files differ
diff --git a/_content/contributor-workshop/image10.png b/_content/contributor-workshop/image10.png
deleted file mode 100755
index 34693fc..0000000
--- a/_content/contributor-workshop/image10.png
+++ /dev/null
Binary files differ
diff --git a/_content/contributor-workshop/image11.png b/_content/contributor-workshop/image11.png
deleted file mode 100755
index 7925273..0000000
--- a/_content/contributor-workshop/image11.png
+++ /dev/null
Binary files differ
diff --git a/_content/contributor-workshop/image12.png b/_content/contributor-workshop/image12.png
deleted file mode 100755
index 457b102..0000000
--- a/_content/contributor-workshop/image12.png
+++ /dev/null
Binary files differ
diff --git a/_content/contributor-workshop/image13.png b/_content/contributor-workshop/image13.png
deleted file mode 100755
index b6b3b75..0000000
--- a/_content/contributor-workshop/image13.png
+++ /dev/null
Binary files differ
diff --git a/_content/contributor-workshop/image14.jpg b/_content/contributor-workshop/image14.jpg
deleted file mode 100644
index 78e35f4..0000000
--- a/_content/contributor-workshop/image14.jpg
+++ /dev/null
Binary files differ
diff --git a/_content/contributor-workshop/image15.png b/_content/contributor-workshop/image15.png
deleted file mode 100755
index 6bd638c..0000000
--- a/_content/contributor-workshop/image15.png
+++ /dev/null
Binary files differ
diff --git a/_content/contributor-workshop/image16.png b/_content/contributor-workshop/image16.png
deleted file mode 100755
index 83e6919..0000000
--- a/_content/contributor-workshop/image16.png
+++ /dev/null
Binary files differ
diff --git a/_content/contributor-workshop/image17.png b/_content/contributor-workshop/image17.png
deleted file mode 100755
index 3109972..0000000
--- a/_content/contributor-workshop/image17.png
+++ /dev/null
Binary files differ
diff --git a/_content/contributor-workshop/image18.jpg b/_content/contributor-workshop/image18.jpg
deleted file mode 100644
index 41a62d0..0000000
--- a/_content/contributor-workshop/image18.jpg
+++ /dev/null
Binary files differ
diff --git a/_content/contributor-workshop/image19.png b/_content/contributor-workshop/image19.png
deleted file mode 100755
index e5c3470..0000000
--- a/_content/contributor-workshop/image19.png
+++ /dev/null
Binary files differ
diff --git a/_content/contributor-workshop/image2.jpg b/_content/contributor-workshop/image2.jpg
deleted file mode 100644
index e78605c..0000000
--- a/_content/contributor-workshop/image2.jpg
+++ /dev/null
Binary files differ
diff --git a/_content/contributor-workshop/image20.jpg b/_content/contributor-workshop/image20.jpg
deleted file mode 100644
index c477609..0000000
--- a/_content/contributor-workshop/image20.jpg
+++ /dev/null
Binary files differ
diff --git a/_content/contributor-workshop/image21.jpg b/_content/contributor-workshop/image21.jpg
deleted file mode 100644
index 155ea69..0000000
--- a/_content/contributor-workshop/image21.jpg
+++ /dev/null
Binary files differ
diff --git a/_content/contributor-workshop/image22.png b/_content/contributor-workshop/image22.png
deleted file mode 100755
index 8460e56..0000000
--- a/_content/contributor-workshop/image22.png
+++ /dev/null
Binary files differ
diff --git a/_content/contributor-workshop/image23.png b/_content/contributor-workshop/image23.png
deleted file mode 100755
index 2cd5e53..0000000
--- a/_content/contributor-workshop/image23.png
+++ /dev/null
Binary files differ
diff --git a/_content/contributor-workshop/image3.png b/_content/contributor-workshop/image3.png
deleted file mode 100755
index 4374122..0000000
--- a/_content/contributor-workshop/image3.png
+++ /dev/null
Binary files differ
diff --git a/_content/contributor-workshop/image4.jpg b/_content/contributor-workshop/image4.jpg
deleted file mode 100644
index b2a1783..0000000
--- a/_content/contributor-workshop/image4.jpg
+++ /dev/null
Binary files differ
diff --git a/_content/contributor-workshop/image5.jpg b/_content/contributor-workshop/image5.jpg
deleted file mode 100644
index ef198e8..0000000
--- a/_content/contributor-workshop/image5.jpg
+++ /dev/null
Binary files differ
diff --git a/_content/contributor-workshop/image6.png b/_content/contributor-workshop/image6.png
deleted file mode 100755
index 7ed45f4..0000000
--- a/_content/contributor-workshop/image6.png
+++ /dev/null
Binary files differ
diff --git a/_content/contributor-workshop/image7.png b/_content/contributor-workshop/image7.png
deleted file mode 100755
index 60edd58..0000000
--- a/_content/contributor-workshop/image7.png
+++ /dev/null
Binary files differ
diff --git a/_content/contributor-workshop/image8.jpg b/_content/contributor-workshop/image8.jpg
deleted file mode 100644
index a5eb553..0000000
--- a/_content/contributor-workshop/image8.jpg
+++ /dev/null
Binary files differ
diff --git a/_content/contributor-workshop/image9.jpg b/_content/contributor-workshop/image9.jpg
deleted file mode 100644
index abe4d44..0000000
--- a/_content/contributor-workshop/image9.jpg
+++ /dev/null
Binary files differ
diff --git a/_content/contributors-summit-2019.article b/_content/contributors-summit-2019.article
deleted file mode 100644
index ad3aeee..0000000
--- a/_content/contributors-summit-2019.article
+++ /dev/null
@@ -1,393 +0,0 @@
-# Contributors Summit 2019
-15 Aug 2019
-Tags: community
-Summary: Reporting from the Go Contributor Summit at GopherCon 2019.
-
-Carmen Andoh and contributors
-
-## Introduction
-
-For the third year in a row, the Go team and contributors convened
-the day before GopherCon to discuss and plan for the future of the Go project.
-The event included self-organizing into breakout groups,
-a town-hall style discussion about the proposal process in the morning,
-and afternoon break-out roundtable discussions
-based on topics our contributors chose.
-We asked five contributors to write about their experience
-in various discussions at this year’s summit.
-
-.image contributors-summit-2019/group.jpg _ 800
-
-_(Photo by Steve Francia.)_
-
-## Compiler and Runtime (report by Lynn Boger)
-
-The Go contributors summit was a great opportunity
-to meet and discuss topics and ideas with others who also contribute to Go.
-
-The day started out with a time to meet everyone in the room.
-There was a good mix of the core Go team
-and others who actively contribute to Go.
-From there we decided what topics were of interest
-and how to split the big group into smaller groups.
-My area of interest is the compiler, so I joined that group
-and stayed with them for most of the time.
-
-At our first meeting, a long list of topics were brought up
-and as a result the compiler group decided to keep meeting throughout the day.
-I had a few topics of interest that I shared and many that others suggested
-were also of interest to me.
-Not all items on the list were discussed in detail;
-here is my list of those topics which had the most interest and discussion,
-followed by some brief comments that were made on other topics.
-
-**Binary size**.
-There was a concern expressed about binary size,
-especially that it continues to grow with each release.
-Some possible reasons were identified such as increased inlining and other optimizations.
-Most likely there is a set of users who want small binaries,
-and another group who wants the best performance possible and maybe some don’t care.
-This led to the topic of TinyGo, and it was noted that TinyGo was not a full implementation of Go
-and that it is important to keep TinyGo from diverging from Go and splitting the user base.
-More investigation is required to understand the need among users and the exact reasons
-contributing to the current size.
-If there are opportunities to reduce the size without affecting performance,
-those changes could be made, but if performance were affected
-some users would prefer better performance.
-
-**Vector assembly**.
-How to leverage vector assembly in Go was discussed for a while
-and has been a topic of interest in the past.
-I have split this into three separate possibilities, since they all relate to the use of vector instructions,
-but the way they are used are different, starting with the topic of vector assembly.
-This is another case of a compiler trade off.
-
-For most targets, there are critical functions in standard packages
-such as crypto, hash, math and others, where the use of assembly is necessary
-to get the best possible performance; however having large functions
-written in assembly makes them difficult to support and maintain
-and could require different implementations for each target platform.
-One solution is to make use of macro assembly or other
-high-level generation techniques to make the vector assembly easier to read and understand.
-
-Another side to this question is whether the Go compiler can
-directly generate SIMD vector instructions when compiling a Go source file,
-by enhancing the Go compiler to transform code sequences to “simdize”
-the code to make use of vector instructions.
-Implementing SIMD in the Go compiler would add complexity and compile time,
-and might not always result in code that performs better.
-The way the code is transformed could in some cases depend
-on the target platform so that would not be ideal.
-
-Another way to leverage vector instructions in Go is to provide a way
-to make it easier to make use of vector instructions from within the Go source code.
-Topics discussed were intrinsics, or implementations that exist in other compilers like Rust.
-In gcc some platforms provide inline asm, and Go possibly could provide this capability,
-but I know from experience that intermixing inline asm with Go code adds complexity
-to the compiler in terms of tracking register use and debugging.
-It allows the user to do things the compiler might not expect or want,
-and it does add an extra level of complexity.
-It could be inserted in places that are not ideal.
-
-In summary, it is important to provide a way to leverage
-the available vector instructions, and make it easier and safer to write.
-Where possible, functions use as much Go code as possible,
-and potentially find a way to use high level assembly.
-There was some discussion of designing an experimental vector package
-to try and implement some of these ideas.
-
-**New calling convention**.
-Several people were interested in the topic of the
-[ABI changes to provide a register based calling convention](https://golang.org/issue/18597).
-The current status was reported with details.
-There was discussion on what remained to be done before it could be used.
-The ABI specification needs to be written first and it was not clear when that would be done.
-I know this will benefit some target platforms more than others
-and a register calling convention is used in most compilers for other platforms.
-
-**General optimizations**.
-Certain optimizations that are more beneficial for some platforms other than x86 were discussed.
-In particular, loop optimizations such as hoisting of invariants and strength reduction could be done
-and provide more benefit on some platforms.
-Potential solutions were discussed, and implementation would probably be
-up to the targets that find those improvements important.
-
-**Feedback-directed optimizations**.
-This was discussed and debated as a possible future enhancement.
-In my experience, it is hard to find meaningful programs to use for
-collecting performance data that can later be used to optimize code.
-It increases compile time and takes a lot of space to save the data
-which might only be meaningful for a small set of programs.
-
-**Pending submissions**.
-A few members in the group mentioned changes they had been working on
-and plan to submit soon, including improvements to makeslice, and a rewrite of rulegen.
-
-**Compile time concerns**.
-Compile time was discussed briefly. It was noted that phase timing was added to the GOSSAFUNC output.
-
-**Compiler contributor communication**.
-Someone asked if there was a need for a Go compiler mailing list.
-It was suggested that we use golang-dev for that purpose,
-adding compiler to the subject line to identify it.
-If there is too much traffic on golang-dev, then a compiler-specific mailing list
-can be considered at some later point in time.
-
-**Community**.
-I found the day very beneficial in terms of connecting with people
-who have been active in the community and have similar areas of interest.
-I was able to meet many people who I’ve only known by the user name
-appearing in issues or mailing lists or CLs.
-I was able to discuss some topics and existing issues
-and get direct interactive feedback instead of waiting for online responses.
-I was encouraged to write issues on problems I have seen.
-These connections happened not just during this day but while
-running into others throughout the conference,
-having been introduced on this first day, which led to many interesting discussions.
-Hopefully these connections will lead to more effective communication
-and improved handling of issues and code changes in the future.
-
-## Tools (report by Paul Jolly)
-
-The tools breakout session during the contributor summit took an extended form,
-with two further sessions on the main conference days organized by the
-[golang-tools](https://github.com/golang/go/wiki/golang-tools) group.
-This summary is broken down into two parts: the tools session at the contributor workshop,
-and a combined report from the golang-tools sessions on the main conference days.
-
-**Contributor summit**.
-The tools session started with introductions from ~25 folks gathered,
-followed by a brainstorming of topics, including:
-gopls, ARM 32-bit, eval, signal, analysis, go/packages api, refactoring, pprof,
-module experience, mono repo analysis, go mobile, dependencies, editor integrations,
-compiler opt decisions, debugging, visualization, documentation.
-A lot of people with lots of interest in lots of tools!
-
-The session focused on two areas (all that time allowed): gopls and visualizations.
-[Gopls](https://golang.org/wiki/gopls) (pronounced: “go please”) is an implementation of the
-[Language Server Protocol (LSP)](https://langserver.org) server for Go.
-Rebecca Stamber, the gopls lead author, and the rest of the Go tools team were interested
-in hearing people’s experiences with gopls: stability, missing features, integrations in editors working, etc?
-The general feeling was that gopls was in really good shape and working extremely well for the majority of use cases.
-Integration test coverage needs to be improved, but this is a hard problem to get “right” across all editors.
-We discussed a better means of users reporting gopls errors they encounter via their editor,
-telemetry/diagnostics, gopls performance metrics, all subjects that got more detailed coverage
-in golang-tools sessions that followed on the main conference days (see below).
-A key area of discussion was how to extend gopls, e.g., in the form of
-additional go/analysis vet-like checks, lint checks, refactoring, etc.
-Currently there is no good solution, but it’s actively under investigation.
-Conversation shifted to the very broad topic of visualizations, with a
-demo-based introduction from Anthony Starks (who, incidentally, gave an excellent talk about
-[Go for information displays](https://www.youtube.com/watch?v=NyDNJnioWhI) at GopherCon 2018).
-
-**Conference days**.
-The golang-tools sessions on the main conference days were a continuation of the
-[monthly calls](https://golang.org/wiki/golang-tools) that have been happening since the group’s inception at GopherCon 2018.
-Full notes are available for the
-[day 1](https://docs.google.com/document/d/1-RVyttQ0ncjCpR_sRwizf-Ubedkr0Emwmk2LhnsUOmE/edit) and
-[day 2](https://docs.google.com/document/d/1ZI_WqpLCB8DO6teJ3aBuXTeYD2iZZZlkDptmcY6Ja60/edit#heading=h.x9lkytc2gxmg) sessions.
-These sessions were again well attended with 25-30 people at each session.
-The Go tools team was there in strength (a good sign of the support being put behind this area), as was the Uber platform team.
-In contrast to the contributor summit, the goal from these sessions was to come away with specific action items.
-
-**Gopls**.
-Gopls “readiness” was a major focus for both sessions.
-This answer effectively boiled down to determining when it makes sense to tell
-editor integrators “we have a good first cut of gopls” and then compiling a
-list of “blessed” editor integrations/plugins known to work with gopls.
-Central to this “certification” of editor integrations/plugins is a well-defined process
-by which users can report problems they experience with gopls.
-Performance and memory are not blockers for this initial “release”.
-The conversation about how to extend gopls, started in the
-contributor summit the day before, continued in earnest.
-Despite the many obvious benefits and attractions to extending gopls
-(custom go/analysis checks, linter support, refactoring, code generation…),
-there isn’t a clear answer on how to implement this in a scalable way.
-Those gathered agreed that this should not be seen as a blocker for the
-initial “release”, but should continue to be worked on.
-In the spirit of gopls and editor integrations,
-Heschi Kreinick from the Go tools team brought up the topic of debugging support.
-Delve has become the de facto debugger for Go and is in good shape;
-now the state of debugger-editor integration needs to be established,
-following a process similar to that of gopls and the “blessed” integrations.
-
-**Go Discovery Site**.
-The second golang-tools session started with an excellent introduction to
-the Go Discovery Site by Julie Qiu from the Go tools team, along with a quick demo.
-Julie talked about the plans for the Discovery Site: open sourcing the project,
-what signals are used in search ranking, how [godoc.org](http://godoc.org/) will ultimately be replaced,
-how submodules should work, how users can discover new major versions.
-
-**Build Tags**.
-Conversation then moved to build tag support within gopls.
-This is an area that clearly needs to be better understood
-(use cases are currently being gathered in [issue 33389](https://golang.org/issue/33389)).
-In light of this conversation, the session wrapped up with
-Alexander Zolotov from the JetBrains GoLand team suggesting that the gopls and
-GoLand teams should share experience in this and more areas, given GoLand
-has already gained lots of experience.
-
-**Join Us!**
-We could easily have talked about tools-related topics for days!
-The good news is that the golang-tools calls will continue for the foreseeable future.
-Anyone interested in Go tooling is very much encouraged to join: [the wiki](https://golang.org/wiki/golang-tools) has more details.
-
-## Enterprise Use (report by Daniel Theophanes)
-
-Actively asking after the needs of less vocal developers will be the largest challenge,
-and greatest win, for the Go language. There is a large segment of programmers
-who don’t actively participate in the Go community.
-Some are business associates, marketers, or quality assurance who also do development.
-Some will wear management hats and make hiring or technology decisions.
-Others just do their job and return to their families.
-And lastly, many times these developers work in businesses with strict IP protection contracts.
-Even though most of these developers won’t end up directly participating in open source
-or the Go community proposals, their ability to use Go depends on both.
-
-The Go community and Go proposals need to understand the needs of these less vocal developers.
-Go proposals can have a large impact on what is adopted and used.
-For instance, the vendor folder and later the Go modules proxy are incredibly important
-for businesses that strictly control source code and
-typically have fewer direct conversations with the Go community.
-Having these mechanisms allow these organizations to use Go at all.
-It follows that we must not only pay attention to current Go users,
-but also to developers and organizations who have considered Go,
-but have chosen against it.
-We need to understand these reasons.
-
-Similarly, should the Go community pay attention to “enterprise”
-environments it would unlock many additional organizations who can utilize Go.
-By ensuring active directory authentication works, users who would
-be forced to use a different ecosystem can keep Go on the table.
-By ensuring WSDL just works, a section of users can pick Go up as a tool.
-No one suggested blindly making changes to appease non-Go users.
-But rather we should be aware of untapped potential and unrecognized
-hindrances in the Go language and ecosystem.
-
-While several different possibilities to actively solicit this information
-from the outside was discussed, this is a problem we fundamentally need your help.
-If you are in an organization that doesn’t use Go even though it was considered,
-let us know why Go wasn’t chosen.
-If you are in an organization where Go is only used for a subsection of programming tasks,
-but not others, why isn’t it used for more? Are there specific blockers to adoption?
-
-## Education (report by Andy Walker)
-
-One of the roundtables I was involved in at the Contributors Summit
-this year was on the topic of Go education,
-specifically what kind of resources we make available
-to the new Go programmer, and how we can improve them.
-Present were a number of very passionate organizers, engineers and educators,
-each of whom had a unique perspective on the subject,
-either through tools they’d designed,
-documents they’d written or workshops they’d given to developers of all stripes.
-
-Early on, talk turned to whether or not Go makes a good first programming language.
-I wasn’t sure, and advocated against it.
-Go isn’t a good first language, I argued, because it isn’t intended to be.
-As Rob Pike [wrote back in 2012](https://talks.golang.org/2012/splash.article),
-“the language was designed by and for people who write—and read and debug and maintain—large software systems”.
-To me, this guiding ethos is clear: Go is a deliberate response to perceived flaws
-in the processes used by experienced engineers, not an attempt to create an ideal
-programming language, and as such a certain basic familiarity with programming concepts is assumed.
-
-This is evident in the official documentation at [golang.org/doc](https://golang.org/doc/).
-It jumps right into how to install the language before passing the user on to the
-[tour](https://tour.golang.org/), which is geared towards programmers
-who are already familiar with a C-like language.
-From there, they are taken to [How to Write Go Code](https://golang.org/doc/code.html),
-which provides a very basic introduction to the classic non-module Go workspace,
-before moving immediately on to writing libraries and testing.
-Finally, we have [Effective Go](https://golang.org/doc/effective_go.html),
-and a series of references including the [spec](https://golang.org/ref/spec),
-rounded out by some examples.
-These are all decent resources if you’re already familiar with a C-like language,
-but they still leave a lot to be desired, and there’s nothing to be found
-for the raw beginner or even someone coming directly from a language like Python.
-
-As an accessible, interactive starting point, the tour is a natural first target
-towards making the language more beginner friendly,
-and I think a lot of headway can be made targeting that alone.
-First, it should be the first link in the documentation,
-if not the first link in the bar at the top of golang.org, front and center.
-We should encourage the curious user to jump right in and start playing with the language.
-We should also consider including optional introductory sections on coming
-from other common languages, and the differences they are
-likely to encounter in Go, with interactive exercises.
-This would go a long way to helping new Go programmers in mapping
-the concepts they are already familiar with onto Go.
-
-For experienced programmers, an optional, deeper treatment should be given
-to most sections in the tour, allowing them to drill down into more
-detailed documentation or interactive exercises enumerating the
-design decisions principles of good architecture in Go.
-They should find answers to questions like:
-
-  - Why are there so many integer types when I am encouraged to use `int` most of the time?
-  - Is there ever a good reason to pick a value receiver?
-  - Why is there a plain `int`, but no plain `float`?
-  - What are send- and receive-only channels, and when would I use them?
-  - How do I effectively compose concurrency primitives, and when would I _not_ want to use channels?
-  - What is `uint` good for? Should I use it to restrict my user to positive values? Why not?
-
-The tour should be someplace they can revisit upon finishing the first run-through
-to dive more deeply into some of the more interesting choices in language design.
-
-But we can do more. Many people seek out programming as a way to design
-applications or scratch a particular itch, and they are most likely to want
-to target the interface they are most familiar with: the browser.
-Go does not have a good front-end story yet.
-Javascript is still the only language that really provides
-both a frontend and a backend environment,
-but WASM is fast becoming a first-order platform,
-and there are so many places we could go with that.
-We could provide something like [vecty](https://github.com/gopherjs/vecty)
-in [The Go Play Space](https://goplay.space/),
-or perhaps [Gio](https://gioui.org/), targeting WASM, for people to get
-started programming in the browser right away, inspiring their imagination,
-and provide them a migration path out of our playground into
-a terminal and onto GitHub.
-
-So, is Go a good first language?
-I honestly don’t know, but it’s certainly true there are a significant
-number of people entering the programming profession
-with Go as their starting point, and I am very interested in talking to them,
-learning about their journey and their process,
-and shaping the future of Go education with their input.
-
-## Learning Platforms (report by Ronna Steinberg)
-
-We discussed what a learning platform for Go should look like
-and how we can combine global resources to effectively teach the language.
-We generally agreed that teaching and learning is easier with visualization
-and that a REPL is very gratifying.
-We also overviewed some existing solutions for visualization with Go:
-templates, Go WASM, GopherJS as well as SVG and GIFs generation.
-
-Compiler errors not making sense to the new developer was also brought up
-and we considered ideas of how to handle it, perhaps a bank of errors and how they would be useful.
-One idea was a wrapper for the compiler that explains your errors to you, with examples and solutions.
-
-A new group convened for a second round later and we focused more on
-what UX should the Go learning platform have,
-and if and how we can take existing materials (talks, blog posts, podcasts, etc)
-from the community and organize them into a program people can learn from.
-Should such a platform link to those external resources?
-Embed them?
-Cite them?
-We agreed that a portal-like-solution (of external links to resources)
-makes navigation difficult and takes away from the learning experience,
-which led us to the conclusion that such contribution cannot be passive,
-and contributors will likely have to opt-in to have their material on the platform.
-There was then much excitement around the idea of adding a voting mechanism to the platform,
-effectively turning the learners into contributors, too,
-and incentivizing the contributors to put their materials on the platform.
-
-(If you are interested in helping in educational efforts for Go,
-please email Carmen Andoh candoh@google.com.)
-
-## Thank You!
-
-Thanks to all the attendees for the excellent discussions on contributor day,
-and thanks especially to Lynn, Paul, Daniel, Andy, and Ronna
-for taking the time to write these reports.
diff --git a/_content/contributors-summit-2019/group.jpg b/_content/contributors-summit-2019/group.jpg
deleted file mode 100644
index 4c7a2ee..0000000
--- a/_content/contributors-summit-2019/group.jpg
+++ /dev/null
Binary files differ
diff --git a/_content/contributors-summit.article b/_content/contributors-summit.article
deleted file mode 100644
index 86e6d94..0000000
--- a/_content/contributors-summit.article
+++ /dev/null
@@ -1,169 +0,0 @@
-# Contributors Summit
-3 Aug 2017
-Tags: community
-Summary: Reporting from the Go Contributor Summit at GopherCon 2017.
-
-Sam Whited
-
-## Introduction
-
-The day before GopherCon, a group of Go team members and contributors gathered
-in Denver to discuss and plan for the future of the Go project.
-This was the first ever event of its kind, a major milestone for the Go project.
-The event comprised a morning session revolving around focused discussions on a
-theme, and an afternoon session made up of round table discussions in small
-break-out groups.
-
-### Compiler and runtime
-
-The compiler and runtime session started out with a discussion about refactoring
-`gc` and related tools into importable packages.
-This would reduce overhead in the core tools and in IDEs which could embed the
-compiler themselves to do quick syntax checking.
-Code could also be compiled entirely in memory, which is useful in environments
-that don't provide a filesystem, or to run tests continually while you develop
-to get a live report of breakages.
-More discussion about whether or not to pursue this line of work will most
-likely be brought up on the mailing lists in the future.
-
-There was also a great deal of discussion around bridging the gap between
-optimized assembly code and Go.
-Most crypto code in Go is written in assembly for performance reasons; this
-makes it hard to debug, maintain, and read.
-Furthermore, once you've ventured into writing assembly, you often can't call
-back into Go, limiting code reuse.
-A rewrite in Go would make maintenance easier.
-Adding processor intrinsics and better support for 128-bit math would improve
-Go's crypto performance.
-It was proposed that the new `math/bits` package coming in 1.9 could be expanded
-for this purpose.
-
-Not being all that familiar with the development of the compiler and runtime,
-this for me was one of the more interesting sessions of the day.
-I learned a lot about the current state of the world, the problems, and where
-people want to go from here.
-
-### Dependency management
-
-After a quick update from the [dep](https://github.com/golang/dep) team on the
-status of the project, the dependency management session gravitated towards how
-the Go world will work once dep (or something dep-like) becomes the primary
-means of package management.
-Work to make Go easier to get started with and make dep easier to use has
-already started.
-In Go 1.8, a default value for `GOPATH` was introduced, meaning users will only
-have to add Go's bin directory to their `$PATH` before they can get started
-with dep.
-
-Another future usability improvement that dep might enable, is allowing Go to
-work from any directory (not just a workspace in the GOPATH), so that people can
-use the directory structures and workflows they're used to using with other
-languages.
-It may also be possible to make `go install` easier in the future by guiding
-users through the process of adding the bin directory to their path, or even
-automating the process.
-There are many good options for making the Go tooling easier to use, and
-discussion will likely continue on the mailing lists.
-
-### The standard library
-
-The discussions we had around the future of the Go language are mostly covered
-in Russ Cox's blog post: [Toward Go 2](https://blog.golang.org//toward-go2), so
-let's move on to the standard library session.
-
-As a contributor to the standard library and subrepos, this session was
-particularly interesting to me.
-What goes in the standard library and subrepos, and how much it can change, is a
-topic that isn't well defined.
-It can be hard on the Go team to maintain a huge number of packages when they
-may or may not have anyone with specific expertise in the subject matter.
-To make critical fixes to packages in the standard library, one must wait 6
-months for a new version of Go to ship (or a point release has to be shipped in
-the case of security issues, which drains team resources).
-Better dependency management may facilitate the migration of some packages out
-of the standard library and into their own projects with their own release
-schedules.
-
-There was also some discussion about things that are difficult to achieve with
-the interfaces in the standard library.
-For instance, it would be nice if `io.Reader` accepted a context so that
-blocking read operations could be canceled.
-
-More [experience reports](https://golang.org/wiki/experiencereports) are
-necessary before we can determine what will change in the standard library.
-
-### Tooling and editors
-
-A language server for editors to use was a hot topic in the tooling session,
-with a number of people advocating for IDE and tool developers to adopt a common
-"Go Language Server" to index and display information about code and packages.
-Microsoft's [Language Server Protocol](https://www.github.com/Microsoft/language-server-protocol)
-was suggested as a good starting point because of its wide support in editors
-and IDEs.
-
-Jaana Burcu Dogan also discussed her work on distributed tracing and how
-information about runtime events could be made easier to acquire and attached to
-traces.
-Having a standard "counter" API to report statistics was proposed, but specific
-experience reports from the community will be required before such an API can be
-designed.
-
-### The contributor experience
-
-The final session of the day was on the contributor experience.
-The first discussion was all about how the current Gerrit workflow could be made
-easier for new contributors which has already resulted in improvements to the
-documentation for several repos, and influenced the new contributors workshop a
-few days later!
-
-Making it easier to find tasks to work on, empowering users to perform gardening
-tasks on the issue tracker, and making it easier to find reviewers were also
-considered.
-Hopefully we'll see improvements to these and many more areas of the
-contribution process in the coming weeks and months!
-
-### Breakout sessions
-
-In the afternoon, participants broke out into smaller groups to have more
-in-depth discussions about some of the topics from the morning session.
-These discussions had more specific goals.
-For example, one group worked on identifying the useful parts of an experience
-report and a list of existing literature documenting Go user experiences,
-resulting in the experience report
-[wiki page](https://golang.org/wiki/experiencereports).
-
-Another group considered the future of errors in Go.
-Many Go users are initially confused by, or don't understand the fact that
-`error` is an interface, and it can be difficult to attach more information to
-errors without masking sentinel errors such as `io.EOF`.
-The breakout session discussed specific ways it might be possible to fix some of
-these issues in upcoming Go releases, but also ways error handling could be
-improved in Go 2.
-
-## Community
-
-Outside of the technical discussions, the summit also provided an opportunity
-for a group of people from all over the world who often talk and work together
-to meet in person, in many cases for the first time.
-There is no substitute for a little face-to-face time to build a sense of mutual
-respect and comradeship, which is critical when a diverse group with different
-backgrounds and ideas needs to come together to work in a single community.
-During the breaks, Go team members dispersed themselves among the contributors
-for discussions both about Go and a little general socialization, which really
-helped to put faces to the names that review our code every day.
-
-As Russ discussed in [Toward Go 2](https://blog.golang.org//toward-go2),
-communicating effectively requires knowing your audience.
-Having a broad sample of Go contributors in a room together helped us all to
-understand the Go audience better and start many productive discussions about
-the future of Go.
-Going forward, we hope to do more frequent events like this to facilitate
-discourse and a sense of community.
-
-.image contributors-summit/IMG_20170712_145844.jpg
-.image contributors-summit/IMG_20170712_145854.jpg
-.image contributors-summit/IMG_20170712_145905.jpg
-.image contributors-summit/IMG_20170712_145911.jpg
-.image contributors-summit/IMG_20170712_145950.jpg
-
-Photos by Steve Francia
diff --git a/_content/contributors-summit/IMG_20170712_145844.jpg b/_content/contributors-summit/IMG_20170712_145844.jpg
deleted file mode 100644
index 77c4bff..0000000
--- a/_content/contributors-summit/IMG_20170712_145844.jpg
+++ /dev/null
Binary files differ
diff --git a/_content/contributors-summit/IMG_20170712_145854.jpg b/_content/contributors-summit/IMG_20170712_145854.jpg
deleted file mode 100644
index 97e7072..0000000
--- a/_content/contributors-summit/IMG_20170712_145854.jpg
+++ /dev/null
Binary files differ
diff --git a/_content/contributors-summit/IMG_20170712_145905.jpg b/_content/contributors-summit/IMG_20170712_145905.jpg
deleted file mode 100644
index bd1a950..0000000
--- a/_content/contributors-summit/IMG_20170712_145905.jpg
+++ /dev/null
Binary files differ
diff --git a/_content/contributors-summit/IMG_20170712_145911.jpg b/_content/contributors-summit/IMG_20170712_145911.jpg
deleted file mode 100644
index b03f0b1..0000000
--- a/_content/contributors-summit/IMG_20170712_145911.jpg
+++ /dev/null
Binary files differ
diff --git a/_content/contributors-summit/IMG_20170712_145950.jpg b/_content/contributors-summit/IMG_20170712_145950.jpg
deleted file mode 100644
index 00f0861..0000000
--- a/_content/contributors-summit/IMG_20170712_145950.jpg
+++ /dev/null
Binary files differ
diff --git a/_content/cover.article b/_content/cover.article
deleted file mode 100644
index 7e9e629..0000000
--- a/_content/cover.article
+++ /dev/null
@@ -1,300 +0,0 @@
-# The cover story
-2 Dec 2013
-Tags: tools, coverage, testing
-Summary: Introducing Go 1.12's code coverage tool.
-
-Rob Pike
-
-## Introduction
-
-From the beginning of the project, Go was designed with tools in mind.
-Those tools include some of the most iconic pieces of Go technology such as
-the documentation presentation tool
-[godoc](https://golang.org/cmd/godoc),
-the code formatting tool
-[gofmt](https://golang.org/cmd/gofmt),
-and the API rewriter
-[gofix](https://golang.org/cmd/fix).
-Perhaps most important of all is the
-[`go` command](https://golang.org/cmd/go),
-the program that automatically installs, builds, and tests Go programs
-using nothing more than the source code as the build specification.
-
-The release of Go 1.2 introduces a new tool for test coverage that takes an
-unusual approach to the way it generates coverage statistics, an approach
-that builds on the technology laid down by godoc and friends.
-
-## Support for tools
-
-First, some background: What does it mean for a
-[language to support good tooling](https://talks.golang.org/2012/splash.article#TOC_17.)?
-It means that the language makes it easy to write good tools and that its ecosystem
-supports the construction of tools of all flavors.
-
-There are a number of properties of Go that make it suitable for tooling.
-For starters, Go has a regular syntax that is easy to parse.
-The grammar aims to be free of special cases that require complex machinery to analyze.
-
-Where possible, Go uses lexical and syntactic constructs to make semantic properties
-easy to understand.
-Examples include the use of upper-case letters to define exported names
-and the radically simplified scoping rules compared to other languages in the C tradition.
-
-Finally, the standard library comes with production-quality packages to lex and parse Go source code.
-They also include, more unusually, a production-quality package to pretty-print Go syntax trees.
-
-These packages in combination form the core of the gofmt tool, but the pretty-printer is worth singling out.
-Because it can take an arbitrary Go syntax tree and output standard-format, human-readable, correct
-code, it creates the possibility to build tools that transform the parse tree and output modified but
-correct and easy-to-read code.
-
-One example is the gofix tool, which automates the
-rewriting of code to use new language features or updated libraries.
-Gofix let us make fundamental changes to the language and libraries in the
-[run-up to Go 1.0](https://blog.golang.org/the-path-to-go-1),
-with the confidence that users could just run the tool to update their source to the newest version.
-
-Inside Google, we have used gofix to make sweeping changes in a huge code repository that would be almost
-unthinkable in the other languages we use.
-There's no need any more to support multiple versions of some API; we can use gofix to update
-the entire company in one operation.
-
-It's not just these big tools that these packages enable, of course.
-They also make it easy to write more modest programs such as IDE plugins, for instance.
-All these items build on each other, making the Go environment
-more productive by automating many tasks.
-
-## Test coverage
-
-Test coverage is a term that describes how much of a package's code is exercised by running the package's tests.
-If executing the test suite causes 80% of the package's source statements to be run, we say that the test coverage is 80%.
-
-The program that provides test coverage in Go 1.2 is the latest to exploit the tooling support in the Go ecosystem.
-
-The usual way to compute test coverage is to instrument the binary.
-For instance, the GNU [gcov](http://gcc.gnu.org/onlinedocs/gcc/Gcov.html) program sets breakpoints at branches
-executed by the binary.
-As each branch executes, the breakpoint is cleared and the target statements of the branch are marked as 'covered'.
-
-This approach is successful and widely used. An early test coverage tool for Go even worked the same way.
-But it has problems.
-It is difficult to implement, as analysis of the execution of binaries is challenging.
-It also requires a reliable way of tying the execution trace back to the source code, which can also be difficult,
-as any user of a source-level debugger can attest.
-Problems there include inaccurate debugging information and issues such as in-lined functions complicating
-the analysis.
-Most important, this approach is very non-portable.
-It needs to be done afresh for every architecture, and to some extent for every
-operating system since debugging support varies greatly from system to system.
-
-It does work, though, and for instance if you are a user of gccgo, the gcov tool can give you test coverage
-information.
-However If you're a user of gc, the more commonly used Go compiler suite, until Go 1.2 you were out of luck.
-
-## Test coverage for Go
-
-For the new test coverage tool for Go, we took a different approach that avoids dynamic debugging.
-The idea is simple: Rewrite the package's source code before compilation to add instrumentation,
-compile and run the modified source, and dump the statistics.
-The rewriting is easy to arrange because the `go` command controls the flow
-from source to test to execution.
-
-Here's an example. Say we have a simple, one-file package like this:
-
-.code cover/pkg.go
-
-and this test:
-
-.code cover/pkg_test.go
-
-To get the test coverage for the package,
-we run the test with coverage enabled by providing the `-cover` flag to `go` `test`:
-
-	% go test -cover
-	PASS
-	coverage: 42.9% of statements
-	ok  	size	0.026s
-	%
-
-Notice that the coverage is 42.9%, which isn't very good.
-Before we ask how to raise that number, let's see how that was computed.
-
-When test coverage is enabled, `go` `test` runs the "cover" tool, a separate program included
-with the distribution, to rewrite the source code before compilation. Here's what the rewritten
-`Size` function looks like:
-
-.code cover/pkg.cover /func/,/^}/
-
-Each executable section of the program is annotated with an assignment statement that,
-when executed, records that that section ran.
-The counter is tied to the original source position of the statements it counts
-through a second read-only data structure that is also generated by the cover tool.
-When the test run completes, the counters are collected and the percentage is computed
-by seeing how many were set.
-
-Although that annotating assignment might look expensive, it compiles to a single "move" instruction.
-Its run-time overhead is therefore modest, adding only about 3% when running a typical (more realistic) test.
-That makes it reasonable to include test coverage as part of the standard development pipeline.
-
-## Viewing the results
-
-The test coverage for our example was poor.
-To discover why, we ask `go` `test` to write a "coverage profile" for us, a file that holds
-the collected statistics so we can study them in more detail.
-That's easy to do: use the `-coverprofile` flag to specify a file for the output:
-
-	% go test -coverprofile=coverage.out
-	PASS
-	coverage: 42.9% of statements
-	ok  	size	0.030s
-	%
-
-(The `-coverprofile` flag automatically sets `-cover` to enable coverage analysis.)
-The test runs just as before, but the results are saved in a file.
-To study them, we run the test coverage tool ourselves, without `go` `test`.
-As a start, we can ask for the coverage to be broken down by function,
-although that's not going to illuminate much in this case since there's
-only one function:
-
-	% go tool cover -func=coverage.out
-	size.go:	Size          42.9%
-	total:      (statements)  42.9%
-	%
-
-A much more interesting way to see the data is to get an HTML presentation
-of the source code decorated with coverage information.
-This display is invoked by the `-html` flag:
-
-	$ go tool cover -html=coverage.out
-
-When this command is run, a browser window pops up, showing the covered (green),
-uncovered (red), and uninstrumented (grey) source.
-Here's a screen dump:
-
-.image cover/set.png
-
-With this presentation, it's obvious what's wrong: we neglected to test several
-of the cases!
-And we can see exactly which ones they are, which makes it easy to
-improve our test coverage.
-
-## Heat maps
-
-A big advantage of this source-level approach to test coverage is that it's
-easy to instrument the code in different ways.
-For instance, we can ask not only whether a statement has been executed,
-but how many times.
-
-The `go` `test` command accepts a `-covermode` flag to set the coverage mode
-to one of three settings:
-
-  - set:    did each statement run?
-  - count:  how many times did each statement run?
-  - atomic: like count, but counts precisely in parallel programs
-
-The default is 'set', which we've already seen.
-The `atomic` setting is needed only when accurate counts are required
-when running parallel algorithms. It uses atomic operations from the
-[sync/atomic](https://golang.org/pkg/sync/atomic/) package,
-which can be quite expensive.
-For most purposes, though, the `count` mode works fine and, like
-the default `set` mode, is very cheap.
-
-Let's try counting statement execution for a standard package, the `fmt` formatting package.
-We run the test and write out a coverage profile so we can present the information
-nicely afterwards.
-
-	% go test -covermode=count -coverprofile=count.out fmt
-	ok  	fmt	0.056s	coverage: 91.7% of statements
-	%
-
-That's a much better test coverage ratio than for our previous example.
-(The coverage ratio is not affected by the coverage mode.)
-We can display the function breakdown:
-
-	% go tool cover -func=count.out
-	fmt/format.go: init              100.0%
-	fmt/format.go: clearflags        100.0%
-	fmt/format.go: init              100.0%
-	fmt/format.go: computePadding     84.6%
-	fmt/format.go: writePadding      100.0%
-	fmt/format.go: pad               100.0%
-	...
-	fmt/scan.go:   advance            96.2%
-	fmt/scan.go:   doScanf            96.8%
-	total:         (statements)       91.7%
-
-The big payoff happens in the HTML output:
-
-	% go tool cover -html=count.out
-
-Here's what the `pad` function looks like in that presentation:
-
-.image cover/count.png
-
-Notice how the intensity of the green changes. Brighter-green
-statements have higher execution counts; less saturated greens
-represent lower execution counts.
-You can even hover the mouse over the statements to see the
-actual counts pop up in a tool tip.
-At the time of writing, the counts come out like this
-(we've moved the counts from the tool tips to beginning-of-line
-markers to make them easier to show):
-
-	2933    if !f.widPresent || f.wid == 0 {
-	2985        f.buf.Write(b)
-	2985        return
-	2985    }
-	  56    padding, left, right := f.computePadding(len(b))
-	  56    if left > 0 {
-	  37        f.writePadding(left, padding)
-	  37    }
-	  56    f.buf.Write(b)
-	  56    if right > 0 {
-	  13        f.writePadding(right, padding)
-	  13    }
-
-That's a lot of information about the execution of the function,
-information that might be useful in profiling.
-
-## Basic blocks
-
-You might have noticed that the counts in the previous example
-were not what you expected on the lines with closing braces.
-That's because, as always, test coverage is an inexact science.
-
-What's going on here is worth explaining, though. We'd like the
-coverage annotations to be demarcated by branches in the program,
-the way they are when the binary is instrumented in the traditional
-method.
-It's hard to do that by rewriting the source, though, since
-the branches don't appear explicitly in the source.
-
-What the coverage annotation does is instrument blocks, which
-are typically bounded by brace brackets.
-Getting this right in general is very hard.
-A consequence of the algorithm used is that the closing
-brace looks like it belongs to the block it closes, while the
-opening brace looks like it belongs outside the block.
-A more interesting consequence is that in an expression like
-
-	f() && g()
-
-there is no attempt to separately instrument the calls to `f` and `g`, Regardless of
-the facts it will always look like they both ran the same
-number of times, the number of times `f` ran.
-
-To be fair, even `gcov` has trouble here. That tool gets the
-instrumentation right but the presentation is line-based and
-can therefore miss some nuances.
-
-## The big picture
-
-That's the story about test coverage in Go 1.2.
-A new tool with an interesting implementation enables not only
-test coverage statistics, but easy-to-interpret presentations
-of them and even the possibility to extract profiling information.
-
-Testing is an important part of software development and test
-coverage a simple way to add discipline to your testing strategy.
-Go forth, test, and cover.
diff --git a/_content/cover/count.png b/_content/cover/count.png
deleted file mode 100644
index 2c66956..0000000
--- a/_content/cover/count.png
+++ /dev/null
Binary files differ
diff --git a/_content/cover/pkg.cover b/_content/cover/pkg.cover
deleted file mode 100644
index 03a8cbc..0000000
--- a/_content/cover/pkg.cover
+++ /dev/null
@@ -1,49 +0,0 @@
-package main
-
-func Size(a int) string {
-	GoCover.Count[0] = 1
-	switch {
-	case a < 0:
-		GoCover.Count[2] = 1
-		return "negative"
-	case a == 0:
-		GoCover.Count[3] = 1
-		return "zero"
-	case a < 10:
-		GoCover.Count[4] = 1
-		return "small"
-	case a < 100:
-		GoCover.Count[5] = 1
-		return "big"
-	case a < 1000:
-		GoCover.Count[6] = 1
-		return "huge"
-	}
-	GoCover.Count[1] = 1
-	return "enormous"
-}
-
-var GoCover = struct {
-	Count     [7]uint32
-	Pos       [3 * 7]uint32
-	NumStmt   [7]uint16
-} {
-	Pos: [3 * 7]uint32{
-		3, 4, 0x90019, // [0]
-		16, 16, 0x130002, // [1]
-		5, 6, 0x140002, // [2]
-		7, 8, 0x100002, // [3]
-		9, 10, 0x110002, // [4]
-		11, 12, 0xf0002, // [5]
-		13, 14, 0x100002, // [6]
-	},
-	NumStmt: [7]uint16{
-		1, // 0
-		1, // 1
-		1, // 2
-		1, // 3
-		1, // 4
-		1, // 5
-		1, // 6
-	},
-}
diff --git a/_content/cover/pkg.go b/_content/cover/pkg.go
deleted file mode 100644
index 6e67107..0000000
--- a/_content/cover/pkg.go
+++ /dev/null
@@ -1,17 +0,0 @@
-package size
-
-func Size(a int) string {
-	switch {
-	case a < 0:
-		return "negative"
-	case a == 0:
-		return "zero"
-	case a < 10:
-		return "small"
-	case a < 100:
-		return "big"
-	case a < 1000:
-		return "huge"
-	}
-	return "enormous"
-}
diff --git a/_content/cover/pkg_test.go b/_content/cover/pkg_test.go
deleted file mode 100644
index 8bf4b0c..0000000
--- a/_content/cover/pkg_test.go
+++ /dev/null
@@ -1,22 +0,0 @@
-package size
-
-import "testing"
-
-type Test struct {
-	in  int
-	out string
-}
-
-var tests = []Test{
-	{-1, "negative"},
-	{5, "small"},
-}
-
-func TestSize(t *testing.T) {
-	for i, test := range tests {
-		size := Size(test.in)
-		if size != test.out {
-			t.Errorf("#%d: Size(%d)=%s; want %s", i, test.in, size, test.out)
-		}
-	}
-}
diff --git a/_content/cover/set.png b/_content/cover/set.png
deleted file mode 100644
index d4cfca2..0000000
--- a/_content/cover/set.png
+++ /dev/null
Binary files differ
diff --git a/_content/cwg.article b/_content/cwg.article
deleted file mode 100644
index 0e17def..0000000
--- a/_content/cwg.article
+++ /dev/null
@@ -1,55 +0,0 @@
-# Community Outreach Working Group
-5 Sep 2017
-Tags: community
-Summary: Announcing the Go Community Outreach Working Group (CWG).
-OldURL: /community-outreach-working-group
-
-Steve Francia & Cassandra Salisbury
-spf@golang.org
-
-## Announcing the Go Community Outreach Working Group
-
-The Go project has grown considerably with over half a million users and
-community members all over the world. To date all community oriented activities
-have been organized by the community with minimal involvement from the Go
-project. We greatly appreciate these efforts.
-
-After talking to many community organizers we have heard consistent
-feedback that they would like better collaboration between organizers and
-the Go project. We are forming the Community outreach Working Group (CWG)
-to help support these community efforts.
-
-## The CWG Mission
-
-The mission of the CWG is to act as a conduit between the broader Go
-community, it’s organizers and the Go project. The CWG will help provide
-the structures and community management necessary to create an online and
-in person community that is enjoyable and rewarding to participate in. The
-CWG leadership represents the Go project in these efforts.
-
-**The CWG is responsible for:**
-
-  - Defining programs to facilitate deeper collaboration across the community.
-  - Facilitating the coordination of Go events
-  - Establishing growth and expansion plans for the community
-  - Project exposure and accessibility
-  - Ecosystem Development
-
-**Leadership:**
-
-  - [Ashley McNamara](https://twitter.com/ashleymcnamara)
-  - [Cassandra Salisbury](https://twitter.com/Cassandraoid)
-  - [Francesc Campoy](https://twitter.com/francesc)
-  - [Steve Francia](https://twitter.com/spf13)
-
-## Plans for Action
-
-The CWG has an [open GitHub repo](https://github.com/golang/cwg) we’ve created for complete transparency
-of our efforts.  We have various [GitHub projects](https://github.com/golang/cwg/projects) which are acting as our
-primary initiatives. Each project has a variety of [issues](https://github.com/golang/cwg/issues) tied to them
-with assignees from our Leadership team and [our members](https://github.com/golang/cwg/issues/15).
-
-.image cwg/project.png
-
-If you’d like to get involved, we encourage you to comment on the issue
-that interests you or [submit an issue](https://github.com/golang/cwg/issues/new) yourself!
diff --git a/_content/cwg/project.png b/_content/cwg/project.png
deleted file mode 100644
index 3619ebd..0000000
--- a/_content/cwg/project.png
+++ /dev/null
Binary files differ
diff --git a/_content/debug-gdb.article b/_content/debug-gdb.article
deleted file mode 100644
index ff24c4f..0000000
--- a/_content/debug-gdb.article
+++ /dev/null
@@ -1,20 +0,0 @@
-# Debugging Go programs with the GNU Debugger
-30 Oct 2011
-Tags: debug, gdb, technical
-Summary: Announcing a new article about debugging Go programs with GDB.
-OldURL: /debugging-go-programs-with-gnu-debugger
-
-Andrew Gerrand
-
-##
-
-Last year we [reported](https://blog.golang.org/2010/11/debugging-go-code-status-report.html)
-that Go's [gc](https://golang.org/cmd/gc/)/[ld](https://golang.org/cmd/6l/)
-toolchain produces DWARFv3 debugging information that can be read by the GNU Debugger (GDB).
-Since then, work has continued steadily on improving support for debugging Go code with GDB.
-Among the improvements are the ability to inspect goroutines and to print
-native Go data types,
-including structs, slices, strings, maps,
-interfaces, and channels.
-
-To learn more about Go and GDB, see the [Debugging with GDB](https://golang.org/doc/debugging_with_gdb.html) article.
diff --git a/_content/debug-opt.article b/_content/debug-opt.article
deleted file mode 100644
index 002181b..0000000
--- a/_content/debug-opt.article
+++ /dev/null
@@ -1,116 +0,0 @@
-# Debugging what you deploy in Go 1.12
-21 Mar 2019
-Tags: debug, technical
-Summary: Go 1.12 improves support for debugging optimized binaries.
-OldURL: /debugging-what-you-deploy
-
-David Chase
-
-## Introduction
-
-Go 1.11 and Go 1.12 make significant progress toward allowing developers
-to debug the same optimized binaries that they deploy to production.
-
-As the Go compiler has become increasingly aggressive in producing faster binaries,
-we've lost ground in debuggability.
-In Go 1.10, users needed to disable optimizations entirely in order to have
-a good debugging experience from interactive tools like Delve.
-But users shouldn’t have to trade performance for debuggability,
-especially when running production services.
-If your problem is occurring in production,
-you need to debug it in production, and that shouldn’t require deploying
-unoptimized binaries.
-
-For Go 1.11 and 1.12, we focused on improving the debugging experience on
-optimized binaries (the default setting of the Go compiler).
-Improvements include
-
-  - More accurate value inspection, in particular for arguments at function entry;
-  - More precisely identifying statement boundaries so that stepping is less
-    jumpy and breakpoints more often land where the programmer expects;
-  - And preliminary support for Delve to call Go functions (goroutines and
-    garbage collection make this trickier than it is in C and C++).
-
-## Debugging optimized code with Delve
-
-[Delve](https://github.com/go-delve/delve) is a debugger for Go on x86
-supporting both Linux and macOS.
-Delve is aware of goroutines and other Go features and provides one of the
-best Go debugging experiences.
-Delve is also the debugging engine behind [GoLand](https://www.jetbrains.com/go/),
-[VS Code](https://code.visualstudio.com/),
-and [Vim](https://github.com/fatih/vim-go).
-
-Delve normally rebuilds the code it is debugging with `-gcflags "all=-N -l"`,
-which disables inlining and most optimizations.
-To debug optimized code with delve, first build the optimized binary,
-then use `dlv exec your_program` to debug it.
-Or, if you have a core file from a crash,
-you can examine it with `dlv core your_program your_core`.
-With 1.12 and the latest Delve releases, you should be able to examine many variables,
-even in optimized binaries.
-
-## Improved value inspection
-
-When debugging optimized binaries produced by Go 1.10,
-variable values were usually completely unavailable.
-In contrast, starting with Go 1.11, variables can usually be examined even
-in optimized binaries,
-unless they’ve been optimized away completely.
-In Go 1.11 the compiler began emitting DWARF location lists so debuggers
-can track variables as they move in and out of registers and reconstruct
-complex objects that are split across different registers and stack slots.
-
-## Improved stepping
-
-This shows an example of stepping through a simple function in a debugger in 1.10,
-with flaws (skipped and repeated lines) highlighted by red arrows.
-
-.image debug-opt/stepping.svg _ 450
-
-Flaws like this make it easy to lose track of where you are when stepping
-through a program and interfere with hitting breakpoints.
-
-Go 1.11 and 1.12 record statement boundary information and do a better job
-of tracking source line numbers through optimizations and inlining.
-As a result, in Go 1.12, stepping through this code stops on every line
-and does so in the order you would expect.
-
-## Function calls
-
-Function call support in Delve is still under development, but simple cases work.  For example:
-
-	(dlv) call fib(6)
-	> main.main() ./hello.go:15 (PC: 0x49d648)
-	Values returned:
-		~r1: 8
-
-## The path forward
-
-Go 1.12 is a step toward a better debugging experience for optimized binaries
-and we have plans to improve it even further.
-
-There are fundamental tradeoffs between debuggability and performance,
-so we’re focusing on the highest-priority debugging defects,
-and working to collect automated metrics to monitor our progress and catch regressions.
-
-We’re focusing on generating correct information for debuggers about variable locations,
-so if a variable can be printed, it is printed correctly.
-We’re also looking at making variable values available more of the time,
-particularly at key points like call sites,
-though in many cases improving this would require slowing down program execution.
-Finally, we’re working on improving stepping:
-we’re focusing on the order of stepping with panics,
-the order of stepping around loops, and generally trying to follow source
-order where possible.
-
-## A note on macOS support
-
-Go 1.11 started compressing debug information to reduce binary sizes.
-This is natively supported by Delve, but neither LLDB nor GDB support compressed
-debug info on macOS.
-If you are using LLDB or GDB, there are two workarounds:
-build binaries with `-ldflags=-compressdwarf=false`,
-or use [splitdwarf](https://godoc.org/golang.org/x/tools/cmd/splitdwarf)
-(`go get golang.org/x/tools/cmd/splitdwarf`) to decompress the debug information
-in an existing binary.
diff --git a/_content/debug-opt/stepping.graffle b/_content/debug-opt/stepping.graffle
deleted file mode 100644
index 6deefa7..0000000
--- a/_content/debug-opt/stepping.graffle
+++ /dev/null
Binary files differ
diff --git a/_content/debug-opt/stepping.svg b/_content/debug-opt/stepping.svg
deleted file mode 100644
index fb39be5..0000000
--- a/_content/debug-opt/stepping.svg
+++ /dev/null
@@ -1,59 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE svg  PUBLIC '-//W3C//DTD SVG 1.1//EN'  'http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd'>
-<svg width="355.46" height="208" version="1.1" viewBox="55.075 95.5 355.4621 208" xmlns="http://www.w3.org/2000/svg" xmlns:dc="http://purl.org/dc/elements/1.1/">
-<defs>
-<marker id="a" color="#ff2600" overflow="visible" stroke-miterlimit="10" markerHeight="8" markerWidth="10" orient="auto" viewBox="-1 -4 10 8">
-<path d="m8 0l-8-3v6z" fill="currentColor" stroke="currentColor"/>
-</marker>
-</defs>
-<metadata>Produced by OmniGraffle 7.10.1
-<dc:date>2019-03-21 19:47:24 +0000</dc:date>
-</metadata>
-<g fill="none">
-<title>Canvas 1</title>
-<g>
-<title>Layer 1</title>
-<text transform="translate(64.5 130.5)" fill="black" font-family="Go, sans-serif" font-size="12" font-weight="400">
-<tspan x="28" y="11">l := line{point{1 + zero, 2 + zero}, point{3 + zero, 4 + zero}}</tspan>
-<tspan x="28" y="25">tinycall()</tspan>
-<tspan x="28" y="39">hist := make([]int, 7)</tspan>
-<tspan x="28" y="53">var reader io.Reader = strings.NewReader(cannedInput)</tspan>
-<tspan x="28" y="67">scanner := bufio.NewScanner(reader)</tspan>
-<tspan x="28" y="81">for scanner.Scan() {</tspan>
-<tspan x="56" y="95">s := scanner.Text()</tspan>
-<tspan x="56" y="109">i, err := strconv.ParseInt(s, 10, 64)</tspan>
-<tspan x="56" y="123">if err != nil { ... }</tspan>
-<tspan x="56" y="137">hist = ensure(int(i), hist)</tspan>
-<tspan x="56" y="151">hist[int(i)]++</tspan>
-<tspan x="28" y="165">}</tspan>
-</text>
-<text transform="translate(204.34 100.5)" fill="black">
-<tspan x="0" y="15" fill="black" font-family="Go, sans-serif" font-size="16" font-weight="400">Go 1.10</tspan>
-</text>
-<path d="m71.8 130.7l14 6-14 6z" fill="blue" fill-opacity=".3309"/>
-<path d="m71.8 130.7l14 6-14 6z" stroke="#000" stroke-linecap="round" stroke-linejoin="round" stroke-width=".25"/>
-<path d="m100.6 243.3l14 6-14 6z" fill="blue" fill-opacity=".3309"/>
-<path d="m100.6 243.3l14 6-14 6z" stroke="#000" stroke-linecap="round" stroke-linejoin="round" stroke-width=".25"/>
-<path d="m100.6 229.5l14 6-14 6z" fill="blue" fill-opacity=".3309"/>
-<path d="m100.6 229.5l14 6-14 6z" stroke="#000" stroke-linecap="round" stroke-linejoin="round" stroke-width=".25"/>
-<path d="m71.8 200.74l14 6-14 6z" fill="blue" fill-opacity=".3309"/>
-<path d="m71.8 200.74l14 6-14 6z" stroke="#000" stroke-linecap="round" stroke-linejoin="round" stroke-width=".25"/>
-<path d="m71.8 172.72l14 6-14 6z" fill="blue" fill-opacity=".3309"/>
-<path d="m71.8 172.72l14 6-14 6z" stroke="#000" stroke-linecap="round" stroke-linejoin="round" stroke-width=".25"/>
-<path d="m71.8 158.72l14 6-14 6z" fill="blue" fill-opacity=".3309"/>
-<path d="m71.8 158.72l14 6-14 6z" stroke="#000" stroke-linecap="round" stroke-linejoin="round" stroke-width=".25"/>
-<path d="m55.2 145.4l14 6-14 6z" fill="blue" fill-opacity=".3309"/>
-<path d="m55.2 145.4l14 6-14 6z" stroke="#000" stroke-linecap="round" stroke-linejoin="round" stroke-width=".25"/>
-<path d="m100.6 270.9l14 6-14 6z" fill="blue" fill-opacity=".3309"/>
-<path d="m100.6 270.9l14 6-14 6z" stroke="#000" stroke-linecap="round" stroke-linejoin="round" stroke-width=".25"/>
-<path d="m100.6 257.1l14 6-14 6z" fill="blue" fill-opacity=".3309"/>
-<path d="m100.6 257.1l14 6-14 6z" stroke="#000" stroke-linecap="round" stroke-linejoin="round" stroke-width=".25"/>
-<path d="m55.2 130.7l14 6-14 6z" fill="blue" fill-opacity=".3309"/>
-<path d="m55.2 130.7l14 6-14 6z" stroke="#000" stroke-linecap="round" stroke-linejoin="round" stroke-width=".25"/>
-<path d="m61.66 147.95v-2.9031l1.6541-0.99387" marker-end="url(#a)" stroke="#ff2600" stroke-linecap="round" stroke-linejoin="round"/>
-<line x1="79.06" x2="79.06" y1="139.52" y2="152.45" marker-end="url(#a)" stroke="#ff2600" stroke-linecap="round" stroke-linejoin="round"/>
-<line x1="79.06" x2="94.381" y1="209.4" y2="228.38" marker-end="url(#a)" stroke="#ff2600" stroke-linecap="round" stroke-linejoin="round"/>
-<line x1="79.06" x2="79.115" y1="182.66" y2="194.76" marker-end="url(#a)" stroke="#ff2600" stroke-linecap="round" stroke-linejoin="round"/>
-</g>
-</g>
-</svg>
diff --git a/_content/debug-status.article b/_content/debug-status.article
deleted file mode 100644
index 1f5416b..0000000
--- a/_content/debug-status.article
+++ /dev/null
@@ -1,67 +0,0 @@
-# Debugging Go code (a status report)
-2 Nov 2010
-Tags: debug, gdb
-Summary: What works and what doesn't when debugging Go programs with GDB.
-OldURL: /debugging-go-code-status-report
-
-Luuk van Dijk
-
-##
-
-When it comes to debugging, nothing beats a few strategic print statements
-to inspect variables or a well-placed panic to obtain a stack trace.
-However, sometimes you’re missing either the patience or the source code,
-and in those cases a good debugger can be invaluable.
-That's why over the past few releases we have been improving the support
-in Go’s gc linker (6l,
-8l) for GDB, the GNU debugger.
-
-In the latest release (2010-11-02), the 6l and 8l linkers emit DWARF3 debugging
-information when writing ELF (Linux,
-FreeBSD) or Mach-O (Mac OS X) binaries.
-The DWARF code is rich enough to let you do the following:
-
-  - load a Go program in GDB version 7.x,
-  - list all Go, C, and assembly source files by line (parts of the Go runtime are written in C and assembly),
-  - set breakpoints by line and step through the code,
-  - print stack traces and inspect stack frames, and
-  - find the addresses and print the contents of most variables.
-
-There are still some inconveniences:
-
-  - The emitted DWARF code is unreadable by the GDB version 6.x that ships with Mac OS X.
-    We would gladly accept patches to make the DWARF output compatible with
-    the standard OS X GDB,
-    but until that’s fixed you’ll need to download,
-    build, and install GDB 7.x to use it under OS X.
-    The source can be found at [http://sourceware.org/gdb/download/](http://sourceware.org/gdb/download/).
-    Due to the particulars of OS X you’ll need to install the binary on a
-    local file system with `chgrp procmod` and `chmod g+s`.
-  - Names are qualified with a package name and,
-    as GDB doesn't understand Go packages, you must reference each item by its full name.
-    For example, the variable named `v` in package `main` must be referred to
-    as `'main.v'`, in single quotes.
-    A consequence of this is that tab completion of variable and function names does not work.
-  - Lexical scoping information is somewhat obfuscated.
-    If there are multiple variables of the same name,
-    the nth instance will have a suffix of the form ‘#n’.
-    We plan to fix this, but it will require some changes to the data exchanged
-    between the compiler and linker.
-  - Slice and string variables are represented as their underlying structure
-    in the runtime library.
-    They will look something like `{data = 0x2aaaaab3e320, len = 1, cap = 1}.` For slices,
-    you must dereference the data pointer to inspect the elements.
-
-Some things don't work yet:
-
-  - Channel, function, interface, and map variables cannot be inspected.
-  - Only Go variables are annotated with type information; the runtime's C variables are not.
-  - Windows and ARM binaries do not contain DWARF debugging information and, as such, cannot be inspected with GDB.
-
-Over the coming months we intend to address these issues,
-either by changing the compiler and linker or by using the Python extensions to GDB.
-In the meantime, we hope that Go programmers will benefit from having better
-access to this well-known debugging tool.
-
-P.S. The DWARF information can also be read by tools other than GDB.
-For example, on Linux you can use it with the sysprof system-wide profiler.
diff --git a/_content/declaration-syntax.article b/_content/declaration-syntax.article
deleted file mode 100644
index f1d0574..0000000
--- a/_content/declaration-syntax.article
+++ /dev/null
@@ -1,211 +0,0 @@
-# Go's Declaration Syntax
-7 Jul 2010
-Tags: c, syntax, ethos
-Summary: Why Go's declaration syntax doesn't look like, and is much simpler than, C's.
-OldURL: /gos-declaration-syntax
-
-Rob Pike
-
-## Introduction
-
-Newcomers to Go wonder why the declaration syntax is different from the
-tradition established in the C family.
-In this post we'll compare the two approaches and explain why Go's declarations look as they do.
-
-## C syntax
-
-First, let's talk about C syntax. C took an unusual and clever approach
-to declaration syntax.
-Instead of describing the types with special syntax,
-one writes an expression involving the item being declared,
-and states what type that expression will have. Thus
-
-	int x;
-
-declares x to be an int: the expression 'x' will have type int.
-In general, to figure out how to write the type of a new variable,
-write an expression involving that variable that evaluates to a basic type,
-then put the basic type on the left and the expression on the right.
-
-Thus, the declarations
-
-	int *p;
-	int a[3];
-
-state that p is a pointer to int because '\*p' has type int,
-and that a is an array of ints because a[3] (ignoring the particular index value,
-which is punned to be the size of the array) has type int.
-
-What about functions? Originally, C's function declarations wrote the types
-of the arguments outside the parens, like this:
-
-	int main(argc, argv)
-	    int argc;
-	    char *argv[];
-	{ /* ... */ }
-
-Again, we see that main is a function because the expression main(argc,
-argv) returns an int.
-In modern notation we'd write
-
-	int main(int argc, char *argv[]) { /* ... */ }
-
-but the basic structure is the same.
-
-This is a clever syntactic idea that works well for simple types but can get confusing fast.
-The famous example is declaring a function pointer.
-Follow the rules and you get this:
-
-	int (*fp)(int a, int b);
-
-Here, fp is a pointer to a function because if you write the expression (\*fp)(a,
-b) you'll call a function that returns int.
-What if one of fp's arguments is itself a function?
-
-	int (*fp)(int (*ff)(int x, int y), int b)
-
-That's starting to get hard to read.
-
-Of course, we can leave out the name of the parameters when we declare a function, so main can be declared
-
-	int main(int, char *[])
-
-Recall that argv is declared like this,
-
-	char *argv[]
-
-so you drop the name from the middle of its declaration to construct its type.
-It's not obvious, though, that you declare something of type char \*[] by
-putting its name in the middle.
-
-And look what happens to fp's declaration if you don't name the parameters:
-
-	int (*fp)(int (*)(int, int), int)
-
-Not only is it not obvious where to put the name inside
-
-	int (*)(int, int)
-
-it's not exactly clear that it's a function pointer declaration at all.
-And what if the return type is a function pointer?
-
-	int (*(*fp)(int (*)(int, int), int))(int, int)
-
-It's hard even to see that this declaration is about fp.
-
-You can construct more elaborate examples but these should illustrate some
-of the difficulties that C's declaration syntax can introduce.
-
-There's one more point that needs to be made, though.
-Because type and declaration syntax are the same,
-it can be difficult to parse expressions with types in the middle.
-This is why, for instance, C casts always parenthesize the type, as in
-
-	(int)M_PI
-
-## Go syntax
-
-Languages outside the C family usually use a distinct type syntax in declarations.
-Although it's a separate point, the name usually comes first,
-often followed by a colon.
-Thus our examples above become something like (in a fictional but illustrative language)
-
-	x: int
-	p: pointer to int
-	a: array[3] of int
-
-These declarations are clear, if verbose - you just read them left to right.
-Go takes its cue from here, but in the interests of brevity it drops the
-colon and removes some of the keywords:
-
-	x int
-	p *int
-	a [3]int
-
-There is no direct correspondence between the look of [3]int and how to
-use a in an expression.
-(We'll come back to pointers in the next section.) You gain clarity at the
-cost of a separate syntax.
-
-Now consider functions. Let's transcribe the declaration for main as it would read in Go,
-although the real main function in Go takes no arguments:
-
-	func main(argc int, argv []string) int
-
-Superficially that's not much different from C,
-other than the change from `char` arrays to strings,
-but it reads well from left to right:
-
-function main takes an int and a slice of strings and returns an int.
-
-Drop the parameter names and it's just as clear - they're always first so there's no confusion.
-
-	func main(int, []string) int
-
-One merit of this left-to-right style is how well it works as the types
-become more complex.
-Here's a declaration of a function variable (analogous to a function pointer in C):
-
-	f func(func(int,int) int, int) int
-
-Or if f returns a function:
-
-	f func(func(int,int) int, int) func(int, int) int
-
-It still reads clearly, from left to right,
-and it's always obvious which name is being declared - the name comes first.
-
-The distinction between type and expression syntax makes it easy to write and invoke closures in Go:
-
-	sum := func(a, b int) int { return a+b } (3, 4)
-
-## Pointers
-
-Pointers are the exception that proves the rule.
-Notice that in arrays and slices, for instance,
-Go's type syntax puts the brackets on the left of the type but the expression
-syntax puts them on the right of the expression:
-
-	var a []int
-	x = a[1]
-
-For familiarity, Go's pointers use the \* notation from C,
-but we could not bring ourselves to make a similar reversal for pointer types.
-Thus pointers work like this
-
-	var p *int
-	x = *p
-
-We couldn't say
-
-	var p *int
-	x = p*
-
-because that postfix \* would conflate with multiplication. We could have used the Pascal ^, for example:
-
-	var p ^int
-	x = p^
-
-and perhaps we should have (and chosen another operator for xor),
-because the prefix asterisk on both types and expressions complicates things
-in a number of ways.
-For instance, although one can write
-
-	[]int("hi")
-
-as a conversion, one must parenthesize the type if it starts with a \*:
-
-	(*int)(nil)
-
-Had we been willing to give up \* as pointer syntax, those parentheses would be unnecessary.
-
-So Go's pointer syntax is tied to the familiar C form,
-but those ties mean that we cannot break completely from using parentheses
-to disambiguate types and expressions in the grammar.
-
-Overall, though, we believe Go's type syntax is easier to understand than C's, especially when things get complicated.
-
-## Notes
-
-Go's declarations read left to right. It's been pointed out that C's read in a spiral!
-See [ The "Clockwise/Spiral Rule"](http://c-faq.com/decl/spiral.anderson.html) by David Anderson.
diff --git a/_content/defer-panic-and-recover.article b/_content/defer-panic-and-recover.article
deleted file mode 100644
index 93431a3..0000000
--- a/_content/defer-panic-and-recover.article
+++ /dev/null
@@ -1,220 +0,0 @@
-# Defer, Panic, and Recover
-4 Aug 2010
-Tags: defer, panic, recover, technical, function
-Summary: An introduction to the Go's defer, panic, and recover control flow mechanisms.
-
-Andrew Gerrand
-
-##
-
-Go has the usual mechanisms for control flow:
-if, for, switch, goto.
-It also has the go statement to run code in a separate goroutine.
-Here I'd like to discuss some of the less common ones:
-defer, panic, and recover.
-
-A **defer statement** pushes a function call onto a list.
-The list of saved calls is executed after the surrounding function returns.
-Defer is commonly used to simplify functions that perform various clean-up actions.
-
-For example, let's look at a function that opens two files and copies the contents of one file to the other:
-
-	func CopyFile(dstName, srcName string) (written int64, err error) {
-	    src, err := os.Open(srcName)
-	    if err != nil {
-	        return
-	    }
-
-	    dst, err := os.Create(dstName)
-	    if err != nil {
-	        return
-	    }
-
-	    written, err = io.Copy(dst, src)
-	    dst.Close()
-	    src.Close()
-	    return
-	}
-
-This works, but there is a bug. If the call to os.Create fails,
-the function will return without closing the source file.
-This can be easily remedied by putting a call to src.Close before the second return statement,
-but if the function were more complex the problem might not be so easily
-noticed and resolved.
-By introducing defer statements we can ensure that the files are always closed:
-
-	func CopyFile(dstName, srcName string) (written int64, err error) {
-	    src, err := os.Open(srcName)
-	    if err != nil {
-	        return
-	    }
-	    defer src.Close()
-
-	    dst, err := os.Create(dstName)
-	    if err != nil {
-	        return
-	    }
-	    defer dst.Close()
-
-	    return io.Copy(dst, src)
-	}
-
-Defer statements allow us to think about closing each file right after opening it,
-guaranteeing that, regardless of the number of return statements in the function,
-the files _will_ be closed.
-
-The behavior of defer statements is straightforward and predictable. There are three simple rules:
-
-1. _A deferred function's arguments are evaluated when the defer statement is evaluated._
-
-In this example, the expression "i" is evaluated when the Println call is deferred.
-The deferred call will print "0" after the function returns.
-
-	func a() {
-	    i := 0
-	    defer fmt.Println(i)
-	    i++
-	    return
-	}
-
-2. _Deferred function calls are executed in Last In First Out order after the surrounding function returns._
-
-This function prints "3210":
-
-	func b() {
-	    for i := 0; i < 4; i++ {
-	        defer fmt.Print(i)
-	    }
-	}
-
-3. _Deferred functions may read and assign to the returning function's named return values._
-
-In this example, a deferred function increments the return value i _after_
-the surrounding function returns.
-Thus, this function returns 2:
-
-	func c() (i int) {
-	    defer func() { i++ }()
-	    return 1
-	}
-
-This is convenient for modifying the error return value of a function; we will see an example of this shortly.
-
-**Panic** is a built-in function that stops the ordinary flow of control and begins _panicking_.
-When the function F calls panic, execution of F stops,
-any deferred functions in F are executed normally,
-and then F returns to its caller.
-To the caller, F then behaves like a call to panic.
-The process continues up the stack until all functions in the current goroutine have returned,
-at which point the program crashes.
-Panics can be initiated by invoking panic directly.
-They can also be caused by runtime errors,
-such as out-of-bounds array accesses.
-
-**Recover** is a built-in function that regains control of a panicking goroutine.
-Recover is only useful inside deferred functions.
-During normal execution, a call to recover will return nil and have no other effect.
-If the current goroutine is panicking, a call to recover will capture the
-value given to panic and resume normal execution.
-
-Here's an example program that demonstrates the mechanics of panic and defer:
-
-	package main
-
-	import "fmt"
-
-	func main() {
-	    f()
-	    fmt.Println("Returned normally from f.")
-	}
-
-	func f() {
-	    defer func() {
-	        if r := recover(); r != nil {
-	            fmt.Println("Recovered in f", r)
-	        }
-	    }()
-	    fmt.Println("Calling g.")
-	    g(0)
-	    fmt.Println("Returned normally from g.")
-	}
-
-	func g(i int) {
-	    if i > 3 {
-	        fmt.Println("Panicking!")
-	        panic(fmt.Sprintf("%v", i))
-	    }
-	    defer fmt.Println("Defer in g", i)
-	    fmt.Println("Printing in g", i)
-	    g(i + 1)
-	}
-
-The function g takes the int i, and panics if i is greater than 3,
-or else it calls itself with the argument i+1.
-The function f defers a function that calls recover and prints the recovered
-value (if it is non-nil).
-Try to picture what the output of this program might be before reading on.
-
-The program will output:
-
-	Calling g.
-	Printing in g 0
-	Printing in g 1
-	Printing in g 2
-	Printing in g 3
-	Panicking!
-	Defer in g 3
-	Defer in g 2
-	Defer in g 1
-	Defer in g 0
-	Recovered in f 4
-	Returned normally from f.
-
-If we remove the deferred function from f the panic is not recovered and
-reaches the top of the goroutine's call stack,
-terminating the program.
-This modified program will output:
-
-	Calling g.
-	Printing in g 0
-	Printing in g 1
-	Printing in g 2
-	Printing in g 3
-	Panicking!
-	Defer in g 3
-	Defer in g 2
-	Defer in g 1
-	Defer in g 0
-	panic: 4
-
-	panic PC=0x2a9cd8
-	[stack trace omitted]
-
-For a real-world example of **panic** and **recover**,
-see the [json package](https://golang.org/pkg/encoding/json/) from the
-Go standard library.
-It encodes an interface with a set of recursive functions.
-If an error occurs when traversing the value,
-panic is called to unwind the stack to the top-level function call,
-which recovers from the panic and returns an appropriate error value (see
-the 'error' and 'marshal' methods of the encodeState type in [encode.go](https://golang.org/src/pkg/encoding/json/encode.go)).
-
-The convention in the Go libraries is that even when a package uses panic internally,
-its external API still presents explicit error return values.
-
-Other uses of **defer** (beyond the file.Close example given earlier) include releasing a mutex:
-
-	mu.Lock()
-	defer mu.Unlock()
-
-printing a footer:
-
-	printHeader()
-	defer printFooter()
-
-and more.
-
-In summary, the defer statement (with or without panic and recover) provides
-an unusual and powerful mechanism for control flow.
-It can be used to model a number of features implemented by special-purpose
-structures in other programming languages. Try it out.
diff --git a/_content/developer-experience.article b/_content/developer-experience.article
deleted file mode 100644
index 73254f5..0000000
--- a/_content/developer-experience.article
+++ /dev/null
@@ -1,40 +0,0 @@
-# Introducing the Developer Experience Working Group
-10 Apr 2017
-Summary: Announcing the Developer eXperience Working Group (DXWG).
-
-The Developer Experience Working Group
-
-##
-
-Over the last several years, Go's audience has shifted from early
-adopters to mainstream users. Today, our users come from a wide
-variety of backgrounds, experiences, and expectations. The needs
-of users are growing faster than the Go project can currently address
-them. To streamline the experience for first-time Go users,
-we've created the Developer eXperience Working Group (DXWG).
-
-For the next three months, this group will work together on delivering:
-
-  - improvements to the Go installation experience
-  - better guidelines to help new users
-  - guides on tooling and developer environments (editors and IDEs)
-  - running user studies to systematically analyze and measure friction points
-  - improvements to the [Go Tour](https://tour.golang.org/) and [Go Playground](https://play.golang.org/)
-
-A secondary goal of the working group is to better understand how to
-involve the Go community in charting Go’s future. We hope that working
-groups – Go team members working alongside community members – will
-help Go scale its leadership and address user needs.  We’ll learn
-from this experience and iterate.
-
-The initial members of the working group are:
-Carmen Andoh, Chris Broadfoot, Francesc Campoy, Jaana Burcu Dogan,
-Steve Francia, Jess Frazelle, Bill Kennedy, Katrina Owen, Natalie
-Pistunovich, Mat Ryer, Dmitri Shuralyov.
-
-We are looking for additional people to help with contributing
-code, writing documentation, sharing feedback and experiences
-(user stories), reviewing contributions, and more. If you are
-interested in any of our current areas of focus, please subscribe to the
-[golang-devexp](https://groups.google.com/forum/#!forum/golang-devexp)
-mailing list.
diff --git a/_content/docker.article b/_content/docker.article
deleted file mode 100644
index d0be85c..0000000
--- a/_content/docker.article
+++ /dev/null
@@ -1,202 +0,0 @@
-# Deploying Go servers with Docker
-26 Sep 2014
-Summary: How to use Docker's new official base images for Go.
-
-Andrew Gerrand
-
-## Introduction
-
-This week Docker [announced](https://blog.docker.com/2014/09/docker-hub-official-repos-announcing-language-stacks/)
-official base images for Go and other major languages,
-giving programmers a trusted and easy way to build containers for their Go programs.
-
-In this article we'll walk through a recipe for creating a Docker container for
-a simple Go web application and deploying that container to Google Compute Engine.
-If you're not familiar with Docker, you should read
-[Understanding Docker](https://docs.docker.com/engine/understanding-docker/)
-before reading on.
-
-## The demo app
-
-For our demonstration we will use the
-[outyet](https://godoc.org/github.com/golang/example/outyet) program from the
-[Go examples repository](https://github.com/golang/example),
-a simple web server that reports whether the next version of Go has been released
-(designed to power sites like [isgo1point4.outyet.org](http://isgo1point4.outyet.org/)).
-It has no dependencies outside the standard library and requires no additional
-data files at run time; for a web server, it's about as simple as it gets.
-
-Use "go get" to fetch and install outyet in your
-[workspace](https://golang.org/doc/code.html#Workspaces):
-
-	$ go get github.com/golang/example/outyet
-
-## Write a Dockerfile
-
-Replace a file named `Dockerfile` in the `outyet` directory with the following contents:
-
-	# Start from a Debian image with the latest version of Go installed
-	# and a workspace (GOPATH) configured at /go.
-	FROM golang
-
-	# Copy the local package files to the container's workspace.
-	ADD . /go/src/github.com/golang/example/outyet
-
-	# Build the outyet command inside the container.
-	# (You may fetch or manage dependencies here,
-	# either manually or with a tool like "godep".)
-	RUN go install github.com/golang/example/outyet
-
-	# Run the outyet command by default when the container starts.
-	ENTRYPOINT /go/bin/outyet
-
-	# Document that the service listens on port 8080.
-	EXPOSE 8080
-
-This `Dockerfile` specifies how to construct a container that runs `outyet`,
-starting with the basic dependencies (a Debian system with Go installed;
-the [official `golang` docker image](https://registry.hub.docker.com/_/golang/)),
-adding the `outyet` package source, building it, and then finally running it.
-
-The `ADD`, `RUN`, and `ENTRYPOINT` steps are common tasks for any Go project.
-To simplify this, there is an
-[`onbuild` variant](https://github.com/docker-library/golang/blob/9ff2ccca569f9525b023080540f1bb55f6b59d7f/1.3.1/onbuild/Dockerfile)
-of the `golang` image that automatically copies the package source, fetches the
-application dependencies, builds the program, and configures it to run on
-startup.
-
-With the `onbuild` variant, the `Dockerfile` is much simpler:
-
-	FROM golang:onbuild
-	EXPOSE 8080
-
-## Build and run the image
-
-Invoke Docker from the `outyet` package directory to build an image using the `Dockerfile`:
-
-	$ docker build -t outyet .
-
-This will fetch the `golang` base image from Docker Hub, copy the package source
-to it, build the package inside it, and tag the resulting image as `outyet`.
-
-To run a container from the resulting image:
-
-	$ docker run --publish 6060:8080 --name test --rm outyet
-
-The `--publish` flag tells docker to publish the container's port `8080` on the
-external port `6060`.
-
-The `--name` flag gives our container a predictable name to make it easier to work with.
-
-The `--rm` flag tells docker to remove the container image when the outyet server exits.
-
-With the container running, open `http://localhost:6060/` in a web browser and
-you should see something like this:
-
-.image docker/outyet.png
-
-(If your docker daemon is running on another machine (or in a virtual machine),
-you should replace `localhost` with the address of that machine. If you're
-using [boot2docker](http://boot2docker.io/) on OS X or Windows you can find
-that address with `boot2docker ip`.)
-
-Now that we've verified that the image works, shut down the running container
-from another terminal window:
-
-	$ docker stop test
-
-## Create a repository on Docker Hub
-
-[Docker Hub](https://hub.docker.com/), the container registry from which we
-pulled the `golang` image earlier, offers a feature called
-[Automated Builds](http://docs.docker.com/docker-hub/builds/) that builds
-images from a GitHub or BitBucket repository.
-
-By committing [the Dockerfile](https://github.com/golang/example/blob/master/outyet/Dockerfile)
-to the repository and creating an
-[automated build](https://registry.hub.docker.com/u/adg1/outyet/)
-for it, anyone with Docker installed can download and run our image with a
-single command. (We will see the utility of this in the next section.)
-
-To set up an Automated Build, commit the Dockerfile to your repo on
-[GitHub](https://github.com/) or [BitBucket](https://bitbucket.org/),
-create an account on Docker Hub, and follow the instructions for
-[creating an Automated Build](http://docs.docker.com/docker-hub/builds/).
-
-When you're done, you can run your container using the name of the automated build:
-
-	$ docker run goexample/outyet
-
-(Replace `goexample/outyet` with the name of the automated build you created.)
-
-## Deploy the container to Google Compute Engine
-
-Google provides
-[container-optimized Google Compute Engine images](https://developers.google.com/compute/docs/containers/container_vms)
-that make it easy to spin up a virtual machine running an arbitrary Docker container.
-On startup, a program running on the instance reads a configuration file that
-specifies which container to run, fetches the container image, and runs it.
-
-Create a [containers.yaml](https://cloud.google.com/compute/docs/containers/container_vms#container_manifest)
-file that specifies the docker image to run and the ports to expose:
-
-	version: v1beta2
-	containers:
-	- name: outyet
-	  image: goexample/outyet
-	  ports:
-	  - name: http
-	    hostPort: 80
-	    containerPort: 8080
-
-(Note that we're publishing the container's port `8080` as external port `80`,
-the default port for serving HTTP traffic. And, again, you should replace
-`goexample/outyet` with the name of your Automated Build.)
-
-Use the [gcloud tool](https://cloud.google.com/sdk/#Quick_Start)
-to create a VM instance running the container:
-
-	$ gcloud compute instances create outyet \
-		--image container-vm-v20140925 \
-		--image-project google-containers \
-		--metadata-from-file google-container-manifest=containers.yaml \
-		--tags http-server \
-		--zone us-central1-a \
-		--machine-type f1-micro
-
-The first argument (`outyet`) specifies the instance name, a convenient label
-for administrative purposes.
-
-The `--image` and `--image-project` flags specify the special
-container-optimized system image to use (copy these flags verbatim).
-
-The `--metadata-from-file` flag supplies your `containers.yaml` file to the VM.
-
-The `--tags` flag tags your VM instance as an HTTP server, adjusting the
-firewall to expose port 80 on the public network interface.
-
-The `--zone` and `--machine-type` flags specify the zone in which to run the VM
-and the type of machine to run. (To see a list of machine types and the zones,
-run `gcloud compute machine-types list`.)
-
-Once this has completed, the gcloud command should print some information about
-the instance. In the output, locate the `networkInterfaces` section to find the
-instance's external IP address. Within a couple of minutes you should be able
-to access that IP with your web browser and see the "Has Go 1.4 been released
-yet?" page.
-
-(To see what's happening on the new VM instance you can ssh into it with
-`gcloud compute ssh outyet`. From there, try `sudo docker ps` to see which
-Docker containers are running.)
-
-## Learn more
-
-This is just the tip of the iceberg—there's a lot more you can do with Go, Docker, and Google Compute Engine.
-
-To learn more about Docker, see their [extensive documentation](https://docs.docker.com/).
-
-To learn more about Docker and Go, see the [official `golang` Docker Hub repository](https://registry.hub.docker.com/_/golang/) and Kelsey Hightower's [Optimizing Docker Images for Static Go Binaries](https://medium.com/@kelseyhightower/optimizing-docker-images-for-static-binaries-b5696e26eb07).
-
-To learn more about Docker and [Google Compute Engine](http://cloud.google.com/compute),
-see the [Container-optimized VMs page](https://cloud.google.com/compute/docs/containers/container_vms)
-and the [google/docker-registry Docker Hub repository](https://registry.hub.docker.com/u/google/docker-registry/).
diff --git a/_content/docker/outyet.png b/_content/docker/outyet.png
deleted file mode 100644
index c5e5710..0000000
--- a/_content/docker/outyet.png
+++ /dev/null
Binary files differ
diff --git a/_content/error-handling-and-go.article b/_content/error-handling-and-go.article
deleted file mode 100644
index 092addc..0000000
--- a/_content/error-handling-and-go.article
+++ /dev/null
@@ -1,325 +0,0 @@
-# Error handling and Go
-12 Jul 2011
-Tags: error, interface, type, technical
-Summary: An introduction to Go errors.
-
-Andrew Gerrand
-
-## Introduction
-
-If you have written any Go code you have probably encountered the built-in `error` type.
-Go code uses `error` values to indicate an abnormal state.
-For example, the `os.Open` function returns a non-nil `error` value when
-it fails to open a file.
-
-	func Open(name string) (file *File, err error)
-
-The following code uses `os.Open` to open a file.
-If an error occurs it calls `log.Fatal` to print the error message and stop.
-
-	f, err := os.Open("filename.ext")
-	if err != nil {
-	    log.Fatal(err)
-	}
-	// do something with the open *File f
-
-You can get a lot done in Go knowing just this about the `error` type,
-but in this article we'll take a closer look at `error` and discuss some
-good practices for error handling in Go.
-
-## The error type
-
-The `error` type is an interface type. An `error` variable represents any
-value that can describe itself as a string.
-Here is the interface's declaration:
-
-	type error interface {
-	    Error() string
-	}
-
-The `error` type, as with all built in types,
-is [predeclared](https://golang.org/doc/go_spec.html#Predeclared_identifiers)
-in the [universe block](https://golang.org/doc/go_spec.html#Blocks).
-
-The most commonly-used `error` implementation is the [errors](https://golang.org/pkg/errors/)
-package's unexported `errorString` type.
-
-	// errorString is a trivial implementation of error.
-	type errorString struct {
-	    s string
-	}
-
-	func (e *errorString) Error() string {
-	    return e.s
-	}
-
-You can construct one of these values with the `errors.New` function.
-It takes a string that it converts to an `errors.errorString` and returns
-as an `error` value.
-
-	// New returns an error that formats as the given text.
-	func New(text string) error {
-	    return &errorString{text}
-	}
-
-Here's how you might use `errors.New`:
-
-	func Sqrt(f float64) (float64, error) {
-	    if f < 0 {
-	        return 0, errors.New("math: square root of negative number")
-	    }
-	    // implementation
-	}
-
-A caller passing a negative argument to `Sqrt` receives a non-nil `error`
-value (whose concrete representation is an `errors.errorString` value).
-The caller can access the error string ("math:
-square root of...") by calling the `error`'s `Error` method,
-or by just printing it:
-
-	f, err := Sqrt(-1)
-	if err != nil {
-	    fmt.Println(err)
-	}
-
-The [fmt](https://golang.org/pkg/fmt/) package formats an `error` value by calling its `Error() string` method.
-
-It is the error implementation's responsibility to summarize the context.
-The error returned by `os.Open` formats as "open /etc/passwd:
-permission denied," not just "permission denied."  The error returned by
-our `Sqrt` is missing information about the invalid argument.
-
-To add that information, a useful function is the `fmt` package's `Errorf`.
-It formats a string according to `Printf`'s rules and returns it as an `error`
-created by `errors.New`.
-
-	if f < 0 {
-	    return 0, fmt.Errorf("math: square root of negative number %g", f)
-	}
-
-In many cases `fmt.Errorf` is good enough,
-but since `error` is an interface, you can use arbitrary data structures as error values,
-to allow callers to inspect the details of the error.
-
-For instance, our hypothetical callers might want to recover the invalid
-argument passed to `Sqrt`.
-We can enable that by defining a new error implementation instead of using
-`errors.errorString`:
-
-	type NegativeSqrtError float64
-
-	func (f NegativeSqrtError) Error() string {
-	    return fmt.Sprintf("math: square root of negative number %g", float64(f))
-	}
-
-A sophisticated caller can then use a [type assertion](https://golang.org/doc/go_spec.html#Type_assertions)
-to check for a `NegativeSqrtError` and handle it specially,
-while callers that just pass the error to `fmt.Println` or `log.Fatal` will
-see no change in behavior.
-
-As another example, the [json](https://golang.org/pkg/encoding/json/)
-package specifies a `SyntaxError` type that the `json.Decode` function returns
-when it encounters a syntax error parsing a JSON blob.
-
-	type SyntaxError struct {
-	    msg    string // description of error
-	    Offset int64  // error occurred after reading Offset bytes
-	}
-
-	func (e *SyntaxError) Error() string { return e.msg }
-
-The `Offset` field isn't even shown in the default formatting of the error,
-but callers can use it to add file and line information to their error messages:
-
-	if err := dec.Decode(&val); err != nil {
-	    if serr, ok := err.(*json.SyntaxError); ok {
-	        line, col := findLine(f, serr.Offset)
-	        return fmt.Errorf("%s:%d:%d: %v", f.Name(), line, col, err)
-	    }
-	    return err
-	}
-
-(This is a slightly simplified version of some [actual code](https://github.com/camlistore/go4/blob/03efcb870d84809319ea509714dd6d19a1498483/jsonconfig/eval.go#L123-L135)
-from the [Camlistore](http://camlistore.org) project.)
-
-The `error` interface requires only a `Error` method;
-specific error implementations might have additional methods.
-For instance, the [net](https://golang.org/pkg/net/) package returns errors of type `error`,
-following the usual convention, but some of the error implementations have
-additional methods defined by the `net.Error` interface:
-
-	package net
-
-	type Error interface {
-	    error
-	    Timeout() bool   // Is the error a timeout?
-	    Temporary() bool // Is the error temporary?
-	}
-
-Client code can test for a `net.Error` with a type assertion and then distinguish
-transient network errors from permanent ones.
-For instance, a web crawler might sleep and retry when it encounters a temporary
-error and give up otherwise.
-
-	if nerr, ok := err.(net.Error); ok && nerr.Temporary() {
-	    time.Sleep(1e9)
-	    continue
-	}
-	if err != nil {
-	    log.Fatal(err)
-	}
-
-## Simplifying repetitive error handling
-
-In Go, error handling is important. The language's design and conventions
-encourage you to explicitly check for errors where they occur (as distinct
-from the convention in other languages of throwing exceptions and sometimes catching them).
-In some cases this makes Go code verbose,
-but fortunately there are some techniques you can use to minimize repetitive error handling.
-
-Consider an [App Engine](https://cloud.google.com/appengine/docs/go/)
-application with an HTTP handler that retrieves a record from the datastore
-and formats it with a template.
-
-	func init() {
-	    http.HandleFunc("/view", viewRecord)
-	}
-
-	func viewRecord(w http.ResponseWriter, r *http.Request) {
-	    c := appengine.NewContext(r)
-	    key := datastore.NewKey(c, "Record", r.FormValue("id"), 0, nil)
-	    record := new(Record)
-	    if err := datastore.Get(c, key, record); err != nil {
-	        http.Error(w, err.Error(), 500)
-	        return
-	    }
-	    if err := viewTemplate.Execute(w, record); err != nil {
-	        http.Error(w, err.Error(), 500)
-	    }
-	}
-
-This function handles errors returned by the `datastore.Get` function and
-`viewTemplate`'s `Execute` method.
-In both cases, it presents a simple error message to the user with the HTTP
-status code 500 ("Internal Server Error").
-This looks like a manageable amount of code,
-but add some more HTTP handlers and you quickly end up with many copies
-of identical error handling code.
-
-To reduce the repetition we can define our own HTTP `appHandler` type that includes an `error` return value:
-
-	type appHandler func(http.ResponseWriter, *http.Request) error
-
-Then we can change our `viewRecord` function to return errors:
-
-	func viewRecord(w http.ResponseWriter, r *http.Request) error {
-	    c := appengine.NewContext(r)
-	    key := datastore.NewKey(c, "Record", r.FormValue("id"), 0, nil)
-	    record := new(Record)
-	    if err := datastore.Get(c, key, record); err != nil {
-	        return err
-	    }
-	    return viewTemplate.Execute(w, record)
-	}
-
-This is simpler than the original version,
-but the [http](https://golang.org/pkg/net/http/) package doesn't understand
-functions that return `error`.
-To fix this we can implement the `http.Handler` interface's `ServeHTTP`
-method on `appHandler`:
-
-	func (fn appHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
-	    if err := fn(w, r); err != nil {
-	        http.Error(w, err.Error(), 500)
-	    }
-	}
-
-The `ServeHTTP` method calls the `appHandler` function and displays the
-returned error (if any) to the user.
-Notice that the method's receiver, `fn`, is a function.
-(Go can do that!) The method invokes the function by calling the receiver
-in the expression `fn(w, r)`.
-
-Now when registering `viewRecord` with the http package we use the `Handle`
-function (instead of `HandleFunc`) as `appHandler` is an `http.Handler`
-(not an `http.HandlerFunc`).
-
-	func init() {
-	    http.Handle("/view", appHandler(viewRecord))
-	}
-
-With this basic error handling infrastructure in place,
-we can make it more user friendly.
-Rather than just displaying the error string,
-it would be better to give the user a simple error message with an appropriate HTTP status code,
-while logging the full error to the App Engine developer console for debugging purposes.
-
-To do this we create an `appError` struct containing an `error` and some other fields:
-
-	type appError struct {
-	    Error   error
-	    Message string
-	    Code    int
-	}
-
-Next we modify the appHandler type to return `*appError` values:
-
-	type appHandler func(http.ResponseWriter, *http.Request) *appError
-
-(It's usually a mistake to pass back the concrete type of an error rather than `error`,
-for reasons discussed in [the Go FAQ](https://golang.org/doc/go_faq.html#nil_error),
-but it's the right thing to do here because `ServeHTTP` is the only place
-that sees the value and uses its contents.)
-
-And make `appHandler`'s `ServeHTTP` method display the `appError`'s `Message`
-to the user with the correct HTTP status `Code` and log the full `Error`
-to the developer console:
-
-	func (fn appHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
-	    if e := fn(w, r); e != nil { // e is *appError, not os.Error.
-	        c := appengine.NewContext(r)
-	        c.Errorf("%v", e.Error)
-	        http.Error(w, e.Message, e.Code)
-	    }
-	}
-
-Finally, we update `viewRecord` to the new function signature and have it
-return more context when it encounters an error:
-
-	func viewRecord(w http.ResponseWriter, r *http.Request) *appError {
-	    c := appengine.NewContext(r)
-	    key := datastore.NewKey(c, "Record", r.FormValue("id"), 0, nil)
-	    record := new(Record)
-	    if err := datastore.Get(c, key, record); err != nil {
-	        return &appError{err, "Record not found", 404}
-	    }
-	    if err := viewTemplate.Execute(w, record); err != nil {
-	        return &appError{err, "Can't display record", 500}
-	    }
-	    return nil
-	}
-
-This version of `viewRecord` is the same length as the original,
-but now each of those lines has specific meaning and we are providing a
-friendlier user experience.
-
-It doesn't end there; we can further improve the error handling in our application. Some ideas:
-
-  - give the error handler a pretty HTML template,
-
-  - make debugging easier by writing the stack trace to the HTTP response when the user is an administrator,
-
-  - write a constructor function for `appError` that stores the stack trace for easier debugging,
-
-  - recover from panics inside the `appHandler`,
-    logging the error to the console as "Critical," while telling the user "a
-    serious error has occurred." This is a nice touch to avoid exposing the
-    user to inscrutable error messages caused by programming errors.
-    See the [Defer, Panic, and Recover](https://golang.org/doc/articles/defer_panic_recover.html)
-    article for more details.
-
-## Conclusion
-
-Proper error handling is an essential requirement of good software.
-By employing the techniques described in this post you should be able to
-write more reliable and succinct Go code.
diff --git a/_content/errors-are-values.article b/_content/errors-are-values.article
deleted file mode 100644
index 761c716..0000000
--- a/_content/errors-are-values.article
+++ /dev/null
@@ -1,236 +0,0 @@
-# Errors are values
-12 Jan 2015
-Summary: Idioms and patterns for handling errors in Go.
-
-Rob Pike
-
-##
-
-A common point of discussion among Go programmers,
-especially those new to the language, is how to handle errors.
-The conversation often turns into a lament at the number of times the sequence
-
-	if err != nil {
-		return err
-	}
-
-shows up.
-We recently scanned all the open source projects we could find and
-discovered that this snippet occurs only once per page or two,
-less often than some would have you believe.
-Still, if the perception persists that one must type
-
-	if err != nil
-
-all the time, something must be wrong, and the obvious target is Go itself.
-
-This is unfortunate, misleading, and easily corrected.
-Perhaps what is happening is that programmers new to Go ask,
-"How does one handle errors?", learn this pattern, and stop there.
-In other languages, one might use a try-catch block or other such mechanism to handle errors.
-Therefore, the programmer thinks, when I would have used a try-catch
-in my old language, I will just type `if` `err` `!=` `nil` in Go.
-Over time the Go code collects many such snippets, and the result feels clumsy.
-
-Regardless of whether this explanation fits,
-it is clear that these Go programmers miss a fundamental point about errors:
-_Errors are values._
-
-Values can be programmed, and since errors are values, errors can be programmed.
-
-Of course a common statement involving an error value is to test whether it is nil,
-but there are countless other things one can do with an error value,
-and application of some of those other things can make your program better,
-eliminating much of the boilerplate that arises if every error is checked with a rote if statement.
-
-Here's a simple example from the `bufio` package's
-[`Scanner`](https://golang.org/pkg/bufio/#Scanner) type.
-Its [`Scan`](https://golang.org/pkg/bufio/#Scanner.Scan) method performs the underlying I/O,
-which can of course lead to an error.
-Yet the `Scan` method does not expose an error at all.
-Instead, it returns a boolean, and a separate method, to be run at the end of the scan,
-reports whether an error occurred.
-Client code looks like this:
-
-	scanner := bufio.NewScanner(input)
-	for scanner.Scan() {
-		token := scanner.Text()
-		// process token
-	}
-	if err := scanner.Err(); err != nil {
-		// process the error
-	}
-
-Sure, there is a nil check for an error, but it appears and executes only once.
-The `Scan` method could instead have been defined as
-
-	func (s *Scanner) Scan() (token []byte, error)
-
-and then the example user code might be (depending on how the token is retrieved),
-
-	scanner := bufio.NewScanner(input)
-	for {
-		token, err := scanner.Scan()
-		if err != nil {
-			return err // or maybe break
-		}
-		// process token
-	}
-
-This isn't very different, but there is one important distinction.
-In this code, the client must check for an error on every iteration,
-but in the real `Scanner` API, the error handling is abstracted away from the key API element,
-which is iterating over tokens.
-With the real API, the client's code therefore feels more natural:
-loop until done, then worry about errors.
-Error handling does not obscure the flow of control.
-
-Under the covers what's happening, of course,
-is that as soon as `Scan` encounters an I/O error, it records it and returns `false`.
-A separate method, [`Err`](https://golang.org/pkg/bufio/#Scanner.Err),
-reports the error value when the client asks.
-Trivial though this is, it's not the same as putting
-
-	if err != nil
-
-everywhere or asking the client to check for an error after every token.
-It's programming with error values.
-Simple programming, yes, but programming nonetheless.
-
-It's worth stressing that whatever the design,
-it's critical that the program check the errors however they are exposed.
-The discussion here is not about how to avoid checking errors,
-it's about using the language to handle errors with grace.
-
-The topic of repetitive error-checking code arose when I attended the autumn 2014 GoCon in Tokyo.
-An enthusiastic gopher, who goes by [`@jxck_`](https://twitter.com/jxck_) on Twitter,
-echoed the familiar lament about error checking.
-He had some code that looked schematically like this:
-
-	_, err = fd.Write(p0[a:b])
-	if err != nil {
-		return err
-	}
-	_, err = fd.Write(p1[c:d])
-	if err != nil {
-		return err
-	}
-	_, err = fd.Write(p2[e:f])
-	if err != nil {
-		return err
-	}
-	// and so on
-
-It is very repetitive.
-In the real code, which was longer,
-there is more going on so it's not easy to just refactor this using a helper function,
-but in this idealized form, a function literal closing over the error variable would help:
-
-	var err error
-	write := func(buf []byte) {
-		if err != nil {
-			return
-		}
-		_, err = w.Write(buf)
-	}
-	write(p0[a:b])
-	write(p1[c:d])
-	write(p2[e:f])
-	// and so on
-	if err != nil {
-		return err
-	}
-
-This pattern works well, but requires a closure in each function doing the writes;
-a separate helper function is clumsier to use because the `err` variable
-needs to be maintained across calls (try it).
-
-We can make this cleaner, more general, and reusable by borrowing the idea from the
-`Scan` method above.
-I mentioned this technique in our discussion but `@jxck_` didn't see how to apply it.
-After a long exchange, hampered somewhat by a language barrier,
-I asked if I could just borrow his laptop and show him by typing some code.
-
-I defined an object called an `errWriter`, something like this:
-
-	type errWriter struct {
-		w   io.Writer
-		err error
-	}
-
-and gave it one method, `write.`
-It doesn't need to have the standard `Write` signature,
-and it's lower-cased in part to highlight the distinction.
-The `write` method calls the `Write` method of the underlying `Writer`
-and records the first error for future reference:
-
-	func (ew *errWriter) write(buf []byte) {
-		if ew.err != nil {
-			return
-		}
-		_, ew.err = ew.w.Write(buf)
-	}
-
-As soon as an error occurs, the `write` method becomes a no-op but the error value is saved.
-
-Given the `errWriter` type and its `write` method, the code above can be refactored:
-
-	ew := &errWriter{w: fd}
-	ew.write(p0[a:b])
-	ew.write(p1[c:d])
-	ew.write(p2[e:f])
-	// and so on
-	if ew.err != nil {
-		return ew.err
-	}
-
-This is cleaner, even compared to the use of a closure,
-and also makes the actual sequence of writes being done easier to see on the page.
-There is no clutter any more.
-Programming with error values (and interfaces) has made the code nicer.
-
-It's likely that some other piece of code in the same package can build on this idea,
-or even use `errWriter` directly.
-
-Also, once `errWriter` exists, there's more it could do to help,
-especially in less artificial examples.
-It could accumulate the byte count.
-It could coalesce writes into a single buffer that can then be transmitted atomically.
-And much more.
-
-In fact, this pattern appears often in the standard library.
-The [`archive/zip`](https://golang.org/pkg/archive/zip/) and
-[`net/http`](https://golang.org/pkg/net/http/) packages use it.
-More salient to this discussion, the [`bufio` package's `Writer`](https://golang.org/pkg/bufio/)
-is actually an implementation of the `errWriter` idea.
-Although `bufio.Writer.Write` returns an error,
-that is mostly about honoring the [`io.Writer`](https://golang.org/pkg/io/#Writer) interface.
-The `Write` method of `bufio.Writer` behaves just like our `errWriter.write`
-method above, with `Flush` reporting the error, so our example could be written like this:
-
-	b := bufio.NewWriter(fd)
-	b.Write(p0[a:b])
-	b.Write(p1[c:d])
-	b.Write(p2[e:f])
-	// and so on
-	if b.Flush() != nil {
-		return b.Flush()
-	}
-
-There is one significant drawback to this approach, at least for some applications:
-there is no way to know how much of the processing completed before the error occurred.
-If that information is important, a more fine-grained approach is necessary.
-Often, though, an all-or-nothing check at the end is sufficient.
-
-We've looked at just one technique for avoiding repetitive error handling code.
-Keep in mind that the use of `errWriter` or `bufio.Writer` isn't the only way to simplify error handling,
-and this approach is not suitable for all situations.
-The key lesson, however, is that errors are values and the full power of
-the Go programming language is available for processing them.
-
-Use the language to simplify your error handling.
-
-But remember: Whatever you do, always check your errors!
-
-Finally, for the full story of my interaction with @jxck\_, including a little video he recorded,
-visit [his blog](http://jxck.hatenablog.com/entry/golang-error-handling-lesson-by-rob-pike).
diff --git a/_content/examples.article b/_content/examples.article
deleted file mode 100644
index 86d727d..0000000
--- a/_content/examples.article
+++ /dev/null
@@ -1,200 +0,0 @@
-# Testable Examples in Go
-7 May 2015
-Tags: godoc, testing
-Summary: How to add examples, which double as tests, to your packages.
-
-Andrew Gerrand
-
-## Introduction
-
-Godoc [examples](https://golang.org/pkg/testing/#hdr-Examples) are snippets of
-Go code that are displayed as package documentation and that are verified by
-running them as tests.
-They can also be run by a user visiting the godoc web page for the package
-and clicking the associated "Run" button.
-
-Having executable documentation for a package guarantees that the information
-will not go out of date as the API changes.
-
-The standard library includes many such examples
-(see the [`strings` package](https://golang.org/pkg/strings/#Contains),
-for instance).
-
-This article explains how to write your own example functions.
-
-## Examples are tests
-
-Examples are compiled (and optionally executed) as part of a package's test
-suite.
-
-As with typical tests, examples are functions that reside in a package's
-`_test.go` files.
-Unlike normal test functions, though, example functions take no arguments
-and begin with the word `Example` instead of `Test`.
-
-The [`stringutil` package](https://godoc.org/github.com/golang/example/stringutil/)
-is part of the [Go example repository](https://github.com/golang/example).
-Here's an example that demonstrates its `Reverse` function:
-
-	package stringutil_test
-
-	import (
-		"fmt"
-
-		"github.com/golang/example/stringutil"
-	)
-
-	func ExampleReverse() {
-		fmt.Println(stringutil.Reverse("hello"))
-		// Output: olleh
-	}
-
-This code might live in `example_test.go` in the `stringutil` directory.
-
-Godoc will present this example alongside the `Reverse` function's documentation:
-
-.image examples/reverse.png
-
-Running the package's test suite, we can see the example function is executed
-with no further arrangement from us:
-
-	$ go test -v
-	=== RUN TestReverse
-	--- PASS: TestReverse (0.00s)
-	=== RUN: ExampleReverse
-	--- PASS: ExampleReverse (0.00s)
-	PASS
-	ok  	github.com/golang/example/stringutil	0.009s
-
-## Output comments
-
-What does it mean that the `ExampleReverse` function "passes"?
-
-As it executes the example,
-the testing framework captures data written to standard output
-and then compares the output against the example's "Output:" comment.
-The test passes if the test's output matches its output comment.
-
-To see a failing example we can change the output comment text to something
-obviously incorrect
-
-	func ExampleReverse() {
-		fmt.Println(stringutil.Reverse("hello"))
-		// Output: golly
-	}
-
-and run the tests again:
-
-	$ go test
-	--- FAIL: ExampleReverse (0.00s)
-	got:
-	olleh
-	want:
-	golly
-	FAIL
-
-If we remove the output comment entirely
-
-	func ExampleReverse() {
-		fmt.Println(stringutil.Reverse("hello"))
-	}
-
-then the example function is compiled but not executed:
-
-	$ go test -v
-	=== RUN TestReverse
-	--- PASS: TestReverse (0.00s)
-	PASS
-	ok  	github.com/golang/example/stringutil	0.009s
-
-Examples without output comments are useful for demonstrating code that cannot
-run as unit tests, such as that which accesses the network,
-while guaranteeing the example at least compiles.
-
-## Example function names
-
-Godoc uses a naming convention to associate an example function with a
-package-level identifier.
-
-	func ExampleFoo()     // documents the Foo function or type
-	func ExampleBar_Qux() // documents the Qux method of type Bar
-	func Example()        // documents the package as a whole
-
-Following this convention, godoc displays the `ExampleReverse` example
-alongside the documentation for the `Reverse` function.
-
-Multiple examples can be provided for a given identifier by using a suffix
-beginning with an underscore followed by a lowercase letter.
-Each of these examples documents the `Reverse` function:
-
-	func ExampleReverse()
-	func ExampleReverse_second()
-	func ExampleReverse_third()
-
-## Larger examples
-
-Sometimes we need more than just a function to write a good example.
-
-For instance, to demonstrate the [`sort` package](https://golang.org/pkg/sort/)
-we should show an implementation of `sort.Interface`.
-Since methods cannot be declared inside a function body, the example must
-include some context in addition to the example function.
-
-To achieve this we can use a "whole file example."
-A whole file example is a file that ends in `_test.go` and contains exactly one
-example function, no test or benchmark functions, and at least one other
-package-level declaration.
-When displaying such examples godoc will show the entire file.
-
-Here is a whole file example from the `sort` package:
-
-	package sort_test
-
-	import (
-		"fmt"
-		"sort"
-	)
-
-	type Person struct {
-		Name string
-		Age  int
-	}
-
-	func (p Person) String() string {
-		return fmt.Sprintf("%s: %d", p.Name, p.Age)
-	}
-
-	// ByAge implements sort.Interface for []Person based on
-	// the Age field.
-	type ByAge []Person
-
-	func (a ByAge) Len() int           { return len(a) }
-	func (a ByAge) Swap(i, j int)      { a[i], a[j] = a[j], a[i] }
-	func (a ByAge) Less(i, j int) bool { return a[i].Age < a[j].Age }
-
-	func Example() {
-		people := []Person{
-			{"Bob", 31},
-			{"John", 42},
-			{"Michael", 17},
-			{"Jenny", 26},
-		}
-
-		fmt.Println(people)
-		sort.Sort(ByAge(people))
-		fmt.Println(people)
-
-		// Output:
-		// [Bob: 31 John: 42 Michael: 17 Jenny: 26]
-		// [Michael: 17 Jenny: 26 Bob: 31 John: 42]
-	}
-
-A package can contain multiple whole file examples; one example per file.
-Take a look at the [`sort` package's source code](https://golang.org/src/sort/)
-to see this in practice.
-
-## Conclusion
-
-Godoc examples are a great way to write and maintain code as documentation.
-They also present editable, working, runnable examples your users can build on.
-Use them!
diff --git a/_content/examples/reverse.png b/_content/examples/reverse.png
deleted file mode 100644
index c9b5ad2..0000000
--- a/_content/examples/reverse.png
+++ /dev/null
Binary files differ
diff --git a/_content/experiment.article b/_content/experiment.article
deleted file mode 100644
index cf2ee69..0000000
--- a/_content/experiment.article
+++ /dev/null
@@ -1,1316 +0,0 @@
-# Experiment, Simplify, Ship
-1 Aug 2019
-Tags: community, go2, proposals
-Summary: How we develop Go, a talk from GopherCon 2019.
-
-Russ Cox
-
-## Introduction
-
-This is the blog post version of my talk last week at GopherCon 2019.
-
-.iframe //www.youtube.com/embed/kNHo788oO5Y?rel=0 309 549
-
-We are all on the path to Go 2, together,
-but none of us know exactly where that path leads
-or sometimes even which direction the path goes.
-This post discusses how we actually
-find and follow the path to Go 2.
-Here’s what the process looks like.
-
-<div style="margin-left: 2em;">
-.image experiment/expsimp1.png _ 179
-</div>
-
-We experiment with Go as it exists now,
-to understand it better,
-learning what works well and what doesn’t.
-Then we experiment with possible changes,
-to understand them better,
-again learning what works well and what doesn’t.
-Based on what we learn from those experiments,
-we simplify.
-And then we experiment again.
-And then we simplify again.
-And so on.
-And so on.
-
-## The Four R’s of Simplifying
-
-During this process, there are four main ways that we can simplify
-the overall experience of writing Go programs:
-reshaping, redefining, removing, and restricting.
-
-**Simplify by Reshaping**
-
-The first way we simplify is by reshaping what exists into a new form,
-one that ends up being simpler overall.
-
-Every Go program we write serves as an experiment to test Go itself.
-In the early days of Go, we quickly learned that
-it was common to write code like this `addToList` function:
-
-	func addToList(list []int, x int) []int {
-		n := len(list)
-		if n+1 > cap(list) {
-			big := make([]int, n, (n+5)*2)
-			copy(big, list)
-			list = big
-		}
-		list = list[:n+1]
-		list[n] = x
-		return list
-	}
-
-We’d write the same code for slices of bytes,
-and slices of strings, and so on.
-Our programs were too complex, because Go was too simple.
-
-So we took the many functions like `addToList` in our programs
-and reshaped them into one function provided by Go itself.
-Adding `append` made the Go language a little more complex,
-but on balance
-it made the overall experience of writing Go programs simpler,
-even after accounting for the cost of learning about `append`.
-
-Here’s another example.
-For Go 1, we looked at the very many development tools
-in the Go distribution, and we reshaped them into one new command.
-
-	5a      8g
-	5g      8l
-	5l      cgo
-	6a      gobuild
-	6cov    gofix         →     go
-	6g      goinstall
-	6l      gomake
-	6nm     gopack
-	8a      govet
-
-The `go` command is so central now that
-it is easy to forget that we went so long without it and how much extra work that involved.
-
-We added code and complexity to the Go distribution,
-but on balance we simplified the experience of writing Go programs.
-The new structure also created space for other interesting experiments,
-which we’ll see later.
-
-**Simplify by Redefining**
-
-A second way we simplify is by redefining
-functionality we already have,
-allowing it to do more.
-Like simplifying by reshaping,
-simplifying by redefining makes programs simpler to write,
-but now with nothing new to learn.
-
-For example, `append` was originally defined to read only from slices.
-When appending to a byte slice, you could append the bytes from another byte slice,
-but not the bytes from a string.
-We redefined append to allow appending from a string,
-without adding anything new to the language.
-
-	var b []byte
-	var more []byte
-	b = append(b, more...) // ok
-
-	var b []byte
-	var more string
-	b = append(b, more...) // ok later
-
-**Simplify by Removing**
-
-A third way we simplify is by removing functionality
-when it has turned out to be less useful
-or less important than we expected.
-Removing functionality means one less thing to learn,
-one less thing to fix bugs in,
-one less thing to be distracted by or use incorrectly.
-Of course, removing also
-forces users to update existing programs,
-perhaps making them more complex,
-to make up for the removal.
-But the overall result can still be that the
-process of writing Go programs becomes simpler.
-
-An example of this is when we removed
-the boolean forms of non-blocking channel operations from the language:
-
-	ok := c <- x  // before Go 1, was non-blocking send
-	x, ok := <-c  // before Go 1, was non-blocking receive
-
-These operations were also possible to do using `select`,
-making it confusing to need to decide which form to use.
-Removing them simplified the language without reducing its power.
-
-**Simplify by Restricting**
-
-We can also simplify by restricting what is allowed.
-From day one, Go has restricted the encoding of Go source files:
-they must be UTF-8.
-This restriction makes every program that tries to read Go source files simpler.
-Those programs don’t have to worry about Go source files
-encoded in Latin-1 or UTF-16 or UTF-7 or anything else.
-
-Another important restriction is `gofmt` for program formatting.
-Nothing rejects Go code that isn’t formatted using `gofmt`,
-but we have established a convention that tools that rewrite Go programs
-leave them in `gofmt` form.
-If you keep your programs in `gofmt` form too,
-then these rewriters don’t make any formatting changes.
-When you compare before and after,
-the only diffs you see are real changes.
-This restriction has simplified program rewriters
-and led to successful experiments like
-`goimports`, `gorename`, and many others.
-
-## Go Development Process
-
-This cycle of experiment and simplify is a good model for what we’ve been doing the past ten years.
-but it has a problem:
-it’s too simple.
-We can’t only experiment and simplify.
-
-We have to ship the result.
-We have to make it available to use.
-Of course, using it enables more experiments,
-and possibly more simplifying,
-and the process cycles on and on.
-
-<div style="margin-left: 2em;">
-.image experiment/expsimp2.png _ 326
-</div>
-
-We shipped Go to all of you for the first time
-on November 10, 2009.
-Then, with your help, we shipped Go 1 together in March 2012.
-And we’ve shipped twelve Go releases since then.
-All of these were important milestones,
-to enable more experimentation,
-to help us learn more about Go,
-and of course to make Go available for production use.
-
-When we shipped Go 1,
-we explicitly shifted our focus to using Go,
-to understand this version of the language much better
-before trying any more simplifications involving
-language changes.
-We needed to take time to experiment,
-to really understand what works and what doesn’t.
-
-Of course, we’ve had twelve releases since Go 1,
-so we have still been experimenting and simplifying and shipping.
-But we’ve focused on ways to simplify Go development
-without significant language changes and without breaking
-existing Go programs.
-For example, Go 1.5 shipped the first concurrent garbage collector
-and then the following releases improved it,
-simplifying Go development by removing pause times as an ongoing concern.
-
-At Gophercon in 2017, we announced that after five years of
-experimentation, it was again time
-to think about
-significant changes that would simplify Go development.
-Our path to Go 2 is really the same as the path to Go 1:
-experiment and simplify and ship,
-towards an overall goal of simplifying Go development.
-
-For Go 2, the concrete topics that we believed were
-most important to address are
-error handling, generics, and dependencies.
-Since then we have realized that another
-important topic is developer tooling.
-
-The rest of this post discusses how
-our work in each of these areas
-follows that path.
-Along the way,
-we’ll take one detour,
-stopping to inspect the technical detail
-of what will be shipping soon in Go 1.13
-for error handling.
-
-## Errors
-
-It is hard enough to write a program
-that works the right way in all cases
-when all the inputs are valid and correct
-and nothing the program depends on is failing.
-When you add errors into the mix,
-writing a program that works the right way
-no matter what goes wrong is even harder.
-
-As part of thinking about Go 2,
-we want to understand better
-whether Go can help make that job any simpler.
-
-There are two different aspects that could
-potentially be simplified:
-error values and error syntax.
-We’ll look at each in turn,
-with the technical detour I promised focusing
-on the Go 1.13 error value changes.
-
-**Error Values**
-
-Error values had to start somewhere.
-Here is the `Read` function from the first version of the `os` package:
-
-	export func Read(fd int64, b *[]byte) (ret int64, errno int64) {
-		r, e := syscall.read(fd, &b[0], int64(len(b)));
-		return r, e
-	}
-
-There was no `File` type yet, and also no error type.
-`Read` and the other functions in the package
-returned an `errno int64` directly from the underlying Unix system call.
-
-This code was checked in on September 10, 2008 at 12:14pm.
-Like everything back then, it was an experiment,
-and code changed quickly.
-Two hours and five minutes later, the API changed:
-
-	export type Error struct { s string }
-
-	func (e *Error) Print() { … } // to standard error!
-	func (e *Error) String() string { … }
-
-	export func Read(fd int64, b *[]byte) (ret int64, err *Error) {
-		r, e := syscall.read(fd, &b[0], int64(len(b)));
-		return r, ErrnoToError(e)
-	}
-
-This new API introduced the first `Error` type.
-An error held a string and could return that string
-and also print it to standard error.
-
-The intent here was to generalize beyond integer codes.
-We knew from past experience
-that operating system error numbers were too limited
-a representation,
-that it would simplify programs not to have to shoehorn
-all detail about an error into 64 bits.
-Using error strings had worked reasonably well
-for us in the past, so we did the same here.
-This new API lasted seven months.
-
-The next April, after more experience using interfaces,
-we decided to generalize further
-and allow user-defined error implementations,
-by making the `os.Error` type itself an interface.
-We simplified by removing the `Print` method.
-
-For Go 1 two years later,
-based on a suggestion by Roger Peppe,
-`os.Error` became the built-in `error` type,
-and the `String` method was renamed to `Error`.
-Nothing has changed since then.
-But we have written many Go programs,
-and as a result we have experimented a lot with how
-best to implement and use errors.
-
-**Errors Are Values**
-
-Making `error` a simple interface
-and allowing many different implementations
-means we have the entire Go language
-available to define and inspect errors.
-We like to say that [errors are values](https://blog.golang.org/errors-are-values),
-the same as any other Go value.
-
-Here’s an example.
-On Unix,
-an attempt to dial a network connection
-ends up using the `connect` system call.
-That system call returns a `syscall.Errno`,
-which is a named integer type that represents
-a system call error number
-and implements the `error` interface:
-
-	package syscall
-
-	type Errno int64
-
-	func (e Errno) Error() string { ... }
-
-	const ECONNREFUSED = Errno(61)
-
-	    ... err == ECONNREFUSED ...
-
-The `syscall` package also defines named constants
-for the host operating system’s defined error numbers.
-In this case, on this system, `ECONNREFUSED` is number 61.
-Code that gets an error from a function
-can test whether the error is `ECONNREFUSED`
-using ordinary [value equality](https://golang.org/ref/spec#Comparison_operators).
-
-Moving up a level,
-in package `os`,
-any system call failure is reported using
-a larger error structure that records what
-operation was attempted in addition to the error.
-There are a handful of these structures.
-This one, `SyscallError`, describes an error
-invoking a specific system call
-with no additional information recorded:
-
-	package os
-
-	type SyscallError struct {
-		Syscall string
-		Err     error
-	}
-
-	func (e *SyscallError) Error() string {
-		return e.Syscall + ": " + e.Err.Error()
-	}
-
-Moving up another level,
-in package `net`,
-any network failure is reported using an even
-larger error structure that records the details
-of the surrounding network operation,
-such as dial or listen,
-and the network and addresses involved:
-
-	package net
-
-	type OpError struct {
-		Op     string
-		Net    string
-		Source Addr
-		Addr   Addr
-		Err    error
-	}
-
-	func (e *OpError) Error() string { ... }
-
-Putting these together,
-the errors returned by operations like `net.Dial` can format as strings,
-but they are also structured Go data values.
-In this case, the error is a `net.OpError`, which adds context
-to an `os.SyscallError`, which adds context to a `syscall.Errno`:
-
-	c, err := net.Dial("tcp", "localhost:50001")
-
-	// "dial tcp [::1]:50001: connect: connection refused"
-
-	err is &net.OpError{
-		Op:   "dial",
-		Net:  "tcp",
-		Addr: &net.TCPAddr{IP: ParseIP("::1"), Port: 50001},
-		Err: &os.SyscallError{
-			Syscall: "connect",
-			Err:     syscall.Errno(61), // == ECONNREFUSED
-		},
-	}
-
-When we say errors are values, we mean both that
-the entire Go language is available to define them
-and also that
-the entire Go language is available to inspect them.
-
-Here is an example from package net.
-It turns out that when you attempt a socket connection,
-most of the time you will get connected or get connection refused,
-but sometimes you can get a spurious `EADDRNOTAVAIL`,
-for no good reason.
-Go shields user programs from this failure mode by retrying.
-To do this, it has to inspect the error structure to find out
-whether the `syscall.Errno` deep inside is `EADDRNOTAVAIL`.
-
-Here is the code:
-
-	func spuriousENOTAVAIL(err error) bool {
-		if op, ok := err.(*OpError); ok {
-			err = op.Err
-		}
-		if sys, ok := err.(*os.SyscallError); ok {
-			err = sys.Err
-		}
-		return err == syscall.EADDRNOTAVAIL
-	}
-
-A [type assertion](https://golang.org/ref/spec#Type_assertions) peels away any `net.OpError` wrapping.
-And then a second type assertion peels away any `os.SyscallError` wrapping.
-And then the function checks the unwrapped error for equality with `EADDRNOTAVAIL`.
-
-What we’ve learned from years of experience,
-from this experimenting with Go errors,
-is that it is very powerful to be able to define
-arbitrary implementations of the `error` interface,
-to have the full Go language available
-both to construct and to deconstruct errors,
-and not to require the use of any single implementation.
-
-These properties—that errors are values,
-and that there is not one required error implementation—are
-important to preserve.
-
-Not mandating one error implementation
-enabled everyone to experiment with
-additional functionality that an error might provide,
-leading to many packages,
-such as
-[github.com/pkg/errors](https://godoc.org/github.com/pkg/errors),
-[gopkg.in/errgo.v2](https://godoc.org/gopkg.in/errgo.v2),
-[github.com/hashicorp/errwrap](https://godoc.org/github.com/hashicorp/errwrap),
-[upspin.io/errors](https://godoc.org/upspin.io/errors),
-[github.com/spacemonkeygo/errors](https://godoc.org/github.com/spacemonkeygo/errors),
-and more.
-
-One problem with unconstrained experimentation,
-though, is that as a client
-you have to program to the union of
-all the possible implementations you might encounter.
-A simplification that seemed worth exploring for Go 2
-was to define a standard version of commonly-added functionality,
-in the form of agreed-upon optional interfaces,
-so that different implementations could interoperate.
-
-**Unwrap**
-
-The most commonly-added functionality
-in these packages is some method that can be
-called to remove context from an error,
-returning the error inside.
-Packages use different names and meanings
-for this operation, and sometimes it removes one level of context,
-while sometimes it removes as many levels as possible.
-
-For Go 1.13, we have introduced a convention that an error
-implementation adding removable context to an inner error
-should implement an `Unwrap` method that returns the inner error,
-unwrapping the context.
-If there is no inner error appropriate to expose to callers,
-either the error shouldn’t have an `Unwrap` method,
-or the `Unwrap` method should return nil.
-
-	// Go 1.13 optional method for error implementations.
-
-	interface {
-		// Unwrap removes one layer of context,
-		// returning the inner error if any, or else nil.
-		Unwrap() error
-	}
-
-The way to call this optional method is to invoke the helper function `errors.Unwrap`,
-which handles cases like the error itself being nil or not having an `Unwrap` method at all.
-
-	package errors
-
-	// Unwrap returns the result of calling
-	// the Unwrap method on err,
-	// if err’s type defines an Unwrap method.
-	// Otherwise, Unwrap returns nil.
-	func Unwrap(err error) error
-
-We can use the `Unwrap` method
-to write a simpler, more general version of `spuriousENOTAVAIL`.
-Instead of looking for specific error wrapper implementations
-like `net.OpError` or `os.SyscallError`,
-the general version can loop, calling `Unwrap` to remove context,
-until either it reaches `EADDRNOTAVAIL` or there’s no error left:
-
-	func spuriousENOTAVAIL(err error) bool {
-		for err != nil {
-			if err == syscall.EADDRNOTAVAIL {
-				return true
-			}
-			err = errors.Unwrap(err)
-		}
-		return false
-	}
-
-This loop is so common, though, that Go 1.13 defines a second function, `errors.Is`,
-that repeatedly unwraps an error looking for a specific target.
-So we can replace the entire loop with a single call to `errors.Is`:
-
-	func spuriousENOTAVAIL(err error) bool {
-		return errors.Is(err, syscall.EADDRNOTAVAIL)
-	}
-
-At this point we probably wouldn’t even define the function;
-it would be equally clear, and simpler, to call `errors.Is` directly at the call sites.
-
-Go 1.13 also introduces a function `errors.As`
-that unwraps until it finds a specific implementation type.
-
-If you want to write code that works with
-arbitrarily-wrapped errors,
-`errors.Is` is the wrapper-aware
-version of an error equality check:
-
-	err == target
-
-	    →
-
-	errors.Is(err, target)
-
-And `errors.As` is the wrapper-aware
-version of an error type assertion:
-
-	target, ok := err.(*Type)
-	if ok {
-	    ...
-	}
-
-	    →
-
-	var target *Type
-	if errors.As(err, &target) {
-	   ...
-	}
-
-**To Unwrap Or Not To Unwrap?**
-
-Whether to make it possible to unwrap an error is an API decision,
-the same way that whether to export a struct field is an API decision.
-Sometimes it is appropriate to expose that detail to calling code,
-and sometimes it isn’t.
-When it is, implement Unwrap.
-When it isn’t, don’t implement Unwrap.
-
-Until now, `fmt.Errorf` has not exposed
-an underlying error formatted with `%v` to caller inspection.
-That is, the result of `fmt.Errorf` has not been possible to unwrap.
-Consider this example:
-
-	// errors.Unwrap(err2) == nil
-	// err1 is not available (same as earlier Go versions)
-	err2 := fmt.Errorf("connect: %v", err1)
-
-If `err2` is returned to
-a caller, that caller has never had any way to open up `err2` and access `err1`.
-We preserved that property in Go 1.13.
-
-For the times when you do want to allow unwrapping the result of `fmt.Errorf`,
-we also added a new printing verb `%w`, which formats like `%v`,
-requires an error value argument,
-and makes the resulting error’s `Unwrap` method return that argument.
-In our example, suppose we replace `%v` with `%w`:
-
-	// errors.Unwrap(err4) == err3
-	// (%w is new in Go 1.13)
-	err4 := fmt.Errorf("connect: %w", err3)
-
-Now, if `err4` is returned to a caller,
-the caller can use `Unwrap` to retrieve `err3`.
-
-It is important to note that absolute rules like
-“always use `%v` (or never implement `Unwrap`)” or “always use `%w` (or always implement `Unwrap`)”
-are as wrong as absolute rules like “never export struct fields” or “always export struct fields.”
-Instead, the right decision depends on
-whether callers should be able to inspect and depend on
-the additional information that using `%w` or implementing `Unwrap` exposes.
-
-As an illustration of this point,
-every error-wrapping type in the standard library
-that already had an exported `Err` field
-now also has an `Unwrap` method returning that field,
-but implementations with unexported error fields do not,
-and existing uses of `fmt.Errorf` with `%v` still use `%v`, not `%w`.
-
-**Error Value Printing (Abandoned)**
-
-Along with the design draft for Unwrap,
-we also published a
-[design draft for an optional method for richer error printing](https://golang.org/design/go2draft-error-printing),
-including stack frame information
-and support for localized, translated errors.
-
-	// Optional method for error implementations
-	type Formatter interface {
-		Format(p Printer) (next error)
-	}
-
-	// Interface passed to Format
-	type Printer interface {
-		Print(args ...interface{})
-		Printf(format string, args ...interface{})
-		Detail() bool
-	}
-
-This one is not as simple as `Unwrap`,
-and I won’t go into the details here.
-As we discussed the design with the Go community over the winter,
-we learned that the design wasn’t simple enough.
-It was too hard for individual error types to implement,
-and it did not help existing programs enough.
-On balance, it did not simplify Go development.
-
-As a result of this community discussion,
-we abandoned this printing design.
-
-**Error Syntax**
-
-That was error values.
-Let’s look briefly at error syntax,
-another abandoned experiment.
-
-Here is some code from
-[`compress/lzw/writer.go`](https://go.googlesource.com/go/+/go1.12/src/compress/lzw/writer.go#209) in the standard library:
-
-	// Write the savedCode if valid.
-	if e.savedCode != invalidCode {
-		if err := e.write(e, e.savedCode); err != nil {
-			return err
-		}
-		if err := e.incHi(); err != nil && err != errOutOfCodes {
-			return err
-		}
-	}
-
-	// Write the eof code.
-	eof := uint32(1)<<e.litWidth + 1
-	if err := e.write(e, eof); err != nil {
-		return err
-	}
-
-At a glance, this code is about half error checks.
-My eyes glaze over when I read it.
-And we know that code that is tedious to write and tedious to read is easy to misread,
-making it a good home for hard-to-find bugs.
-For example, one of these three error checks is not like the others,
-a fact that is easy to miss on a quick skim.
-If you were debugging this code, how long would it take to notice that?
-
-At Gophercon last year we
-[presented a draft design](https://golang.org/design/go2draft-error-handling)
-for a new control flow construct marked by the keyword `check`.
-`Check` consumes the error result from a function call or expression.
-If the error is non-nil, the `check` returns that error.
-Otherwise the `check` evaluates to the other results
-from the call. We can use `check` to simplify the lzw code:
-
-	// Write the savedCode if valid.
-	if e.savedCode != invalidCode {
-		check e.write(e, e.savedCode)
-		if err := e.incHi(); err != errOutOfCodes {
-			check err
-		}
-	}
-
-	// Write the eof code.
-	eof := uint32(1)<<e.litWidth + 1
-	check e.write(e, eof)
-
-This version of the same code uses `check`,
-which removes four lines of code and
-more importantly highlights that
-the call to `e.incHi` is allowed to return `errOutOfCodes`.
-
-Maybe most importantly,
-the design also allowed defining error handler blocks
-to be run when later checks failed.
-That would let you write shared context-adding code just once,
-like in this snippet:
-
-	handle err {
-		err = fmt.Errorf("closing writer: %w", err)
-	}
-
-	// Write the savedCode if valid.
-	if e.savedCode != invalidCode {
-		check e.write(e, e.savedCode)
-		if err := e.incHi(); err != errOutOfCodes {
-			check err
-		}
-	}
-
-	// Write the eof code.
-	eof := uint32(1)<<e.litWidth + 1
-	check e.write(e, eof)
-
-In essence, `check` was a short way to write the `if` statement,
-and `handle` was like
-[`defer`](https://golang.org/ref/spec#Defer_statements) but only for error return paths.
-In contrast to exceptions in other languages,
-this design retained Go’s important property that
-every potential failing call was marked explicitly in the code,
-now using the `check` keyword instead of `if err != nil`.
-
-The big problem with this design
-was that `handle` overlapped too much,
-and in confusing ways, with `defer`.
-
-In May we posted
-[a new design with three simplifications](https://golang.org/design/32437-try-builtin):
-to avoid the confusion with `defer`, the design dropped `handle` in favor of just using `defer`;
-to match a similar idea in Rust and Swift, the design renamed `check` to `try`;
-and to allow experimentation in a way that existing parsers like `gofmt` would recognize,
-it changed `check` (now `try`) from a keyword to a built-in function.
-
-Now the same code would look like this:
-
-	defer errd.Wrapf(&err, "closing writer")
-
-	// Write the savedCode if valid.
-	if e.savedCode != invalidCode {
-		try(e.write(e, e.savedCode))
-		if err := e.incHi(); err != errOutOfCodes {
-			try(err)
-		}
-	}
-
-	// Write the eof code.
-	eof := uint32(1)<<e.litWidth + 1
-	try(e.write(e, eof))
-
-We spent most of June discussing this proposal publicly on GitHub.
-
-The fundamental idea of `check` or `try` was to shorten
-the amount of syntax repeated at each error check,
-and in particular to remove the `return` statement from view,
-keeping the error check explicit and better highlighting interesting variations.
-One interesting point raised during the public feedback discussion,
-however, was that without an explicit `if` statement and `return`,
-there’s nowhere to put a debugging print,
-there’s nowhere to put a breakpoint,
-and there’s no code to show as unexecuted in code coverage results.
-The benefits we were after
-came at the cost of making these situations more complex.
-On balance, from this as well as other considerations,
-it was not at all clear that the overall result would
-be simpler Go development,
-so we abandoned this experiment.
-
-That’s everything about error handling,
-which was one of the main focuses for this year.
-
-## Generics
-
-Now for something a little less controversial: generics.
-
-The second big topic we identified for Go 2 was
-some kind of way to write code with
-type parameters.
-This would enable writing generic data structures
-and also writing generic functions that
-work with any kind of slice,
-or any kind of channel,
-or any kind of map.
-For example, here is a generic channel filter:
-
-	// Filter copies values from c to the returned channel,
-	// passing along only those values satisfying f.
-	func Filter(type value)(f func(value) bool, c <-chan value) <-chan value {
-		out := make(chan value)
-		go func() {
-			for v := range c {
-				if f(v) {
-					out <- v
-				}
-			}
-			close(out)
-		}()
-		return out
-	}
-
-We’ve been thinking about generics since work on Go began,
-and we wrote and rejected our first concrete design in 2010.
-We wrote and rejected three more designs by the end of 2013.
-Four abandoned experiments,
-but not failed experiments,
-We learned from them,
-like we learned from `check` and `try`.
-Each time, we learned that the path to Go 2 is not in that exact direction,
-and we noticed other directions that might be interesting to explore.
-But by 2013 we had decided that we needed to focus on other concerns,
-so we put the entire topic aside for a few years.
-
-Last year we started exploring and experimenting again,
-and we presented a
-[new design](https://github.com/golang/proposal/blob/master/design/go2draft-contracts.md),
-based on the idea of a contract,
-at Gophercon last summer.
-We’ve continued to experiment and simplify,
-and we’ve been working
-with programming language theory experts
-to understand the design better.
-
-Overall, I am hopeful that we’re headed in a good direction,
-toward a design that will simplify Go development.
-Even so, we might find that this design doesn’t work either.
-We might have to abandon this experiment
-and adjust our path based on what we learned.
-We’ll find out.
-
-At Gophercon 2019, Ian Lance Taylor talked about
-why we might want to add generics to Go
-and briefly previewed the latest design draft.
-For details, see his blog post “[Why Generics?](https://blog.golang.org/why-generics)”
-
-## Dependencies
-
-The third big topic we identified for Go 2 was dependency management.
-
-In 2010 we published a tool called `goinstall`,
-which we called
-“[an experiment in package installation](https://groups.google.com/forum/#!msg/golang-nuts/8JFwR3ESjjI/cy7qZzN7Lw4J).”
-It downloaded dependencies and stored them in your
-Go distribution tree, in GOROOT.
-
-As we experimented with `goinstall`,
-we learned that the Go distribution and the installed packages
-should be kept separate,
-so that it was possible to change to a new Go distribution
-without losing all your Go packages.
-So in 2011 we introduced `GOPATH`,
-an environment variable that specified
-where to look for packages not found in the main Go distribution.
-
-Adding GOPATH created more places for Go packages
-but simplified Go development overall,
-by separating your Go distribution from your Go libraries.
-
-**Compatibility**
-
-The `goinstall` experiment intentionally left out
-an explicit concept of package versioning.
-Instead, `goinstall` always downloaded the latest copy.
-We did this so we could focus on the other
-design problems for package installation.
-
-`Goinstall` became `go get` as part of Go 1.
-When people asked about versions,
-we encouraged them to experiment by
-creating additional tools, and they did.
-And we encouraged package AUTHORS
-to provide their USERS
-with the same backwards compatibility
-we did for the Go 1 libraries.
-Quoting [the Go FAQ](https://golang.org/doc/faq#get_version):
-
-<div style="margin-left: 2em; font-style: italic;">
-
-“Packages intended for public use should try to maintain backwards compatibility as they evolve.
-
-If different functionality is required,
-add a new name instead of changing an old one.
-
-If a complete break is required,
-create a new package with a new import path.”
-
-</div>
-
-This convention
-simplifies the overall experience of using a package
-by restricting what authors can do:
-avoid breaking changes to APIs;
-give new functionality a new name;
-and
-give a whole new package design a new import path.
-
-Of course, people kept experimenting.
-One of the most interesting experiments
-was started by Gustavo Niemeyer.
-He created a Git redirector called
-[`gopkg.in`](https://gopkg.in),
-which provided different import paths
-for different API versions,
-to help package authors
-follow the convention
-of giving a new package design
-a new import path.
-
-For example,
-the Go source code in the GitHub repository
-[go-yaml/yaml](https://github.com/go-yaml/yaml)
-has different APIs
-in the v1 and v2 semantic version tags.
-The `gopkg.in` server provides these with
-different import paths
-[gopkg.in/yaml.v1](https://godoc.org/gopkg.in/yaml.v1)
-and
-[gopkg.in/yaml.v2](https://godoc.org/gopkg.in/yaml.v2).
-
-The convention of providing backwards compatibility,
-so that a newer version of a package can be used
-in place of an older version,
-is what makes `go get`’s very simple rule—“always download the latest copy”—work well even today.
-
-**Versioning And Vendoring**
-
-But in production contexts you need to be more precise
-about dependency versions, to make builds reproducible.
-
-Many people experimented with what that should look like,
-building tools that served their needs,
-including Keith Rarick’s `goven` (2012) and `godep` (2013),
-Matt Butcher’s `glide` (2014), and Dave Cheney’s `gb` (2015).
-All of these tools use the model that you copy dependency
-packages into your own source control repository.
-The exact mechanisms used
-to make those packages available for import varied,
-but they were all more complex than it seemed they should be.
-
-After a community-wide discussion,
-we adopted a proposal by Keith Rarick
-to add explicit support for referring to copied dependencies
-without GOPATH tricks.
-This was simplifying by reshaping:
-like with `addToList` and `append`,
-these tools were already implementing the concept,
-but it was more awkward than it needed to be.
-Adding explicit support for vendor directories
-made these uses simpler overall.
-
-Shipping vendor directories in the `go` command
-led to more experimentation with vendoring itself,
-and we realized that we had introduced a few problems.
-The most serious was that we lost _package uniqueness_.
-Before, during any given build,
-an import path
-might appear in lots of different packages,
-and all the imports referred to the same target.
-Now with vendoring, the same import path in different
-packages might refer to different vendored copies of the package,
-all of which would appear in the final resulting binary.
-
-At the time, we didn’t have a name for this property:
-package uniqueness.
-It was just how the GOPATH model worked.
-We didn’t completely appreciate it until it went away.
-
-There is a parallel here with the `check` and `try`
-error syntax proposals.
-In that case, we were relying
-on how the visible `return` statement worked
-in ways we didn’t appreciate
-until we considered removing it.
-
-When we added vendor directory support,
-there were many different tools for managing dependencies.
-We thought that a clear agreement
-about the format of vendor directories
-and vendoring metadata
-would allow the various tools to interoperate,
-the same way that agreement about
-how Go programs are stored in text files
-enables interoperation
-between the Go compiler, text editors,
-and tools like `goimports` and `gorename`.
-
-This turned out to be naively optimistic.
-The vendoring tools all differed in subtle semantic ways.
-Interoperation would require changing them all
-to agree about the semantics,
-likely breaking their respective users.
-Convergence did not happen.
-
-**Dep**
-
-At Gophercon in 2016, we started an effort
-to define a single tool to manage dependencies.
-As part of that effort, we conducted surveys
-with many different kinds of users
-to understand what they needed
-as far as dependency management,
-and a team started work on a new tool,
-which became `dep`.
-
-`Dep` aimed to be able to replace all the
-existing dependency management tools.
-The goal was to simplify by reshaping the
-existing different tools into a single one.
-It partly accomplished that.
-`Dep` also restored package uniqueness for its users,
-by having only one vendor directory
-at the top of the project tree.
-
-But `dep` also introduced a serious problem
-that took us a while to fully appreciate.
-The problem was that `dep` embraced a design choice from `glide`,
-to support and encourage incompatible changes to a given package
-without changing the import path.
-
-Here is an example.
-Suppose you are building your own program,
-and you need to have a configuration file,
-so you use version 2 of a popular Go YAML package:
-
-<div style="margin-left: 2em;">
-.image experiment/yamldeps1.png _ 214
-</div>
-
-Now suppose your program
-imports the Kubernetes client.
-It turns out that Kubernetes uses YAML extensively,
-and it uses version 1 of the same popular package:
-
-<div style="margin-left: 2em;">
-.image experiment/yamldeps2.png _ 557
-</div>
-
-Version 1 and version 2 have incompatible APIs,
-but they also have different import paths,
-so there is no ambiguity about which is meant by a given import.
-Kubernetes gets version 1,
-your config parser gets version 2,
-and everything works.
-
-`Dep` abandoned this model.
-Version 1 and version 2 of the yaml package would now
-have the same import path,
-producing a conflict.
-Using the same import path for two incompatible versions,
-combined with package uniqueness,
-makes it impossible to build this program
-that you could build before:
-
-<div style="margin-left: 2em;">
-.image experiment/yamldeps3.png _ 450
-</div>
-
-It took us a while to understand this problem,
-because we had been applying the
-“new API means new import path”
-convention for so long that we took it for granted.
-The dep experiment helped us
-appreciate that convention better,
-and we gave it a name:
-the _import compatibility rule_:
-
-<div style="margin-left: 2em; font-style: italic;">
-
-“If an old package and a new package have the same import path,
-the new package must be backwards compatible with the old package.”
-
-</div>
-
-**Go Modules**
-
-We took what worked well in the dep experiment
-and what we learned about what didn’t work well,
-and we experimented with a new design, called `vgo`.
-In `vgo`, packages followed the import compatibility rule,
-so that we can provide package uniqueness
-but still not break builds like the one we just looked at.
-This let us simplify other parts of the design as well.
-
-Besides restoring the import compatibility rule,
-another important part of the `vgo` design
-was to give the concept of a group of packages a name
-and to allow that grouping to be separated
-from source code repository boundaries.
-The name of a group of Go packages is a module,
-so we refer to the system now as Go modules.
-
-Go modules are now integrated with the `go` command,
-which avoids needing to copy around vendor directories at all.
-
-**Replacing GOPATH**
-
-With Go modules comes the end of GOPATH as a
-global name space.
-Nearly all the hard work of converting existing Go usage
-and tools to modules is caused by this change,
-from moving away from GOPATH.
-
-The fundamental idea of GOPATH
-is that the GOPATH directory tree
-is the global source of truth
-for what versions are being used,
-and the versions being used don’t change
-as you move around between directories.
-But the global GOPATH mode is in direct
-conflict with the production requirement of
-per-project reproducible builds,
-which itself simplifies the Go development
-and deployment experience in many important ways.
-
-Per-project reproducible builds means that
-when you are working in a checkout of project A,
-you get the same set of dependency versions that the other developers of project A get
-at that commit,
-as defined by the `go.mod` file.
-When you switch to working in a checkout of project B,
-now you get that project’s chosen dependency versions,
-the same set that the other developers of project B get.
-But those are likely different from project A.
-The set of dependency versions
-changing when you move from project A to project B
-is necessary to keep your development in sync
-with that of the other developers on A and on B.
-There can’t be a single global GOPATH anymore.
-
-Most of the complexity of adopting modules
-arises directly from the loss of the one global GOPATH.
-Where is the source code for a package?
-Before, the answer depended only on your GOPATH environment variable,
-which most people rarely changed.
-Now, the answer depends on what project you are working on,
-which may change often.
-Everything needs updating for this new convention.
-
-Most development tools use the
-[`go/build`](https://godoc.org/go/build) package to find and load Go source code.
-We’ve kept that package working,
-but the API did not anticipate modules,
-and the workarounds we added to avoid API changes
-are slower than we’d like.
-We’ve published a replacement,
-[`golang.org/x/tools/go/packages`](https://godoc.org/golang.org/x/tools/go/packages).
-Developer tools should now use that instead.
-It supports both GOPATH and Go modules,
-and it is faster and easier to use.
-In a release or two we may move it into the standard library,
-but for now [`golang.org/x/tools/go/packages`](https://godoc.org/golang.org/x/tools/go/packages)
-is stable and ready for use.
-
-**Go Module Proxies**
-
-One of the ways modules simplify Go development
-is by separating the concept of a group of packages
-from the underlying source control repository
-where they are stored.
-
-When we talked to Go users about dependencies,
-almost everyone using Go at their companies
-asked how to route `go get` package fetches
-through their own servers,
-to better control what code can be used.
-And even open-source developers were concerned
-about dependencies disappearing
-or changing unexpectedly,
-breaking their builds.
-Before modules, users had attempted
-complex solutions to these problems,
-including intercepting the version control
-commands that the `go` command runs.
-
-The Go modules design makes it easy
-to introduce the idea of a module proxy
-that can be asked for a specific module version.
-
-Companies can now easily run their own module proxy,
-with custom rules about what is allowed
-and where cached copies are stored.
-The open-source [Athens project](https://docs.gomods.io) has built just such a proxy,
-and Aaron Schlesinger gave a talk about it at Gophercon 2019.
-(We’ll add a link here when the video becomes available.)
-
-And for individual developers and open source teams,
-the Go team at Google has [launched a proxy](https://groups.google.com/forum/#!topic/golang-announce/0wo8cOhGuAI) that serves
-as a public mirror of all open-source Go packages,
-and Go 1.13 will use that proxy by default when in module mode.
-Katie Hockman gave a [talk about this system at Gophercon 2019](https://youtu.be/KqTySYYhPUE).
-
-**Go Modules Status**
-
-Go 1.11 introduced modules as an experimental, opt-in preview.
-We keep experimenting and simplifying.
-Go 1.12 shipped improvements,
-and Go 1.13 will ship more improvements.
-
-Modules are now at the point
-where we believe that they will serve most users,
-but we aren’t ready to shut down GOPATH just yet.
-We will keep experimenting, simplifying, and revising.
-
-We fully recognize that
-the Go user community
-built up almost a decade of experience
-and tooling and workflows around GOPATH,
-and it will take a while to convert all of that to Go modules.
-
-But again,
-we think that modules will now
-work very well for most users,
-and I encourage you to take a look
-when Go 1.13 is released.
-
-As one data point,
-the Kubernetes project has a lot of dependencies,
-and they have migrated to using Go modules
-to manage them.
-You probably can too.
-And if you can’t,
-please let us know what’s not working for you
-or what’s too complex,
-by [filing a bug report](https://golang.org/issue/new),
-and we will experiment and simplify.
-
-## Tools
-
-Error handling, generics, and dependency management
-are going to take a few more years at least,
-and we’re going to focus on them for now.
-Error handling is close to done,
-modules will be next after that,
-and maybe generics after that.
-
-But suppose we look a couple years out,
-to when we are done experimenting and simplifying
-and have shipped error handling, modules, and generics.
-Then what?
-It’s very difficult to predict the future,
-but I think that once these three have shipped,
-that may mark the start of a new quiet period for major changes.
-Our focus at that point will likely shift to
-simplifying Go development with improved tools.
-
-Some of the tool work is already underway,
-so this post finishes by looking at that.
-
-While we helped update all the Go community’s
-existing tools to understand Go modules,
-we noticed that having a ton of development helper tools
-that each do one small job is not serving users well.
-The individual tools are too hard to combine,
-too slow to invoke, and too different to use.
-
-We began an effort to unify the most commonly-required
-development helpers into a single tool,
-now called `gopls` (pronounced “go, please”).
-`Gopls` speaks the
-[Language Server Protocol, LSP](https://langserver.org/),
-and works with any integrated development environment
-or text editor with LSP support,
-which is essentially everything at this point.
-
-`Gopls` marks an expansion in focus for the Go project,
-from delivering standalone compiler-like, command-line
-tools like go vet or gorename
-to also delivering a complete IDE service.
-Rebecca Stambler gave a talk with more details about `gopls` and IDEs at Gophercon 2019.
-(We’ll add a link here when the video becomes available.)
-
-After `gopls`, we also have ideas for reviving `go fix` in an
-extensible way and for making `go vet` even more helpful.
-
-## Coda
-
-<div style="margin-left: 2em;">
-.image experiment/expsimp2.png _ 326
-</div>
-
-So there’s the path to Go 2.
-We will experiment and simplify.
-And experiment and simplify.
-And ship.
-And experiment and simplify.
-And do it all again.
-It may look or even feel like the path goes around in circles.
-But each time we experiment and simplify
-we learn a little more about what Go 2 should look like
-and move another step closer to it.
-Even abandoned experiments like `try`
-or our first four generics designs
-or `dep` are not wasted time.
-They help us learn what needs to be
-simplified before we can ship,
-and in some cases they help us better understand
-something we took for granted.
-
-At some point we will realize we have
-experimented enough, and simplified enough,
-and shipped enough,
-and we will have Go 2.
-
-Thanks to all of you in the Go community
-for helping us experiment
-and simplify
-and ship
-and find our way on this path.
diff --git a/_content/experiment/expsimp1.graffle b/_content/experiment/expsimp1.graffle
deleted file mode 100644
index 3dd4a98..0000000
--- a/_content/experiment/expsimp1.graffle
+++ /dev/null
Binary files differ
diff --git a/_content/experiment/expsimp1.png b/_content/experiment/expsimp1.png
deleted file mode 100644
index 00f0709..0000000
--- a/_content/experiment/expsimp1.png
+++ /dev/null
Binary files differ
diff --git a/_content/experiment/expsimp2.graffle b/_content/experiment/expsimp2.graffle
deleted file mode 100644
index 551ea3a..0000000
--- a/_content/experiment/expsimp2.graffle
+++ /dev/null
Binary files differ
diff --git a/_content/experiment/expsimp2.png b/_content/experiment/expsimp2.png
deleted file mode 100644
index b94427e..0000000
--- a/_content/experiment/expsimp2.png
+++ /dev/null
Binary files differ
diff --git a/_content/experiment/yamldeps1.graffle b/_content/experiment/yamldeps1.graffle
deleted file mode 100644
index 48172e5..0000000
--- a/_content/experiment/yamldeps1.graffle
+++ /dev/null
Binary files differ
diff --git a/_content/experiment/yamldeps1.png b/_content/experiment/yamldeps1.png
deleted file mode 100644
index 134be30..0000000
--- a/_content/experiment/yamldeps1.png
+++ /dev/null
Binary files differ
diff --git a/_content/experiment/yamldeps2.graffle b/_content/experiment/yamldeps2.graffle
deleted file mode 100644
index 86e9586..0000000
--- a/_content/experiment/yamldeps2.graffle
+++ /dev/null
Binary files differ
diff --git a/_content/experiment/yamldeps2.png b/_content/experiment/yamldeps2.png
deleted file mode 100644
index ed3a1e5..0000000
--- a/_content/experiment/yamldeps2.png
+++ /dev/null
Binary files differ
diff --git a/_content/experiment/yamldeps3.graffle b/_content/experiment/yamldeps3.graffle
deleted file mode 100644
index 6d5d188..0000000
--- a/_content/experiment/yamldeps3.graffle
+++ /dev/null
Binary files differ
diff --git a/_content/experiment/yamldeps3.png b/_content/experiment/yamldeps3.png
deleted file mode 100644
index 439c23e..0000000
--- a/_content/experiment/yamldeps3.png
+++ /dev/null
Binary files differ
diff --git a/_content/external-libraries.article b/_content/external-libraries.article
deleted file mode 100644
index fc21c8e..0000000
--- a/_content/external-libraries.article
+++ /dev/null
@@ -1,80 +0,0 @@
-# Spotlight on external Go libraries
-3 Jun 2011
-Tags: community, libraries
-Summary: Some popular Go libraries and how to use them.
-OldURL: /spotlight-on-external-go-libraries
-
-Andrew Gerrand
-
-##
-
-While the Go authors have been working hard at improving Go's standard library,
-the greater community has created a growing ecosystem of external libraries.
-In this post we look at some popular Go libraries and how they can be used.
-
-[Mgo](http://labix.org/mgo) (pronounced "mango") is a MongoDB database driver.
-[MongoDB](http://www.mongodb.org/) is a [document-oriented database](http://en.wikipedia.org/wiki/Document-oriented_database)
-with a long list of features suitable for [a broad range of uses](http://www.mongodb.org/display/DOCS/Use%2BCases).
-The mgo package provides a rich, idiomatic Go API for working with MongoDB,
-from basic operations such as inserting and updating records to the more
-advanced [MapReduce](http://www.mongodb.org/display/DOCS/MapReduce) and
-[GridFS](http://www.mongodb.org/display/DOCS/GridFS) features.
-Mgo has a bunch of cool features including automated cluster discovery and
-result pre-fetching - see the [mgo homepage](http://labix.org/mgo) for
-details and example code.
-For working with large data sets Go, MongoDB,
-and mgo are a powerful combination.
-
-[Authcookie](https://github.com/dchest/authcookie) is a web library for
-generating and verifying user authentication cookies.
-It allows web servers to hand out cryptographically secure tokens tied to
-a specific user that will expire after a specified time period.
-It has a simple API that makes it straightforward to add authentication
-to existing web applications.
-See the [README file](https://github.com/dchest/authcookie/blob/master/README.md)
-for details and example code.
-
-[Go-charset](http://code.google.com/p/go-charset) provides support for
-converting between Go's standard UTF-8 encoding and a variety of character sets.
-The go-charset package implements a translating io.Reader and io.Writer
-so you can wrap existing Readers and Writers (such as network connections
-or file descriptors),
-making it easy to communicate with systems that use other character encodings.
-
-[Go-socket.io](https://github.com/madari/go-socket.io) is a Go implementation
-of [Socket.IO](http://socket.io/),
-a client/server API that allows web servers to push messages to web browsers.
-Depending on the capabilities of the user's browser,
-Socket.IO uses the best transport for the connection,
-be it modern websockets, AJAX long polling,
-or some [other mechanism](http://socket.io/#transports).
-Go-socket.io bridges the gap between Go servers and rich JavaScript clients
-for a wide range of browsers.
-To get a feel for go-socket.io see the [chat server example](https://github.com/madari/go-socket.io/blob/master/example/example.go).
-
-It's worth mentioning that these packages are [goinstallable](https://golang.org/cmd/goinstall/).
-With an up-to-date Go [installation](https://golang.org/doc/install.html)
-you can install them all with a single command:
-
-	goinstall launchpad.net/mgo \
-	    github.com/dchest/authcookie \
-	    go-charset.googlecode.com/hg/charset \
-	    github.com/madari/go-socket.io
-
-Once goinstalled, the packages can be imported using those same paths:
-
-	import (
-	    "launchpad.net/mgo"
-	    "github.com/dchest/authcookie"
-	    "go-charset.googlecode.com/hg/charset"
-	    "github.com/madari/go-socket.io"
-	)
-
-Also, as they are now a part of the local Go system,
-we can inspect their documentation with [godoc](https://golang.org/cmd/godoc/):
-
-	godoc launchpad.net/mgo Database # see docs for Database type
-
-Of course, this is just the tip of the iceberg;
-there are more great Go libraries listed on the [package dashboard](http://godashboard.appspot.com/package)
-and many more to come.
diff --git a/_content/first-go-program.article b/_content/first-go-program.article
deleted file mode 100644
index 2e25b14..0000000
--- a/_content/first-go-program.article
+++ /dev/null
@@ -1,122 +0,0 @@
-# The first Go program
-18 Jul 2013
-Tags: history
-Summary: Rob Pike dug up the first Go program ever written.
-
-Andrew Gerrand
-
-##
-
-Brad Fitzpatrick and I (Andrew Gerrand) recently started restructuring
-[godoc](https://golang.org/cmd/godoc/), and it occurred to me that it is one
-of the oldest Go programs.
-Robert Griesemer started writing it back in early 2009,
-and we're still using it today.
-
-When I [tweeted](https://twitter.com/enneff/status/357403054632484865) about
-this, Dave Cheney replied with an [interesting question](https://twitter.com/davecheney/status/357406479415914497):
-what is the oldest Go program? Rob Pike dug into his mail and found it
-in an old message to Robert and Ken Thompson.
-
-What follows is the first Go program. It was written by Rob in February 2008,
-when the team was just Rob, Robert, and Ken. They had a solid feature list
-(mentioned in [this blog post](https://commandcenter.blogspot.com.au/2012/06/less-is-exponentially-more.html))
-and a rough language specfication. Ken had just finished the first working version of
-a Go compiler (it didn't produce native code, but rather transliterated Go code
-to C for fast prototyping) and it was time to try writing a program with it.
-
-Rob sent mail to the "Go team":
-
-	From: Rob 'Commander' Pike
-	Date: Wed, Feb 6, 2008 at 3:42 PM
-	To: Ken Thompson, Robert Griesemer
-	Subject: slist
-
-	it works now.
-
-	roro=% a.out
-	(defn foo (add 12 34))
-	return: icounter = 4440
-	roro=%
-
-	here's the code.
-	some ugly hackery to get around the lack of strings.
-
-(The `icounter` line in the program output is the number of executed
-statements, printed for debugging.)
-
-.code first-go-program/slist.go
-
-The program parses and prints an
-[S-expression](https://en.wikipedia.org/wiki/S-expression).
-It takes no user input and has no imports, relying only on the built-in
-`print` facility for output.
-It was written literally the first day there was a
-[working but rudimentary compiler](https://golang.org/change/8b8615138da3).
-Much of the language wasn't implemented and some of it wasn't even specified.
-
-Still, the basic flavor of the language today is recognizable in this program.
-Type and variable declarations, control flow, and package statements haven't
-changed much.
-
-But there are many differences and absences.
-Most significant are the lack of concurrency and interfaces—both
-considered essential since day 1 but not yet designed.
-
-A `func` was a `function`, and its signature specified return values
-_before_ arguments, separating them with `<-`, which we now use as the channel
-send/receive operator. For example, the `WhiteSpace` function takes the integer
-`c` and returns a boolean.
-
-	function WhiteSpace(bool <- c int)
-
-This arrow was a stop-gap measure until a better syntax arose for declaring
-multiple return values.
-
-Methods were distinct from functions and had their own keyword.
-
-	method (this *Slist) Car(*Slist <-) {
-		return this.list.car;
-	}
-
-And methods were pre-declared in the struct definition, although that changed soon.
-
-	type Slist struct {
-		...
-		Car method(*Slist <-);
-	}
-
-There were no strings, although they were in the spec.
-To work around this, Rob had to build the input string as an `uint8` array with
-a clumsy construction. (Arrays were rudimentary and slices hadn't been designed
-yet, let alone implemented, although there was the unimplemented concept of an
-"open array".)
-
-	input[i] = '('; i = i + 1;
-	input[i] = 'd'; i = i + 1;
-	input[i] = 'e'; i = i + 1;
-	input[i] = 'f'; i = i + 1;
-	input[i] = 'n'; i = i + 1;
-	input[i] = ' '; i = i + 1;
-	...
-
-Both `panic` and `print` were built-in keywords, not pre-declared functions.
-
-	print "parse error: expected ", c, "\n";
-	panic "parse";
-
-And there are many other little differences; see if you can identify some others.
-
-Less than two years after this program was written, Go was released as an
-open source project. Looking back, it is striking how much the language has
-grown and matured. (The last thing to change between this proto-Go and the Go
-we know today was the elimination of semicolons.)
-
-But even more striking is how much we have learned about _writing_ Go code.
-For instance, Rob called his method receivers `this`, but now we use shorter
-context-specific names. There are hundreds of more significant examples
-and to this day we're still discovering better ways to write Go code.
-(Check out the [glog package](https://github.com/golang/glog)'s clever trick for
-[handling verbosity levels](https://github.com/golang/glog/blob/c6f9652c7179652e2fd8ed7002330db089f4c9db/glog.go#L893).)
-
-I wonder what we'll learn tomorrow.
diff --git a/_content/first-go-program/slist.go b/_content/first-go-program/slist.go
deleted file mode 100644
index bde7e2b..0000000
--- a/_content/first-go-program/slist.go
+++ /dev/null
@@ -1,322 +0,0 @@
-// +build OMIT
-
-package main
-
-// fake stuff
-type char uint8;
-
-// const char TESTSTRING[] = "(defn foo (add 'a 'b))\n";
-
-type Atom struct {
-        string  *[100]char;
-        integer int;
-        next    *Slist;  /* in hash bucket */
-}
-
-type List struct {
-        car     *Slist;
-        cdr     *Slist;
-}
-
-type Slist struct {
-        isatom          bool;
-        isstring        bool;
-        //union {
-        atom    Atom;
-        list    List;
-        //} u;
-
-        Free method();
-        Print method();
-        PrintOne method(doparen bool);
-        String method(*char <-);
-        Integer method(int <-);
-        Car method(*Slist <-);
-        Cdr method(*Slist <-);
-}
-
-method (this *Slist) Car(*Slist <-) {
-        return this.list.car;
-}
-
-method (this *Slist) Cdr(*Slist <-) {
-        return this.list.cdr;
-}
-
-method (this *Slist) String(*[100]char <-) {
-        return this.atom.string;
-}
-
-method (this *Slist) Integer(int <-) {
-        return this.atom.integer;
-}
-
-function OpenFile();
-function Parse(*Slist <-);
-
-//Slist* atom(char *s, int i);
-
-var token int;
-var peekc int = -1;
-var lineno int32 = 1;
-
-var input [100*1000]char;
-var inputindex int = 0;
-var tokenbuf [100]char;
-
-var EOF int = -1;  // BUG should be const
-
-function main(int32 <-) {
-        var list *Slist;
-
-        OpenFile();
-        for ;; {
-                list = Parse();
-                if list == nil {
-                        break;
-                }
-                list.Print();
-                list.Free();
-                break;
-        }
-
-        return 0;
-}
-
-method (slist *Slist) Free(<-) {
-        if slist == nil {
-                return;
-        }
-        if slist.isatom {
-//              free(slist.String());
-        } else {
-                slist.Car().Free();
-                slist.Cdr().Free();
-        }
-//      free(slist);
-}
-
-method (slist *Slist) PrintOne(<- doparen bool) {
-        if slist == nil {
-                return;
-        }
-        if slist.isatom {
-                if slist.isstring {
-                        print(slist.String());
-                } else {
-                        print(slist.Integer());
-                }
-        } else {
-                if doparen {
-                        print("(");
-                }
-                slist.Car().PrintOne(true);
-                if slist.Cdr() != nil {
-                        print(" ");
-                        slist.Cdr().PrintOne(false);
-                }
-                if doparen {
-                        print(")");
-                }
-        }
-}
-
-method (slist *Slist) Print() {
-        slist.PrintOne(true);
-        print "\n";
-}
-
-function Get(int <-) {
-        var c int;
-
-        if peekc >= 0 {
-                c = peekc;
-                peekc = -1;
-        } else {
-                c = convert(int, input[inputindex]);
-                inputindex = inputindex + 1; // BUG should be incr one expr
-                if c == '\n' {
-                        lineno = lineno + 1;
-                }
-                if c == '\0' {
-                        inputindex = inputindex - 1;
-                        c = EOF;
-                }
-        }
-        return c;
-}
-
-function WhiteSpace(bool <- c int) {
-        return c == ' ' || c == '\t' || c == '\r' || c == '\n';
-}
-
-function NextToken() {
-        var i, c int;
-        var backslash bool;
-
-        tokenbuf[0] = '\0';     // clear previous token
-        c = Get();
-        while WhiteSpace(c)  {
-                c = Get();
-        }
-        switch c {
-                case EOF:
-                        token = EOF;
-                case '(':
-                case ')':
-                        token = c;
-                        break;
-                case:
-                        for i = 0; i < 100 - 1; {  // sizeof tokenbuf - 1
-                                tokenbuf[i] = convert(char, c);
-                                i = i + 1;
-                                c = Get();
-                                if c == EOF {
-                                        break;
-                                }
-                                if WhiteSpace(c) || c == ')' {
-                                        peekc = c;
-                                        break;
-                                }
-                        }
-                        if i >= 100 - 1 {  // sizeof tokenbuf - 1
-                                panic "atom too long\n";
-                        }
-                        tokenbuf[i] = '\0';
-                        if '0' <= tokenbuf[0] && tokenbuf[0] <= '9' {
-                                token = '0';
-                        } else {
-                                token = 'A';
-                        }
-        }
-}
-
-function Expect(<- c int) {
-        if token != c {
-                print "parse error: expected ", c, "\n";
-                panic "parse";
-        }
-        NextToken();
-}
-
-// Parse a non-parenthesized list up to a closing paren or EOF
-function ParseList(*Slist <-) {
-        var slist, retval *Slist;
-
-        slist = new(Slist);
-        slist.list.car = nil;
-        slist.list.cdr = nil;
-        slist.isatom = false;
-        slist.isstring = false;
-
-        retval = slist;
-        for ;; {
-                slist.list.car = Parse();
-                if token == ')' {       // empty cdr
-                        break;
-                }
-                if token == EOF {       // empty cdr  BUG SHOULD USE ||
-                        break;
-                }
-                slist.list.cdr = new(Slist);
-                slist = slist.list.cdr;
-        }
-        return retval;
-}
-
-function atom(*Slist <- i int) {  // BUG: uses tokenbuf; should take argument
-        var h, length int;
-        var slist, tail *Slist;
-        
-        slist = new(Slist);
-        if token == '0' {
-                slist.atom.integer = i;
-                slist.isstring = false;
-        } else {
-                slist.atom.string = new([100]char);
-                var i int;
-                for i = 0; ; i = i + 1 {
-                        (*slist.atom.string)[i] = tokenbuf[i];
-                        if tokenbuf[i] == '\0' {
-                                break;
-                        }
-                }
-                //slist.atom.string = "hello"; // BUG! s; //= strdup(s);
-                slist.isstring = true;
-        }
-        slist.isatom = true;
-        return slist;
-}
-
-function atoi(int <-) {  // BUG: uses tokenbuf; should take argument
-        var v int = 0;
-        for i := 0; '0' <= tokenbuf[i] && tokenbuf[i] <= '9'; i = i + 1 {
-                v = 10 * v + convert(int, tokenbuf[i] - '0');
-        }
-        return v;
-}
-
-function Parse(*Slist <-) {
-        var slist *Slist;
-        
-        if token == EOF || token == ')' {
-                return nil;
-        }
-        if token == '(' {
-                NextToken();
-                slist = ParseList();
-                Expect(')');
-                return slist;
-        } else {
-                // Atom
-                switch token {
-                        case EOF:
-                                return nil;
-                        case '0':
-                                slist = atom(atoi());
-                        case '"':
-                        case 'A':
-                                slist = atom(0);
-                        case:
-                                slist = nil;
-                                print "unknown token"; //, token, tokenbuf;
-                }
-                NextToken();
-                return slist;
-        }
-        return nil;
-}
-
-function OpenFile() {
-        //strcpy(input, TESTSTRING);
-        //inputindex = 0;
-        // (defn foo (add 12 34))\n
-        inputindex = 0;
-        peekc = -1;  // BUG
-        EOF = -1;  // BUG
-        i := 0;
-        input[i] = '('; i = i + 1;
-        input[i] = 'd'; i = i + 1;
-        input[i] = 'e'; i = i + 1;
-        input[i] = 'f'; i = i + 1;
-        input[i] = 'n'; i = i + 1;
-        input[i] = ' '; i = i + 1;
-        input[i] = 'f'; i = i + 1;
-        input[i] = 'o'; i = i + 1;
-        input[i] = 'o'; i = i + 1;
-        input[i] = ' '; i = i + 1;
-        input[i] = '('; i = i + 1;
-        input[i] = 'a'; i = i + 1;
-        input[i] = 'd'; i = i + 1;
-        input[i] = 'd'; i = i + 1;
-        input[i] = ' '; i = i + 1;
-        input[i] = '1'; i = i + 1;
-        input[i] = '2'; i = i + 1;
-        input[i] = ' '; i = i + 1;
-        input[i] = '3'; i = i + 1;
-        input[i] = '4'; i = i + 1;
-        input[i] = ')'; i = i + 1;
-        input[i] = ')'; i = i + 1;
-        input[i] = '\n'; i = i + 1;
-        NextToken();
-}
diff --git a/_content/fosdem14.article b/_content/fosdem14.article
deleted file mode 100644
index 22daed7..0000000
--- a/_content/fosdem14.article
+++ /dev/null
@@ -1,73 +0,0 @@
-# Go talks at FOSDEM 2014
-24 Feb 2014
-Tags: fosdem, youtube, talk
-Summary: Reporting from the Go Devroom at FOSDEM 2014.
-
-Andrew Gerrand
-
-## Introduction
-
-At [FOSDEM](http://fosdem.org/) on the 2nd of February 2014 members of the Go
-community presented a series of talks in the Go Devroom. The day was a huge
-success, with 13 great talks presented to a consistently jam-packed room.
-
-Video recordings of the talks are now available, and a selection of these
-videos are presented below.
-
-The complete series of talks is available
-[as a YouTube playlist](http://www.youtube.com/playlist?list=PLtLJO5JKE5YDKG4WcaNts3IVZqhDmmuBH).
-(You can also get them directly at the
-[FOSDEM video archive](http://video.fosdem.org/2014/K4601/Sunday/).)
-
-## Scaling with Go: YouTube's Vitess
-
-Google Engineer Sugu Sougoumarane described how he and his
-team built [Vitess](https://github.com/youtube/vitess) in Go to help scale
-[YouTube](https://youtube.com).
-
-Vitess is a set of servers and tools primarily developed in Go.
-It helps scale MySQL databases for the web, and is currently used as a
-fundamental component of YouTube's MySQL infrastructure.
-
-The talk covers some history about how and why the team chose Go, and how it
-paid off.
-Sugu also talks abou tips and techniques used to scale Vitess using Go.
-
-.iframe //www.youtube.com/embed/qATTTSg6zXk 310 550
-
-The slides for the talk are [available here](https://github.com/youtube/vitess/blob/master/doc/Vitess2014.pdf?raw=true).
-
-## Camlistore
-
-[Camlistore](http://camlistore.org/) is designed to be "your personal storage
-system for life, putting you in control, and designed to last." It's open
-source, under nearly 4 years of active development, and extremely flexible.  In
-this talk, Brad Fitzpatrick and Mathieu Lonjaret explain why they built it,
-what it does, and talk about its design.
-
-.iframe //www.youtube.com/embed/yvjeIZgykiA 310 550
-
-## Write your own Go compiler
-
-Elliot Stoneham explains the potential for Go as a portable language and
-reviews the Go tools that make that such an exciting possibility.
-
-He said: "Based on my experiences writing an experimental Go to Haxe
-translator, I'll talk about the practical issues of code generation and runtime
-emulation required. I'll compare some of my design decisions with those of two
-other Go compiler/translators that build on the go.tools library. My aim is to
-encourage you to try one of these new 'mutant' Go compilers. I hope some of you
-will be inspired to contribute to one of them or even to write a new one of
-your own."
-
-.iframe //www.youtube.com/embed/Qe8Dq7V3hXY 310 550
-
-## More
-
-There were many more great talks, so please check out the complete series
-[as a YouTube playlist](http://www.youtube.com/playlist?list=PLtLJO5JKE5YDKG4WcaNts3IVZqhDmmuBH).
-In particular, the [lightning talks](http://www.youtube.com/watch?v=cwpI5ONWGxc&list=PLtLJO5JKE5YDKG4WcaNts3IVZqhDmmuBH&index=7) were a lot of fun.
-
-I would like to give my personal thanks to the excellent speakers, Mathieu
-Lonjaret for managing the video gear, and to the FOSDEM staff for making all
-this possible.
diff --git a/_content/functions-codewalk.article b/_content/functions-codewalk.article
deleted file mode 100644
index 1ae0b84..0000000
--- a/_content/functions-codewalk.article
+++ /dev/null
@@ -1,19 +0,0 @@
-# First Class Functions in Go
-30 Jun 2011
-Tags: codewalk, function, technical
-Summary: Announcing a new Go codewalk, exploring first class functions.
-OldURL: /first-class-functions-in-go-and-new-go
-
-Andrew Gerrand
-
-##
-
-Programmers new to Go are often surprised by its support for function types,
-functions as values, and closures.
-The [First Class Functions in Go](https://golang.org/doc/codewalk/functions/)
-code walk demonstrates these features with a simulation of the dice game
-[Pig](http://en.wikipedia.org/wiki/Pig_(dice)).
-It is a pretty program that uses the language to great effect,
-and a fun read for Go beginners and veterans alike.
-
-More resources are available at [golang.org](https://golang.org/doc/docs.html).
diff --git a/_content/gccgo-in-gcc-471.article b/_content/gccgo-in-gcc-471.article
deleted file mode 100644
index 1e2e4f2..0000000
--- a/_content/gccgo-in-gcc-471.article
+++ /dev/null
@@ -1,70 +0,0 @@
-# Gccgo in GCC 4.7.1
-11 Jul 2012
-Tags: release
-Summary: GCC 4.7.1 adds support for Go 1.
-
-Ian Lance Taylor
-
-##
-
-The Go language has always been defined by a [spec](https://golang.org/ref/spec),
-not an implementation.
-The Go team has written two different compilers that implement that spec: gc and gccgo.
-Having two different implementations helps ensure that the spec is complete and correct:
-when the compilers disagree, we fix the spec,
-and change one or both compilers accordingly.
-Gc is the original compiler, and the go tool uses it by default.
-Gccgo is a different implementation with a different focus,
-and in this post we’ll take a closer look at it.
-
-Gccgo is distributed as part of GCC, the GNU Compiler Collection.
-GCC supports several different frontends for different languages;
-gccgo is a Go frontend connected to the GCC backend.
-The Go frontend is separate from the GCC project and is designed to be able
-to connect to other compiler backends,
-but currently only supports GCC.
-
-Compared to gc, gccgo is slower to compile code but supports more powerful optimizations,
-so a CPU-bound program built by gccgo will usually run faster.
-All the optimizations implemented in GCC over the years are available,
-including inlining, loop optimizations, vectorization,
-instruction scheduling, and more.
-While it does not always produce better code,
-in some cases programs compiled with gccgo can run 30% faster.
-
-The gc compiler supports only the most popular processors:
-x86 (32-bit and 64-bit) and ARM.
-Gccgo, however, supports all the processors that GCC supports.
-Not all those processors have been thoroughly tested for gccgo,
-but many have, including x86 (32-bit and 64-bit),
-SPARC, MIPS, PowerPC and even Alpha.
-Gccgo has also been tested on operating systems that the gc compiler does
-not support, notably Solaris.
-
-Gccgo provides the standard, complete Go library.
-Many of the core features of the Go runtime are the same in both gccgo and gc,
-including the goroutine scheduler, channels,
-the memory allocator, and the garbage collector.
-Gccgo supports splitting goroutine stacks as the gc compiler does,
-but currently only on x86 (32-bit or 64-bit) and only when using the gold
-linker (on other processors,
-each goroutine will have a large stack, and a deep series of function calls
-may run past the end of the stack and crash the program).
-
-Gccgo distributions do not yet include a version of the go command.
-However, if you install the go command from a standard Go release,
-it already supports gccgo via the `-compiler` option:
-go build `-compiler gccgo myprog`.
-The tools used for calls between Go and C/C++,
-cgo and SWIG, also support gccgo.
-
-We have put the Go frontend under the same BSD license as the rest of the Go
-tools.  You can download the source code for the frontend at the
-[gofrontend project](https://github.com/golang/gofrontend).
-Note that when the Go frontend is linked with the GCC backend to make gccgo,
-GCC’s GPL license takes precedence.
-
-The latest release of GCC, 4.7.1, includes gccgo with support for Go 1.
-If you need better performance for CPU-bound Go programs,
-or you need to support processors or operating systems that the gc compiler does not support,
-gccgo might be the answer.
diff --git a/_content/generate.article b/_content/generate.article
deleted file mode 100644
index 87c42b0..0000000
--- a/_content/generate.article
+++ /dev/null
@@ -1,225 +0,0 @@
-# Generating code
-22 Dec 2014
-Tags: programming, technical
-Summary: How to use go generate.
-
-Rob Pike
-
-##
-
-A property of universal computation—Turing completeness—is that a computer program can write a computer program.
-This is a powerful idea that is not appreciated as often as it might be, even though it happens frequently.
-It's a big part of the definition of a compiler, for instance.
-It's also how the `go` `test` command works: it scans the packages to be tested,
-writes out a Go program containing a test harness customized for the package,
-and then compiles and runs it.
-Modern computers are so fast this expensive-sounding sequence can complete in a fraction of a second.
-
-There are lots of other examples of programs that write programs.
-[Yacc](https://godoc.org/golang.org/x/tools/cmd/goyacc), for instance, reads in a description of a grammar and writes out a program to parse that grammar.
-The protocol buffer "compiler" reads an interface description and emits structure definitions,
-methods, and other support code.
-Configuration tools of all sorts work like this too, examining metadata or the environment
-and emitting scaffolding customized to the local state.
-
-Programs that write programs are therefore important elements in software engineering,
-but programs like Yacc that produce source code need to be integrated into the build
-process so their output can be compiled.
-When an external build tool like Make is being used, this is usually easy to do.
-But in Go, whose go tool gets all necessary build information from the Go source, there is a problem.
-There is simply no mechanism to run Yacc from the go tool alone.
-
-Until now, that is.
-
-The [latest Go release](https://blog.golang.org/go1.4), 1.4,
-includes a new command that makes it easier to run such tools.
-It's called `go` `generate`, and it works by scanning for special comments in Go source code
-that identify general commands to run.
-It's important to understand that `go` `generate` is not part of `go` `build`.
-It contains no dependency analysis and must be run explicitly before running `go` `build`.
-It is intended to be used by the author of the Go package, not its clients.
-
-The `go` `generate` command is easy to use.
-As a warmup, here's how to use it to generate a Yacc grammar.
-
-First, install Go's Yacc tool:
-
-	go get golang.org/x/tools/cmd/goyacc
-
-Say you have a Yacc input file called `gopher.y` that defines a grammar for your new language.
-To produce the Go source file implementing the grammar,
-you would normally invoke the command like this:
-
-	goyacc -o gopher.go -p parser gopher.y
-
-The `-o` option names the output file while `-p` specifies the package name.
-
-To have `go` `generate` drive the process, in any one of the regular (non-generated) `.go` files
-in the same directory, add this comment anywhere in the file:
-
-	//go:generate goyacc -o gopher.go -p parser gopher.y
-
-This text is just the command above prefixed by a special comment recognized by `go` `generate`.
-The comment must start at the beginning of the line and have no spaces between the `//` and the `go:generate`.
-After that marker, the rest of the line specifies a command for `go` `generate` to run.
-
-Now run it. Change to the source directory and run `go` `generate`, then `go` `build` and so on:
-
-	$ cd $GOPATH/myrepo/gopher
-	$ go generate
-	$ go build
-	$ go test
-
-That's it.
-Assuming there are no errors, the `go` `generate` command will invoke `yacc` to create `gopher.go`,
-at which point the directory holds the full set of Go source files, so we can build, test, and work normally.
-Every time `gopher.y` is modified, just rerun `go` `generate` to regenerate the parser.
-
-For more details about how `go` `generate` works, including options, environment variables,
-and so on, see the [design document](https://golang.org/s/go1.4-generate).
-
-Go generate does nothing that couldn't be done with Make or some other build mechanism,
-but it comes with the `go` tool—no extra installation required—and fits nicely into the Go ecosystem.
-Just keep in mind that it is for package authors, not clients,
-if only for the reason that the program it invokes might not be available on the target machine.
-Also, if the containing package is intended for import by `go` `get`,
-once the file is generated (and tested!) it must be checked into the
-source code repository to be available to clients.
-
-Now that we have it, let's use it for something new.
-As a very different example of how `go` `generate` can help, there is a new program available in the
-`golang.org/x/tools` repository called `stringer`.
-It automatically writes string methods for sets of integer constants.
-It's not part of the released distribution, but it's easy to install:
-
-	$ go get golang.org/x/tools/cmd/stringer
-
-Here's an example from the documentation for
-[`stringer`](https://godoc.org/golang.org/x/tools/cmd/stringer).
-Imagine we have some code that contains a set of integer constants defining different types of pills:
-
-	package painkiller
-
-	type Pill int
-
-	const (
-		Placebo Pill = iota
-		Aspirin
-		Ibuprofen
-		Paracetamol
-		Acetaminophen = Paracetamol
-	)
-
-For debugging, we'd like these constants to pretty-print themselves, which means we want a method with signature,
-
-	func (p Pill) String() string
-
-It's easy to write one by hand, perhaps like this:
-
-	func (p Pill) String() string {
-		switch p {
-		case Placebo:
-			return "Placebo"
-		case Aspirin:
-			return "Aspirin"
-		case Ibuprofen:
-			return "Ibuprofen"
-		case Paracetamol: // == Acetaminophen
-			return "Paracetamol"
-		}
-		return fmt.Sprintf("Pill(%d)", p)
-	}
-
-There are other ways to write this function, of course.
-We could use a slice of strings indexed by Pill, or a map, or some other technique.
-Whatever we do, we need to maintain it if we change the set of pills, and we need to make sure it's correct.
-(The two names for paracetamol make this trickier than it might otherwise be.)
-Plus the very question of which approach to take depends on the types and values:
-signed or unsigned, dense or sparse, zero-based or not, and so on.
-
-The `stringer` program takes care of all these details.
-Although it can be run in isolation, it is intended to be driven by `go` `generate`.
-To use it, add a generate comment to the source, perhaps near the type definition:
-
-	//go:generate stringer -type=Pill
-
-This rule specifies that `go` `generate` should run the `stringer` tool to generate a `String` method for type `Pill`.
-The output is automatically written to `pill_string.go` (a default we could override with the
-`-output` flag).
-
-Let's run it:
-
-	$ go generate
-	$ cat pill_string.go
-	// Code generated by stringer -type Pill pill.go; DO NOT EDIT.
-
-	package painkiller
-
-	import "fmt"
-
-	const _Pill_name = "PlaceboAspirinIbuprofenParacetamol"
-
-	var _Pill_index = [...]uint8{0, 7, 14, 23, 34}
-
-	func (i Pill) String() string {
-		if i < 0 || i+1 >= Pill(len(_Pill_index)) {
-			return fmt.Sprintf("Pill(%d)", i)
-		}
-		return _Pill_name[_Pill_index[i]:_Pill_index[i+1]]
-	}
-	$
-
-Every time we change the definition of `Pill` or the constants, all we need to do is run
-
-	$ go generate
-
-to update the `String` method.
-And of course if we've got multiple types set up this way in the same package,
-that single command will update all their `String` methods with a single command.
-
-There's no question the generated method is ugly.
-That's OK, though, because humans don't need to work on it; machine-generated code is often ugly.
-It's working hard to be efficient.
-All the names are smashed together into a single string,
-which saves memory (only one string header for all the names, even if there are zillions of them).
-Then an array, `_Pill_index`, maps from value to name by a simple, efficient technique.
-Note too that `_Pill_index` is an array (not a slice; one more header eliminated) of `uint8`,
-the smallest integer sufficient to span the space of values.
-If there were more values, or there were negatives ones,
-the generated type of `_Pill_index` might change to `uint16` or `int8`: whatever works best.
-
-The approach used by the methods printed by `stringer` varies according to the properties of the constant set.
-For instance, if the constants are sparse, it might use a map.
-Here's a trivial example based on a constant set representing powers of two:
-
-	const _Power_name = "p0p1p2p3p4p5..."
-
-	var _Power_map = map[Power]string{
-		1:    _Power_name[0:2],
-		2:    _Power_name[2:4],
-		4:    _Power_name[4:6],
-		8:    _Power_name[6:8],
-		16:   _Power_name[8:10],
-		32:   _Power_name[10:12],
-		...,
-	}
-
-	func (i Power) String() string {
-		if str, ok := _Power_map[i]; ok {
-			return str
-		}
-		return fmt.Sprintf("Power(%d)", i)
-	}
-
-In short, generating the method automatically allows us to do a better job than we would expect a human to do.
-
-There are lots of other uses of `go` `generate` already installed in the Go tree.
-Examples include generating Unicode tables in the `unicode` package,
-creating efficient methods for encoding and decoding arrays in `encoding/gob`,
-producing time zone data in the `time` package, and so on.
-
-Please use `go` `generate` creatively.
-It's there to encourage experimentation.
-
-And even if you don't, use the new `stringer` tool to write your `String` methods for your integer constants.
-Let the machine do the work.
diff --git a/_content/generics-next-step.article b/_content/generics-next-step.article
deleted file mode 100644
index 72014d3..0000000
--- a/_content/generics-next-step.article
+++ /dev/null
@@ -1,142 +0,0 @@
-# The Next Step for Generics
-16 Jun 2020
-Tags: go2, proposals, generics
-Summary: An updated generics design draft, and a translation tool for experimentation
-
-Ian Lance Taylor
-
-Robert Griesemer
-
-## Introduction
-
-It’s been almost a year since we [last wrote about the possibility of
-adding generics to Go](https://blog.golang.org/why-generics).
-It’s time for an update.
-
-## Updated design
-
-We’ve been continuing to refine the [generics design
-draft](https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-contracts.md).
-We’ve written a type checker for it: a program that can parse Go code
-that uses generics as described in the design draft and report any
-type errors.
-We’ve written example code.
-And we’ve collected feedback from many, many people&mdash;thanks for
-providing it!
-
-Based on what we’ve learned, we’re releasing an [updated design
-draft](https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md).
-The biggest change is that we are dropping the idea of contracts.
-The difference between contracts and interface types was confusing, so
-we’re eliminating that difference.
-Type parameters are now constrained by interface types.
-Interface types are now permitted to include type lists, though only
-when used as constraints; in the previous design draft type lists were
-a feature of contracts.
-More complex cases will use a parameterized interface type.
-
-We hope that people will find this design draft simpler and easier to
-understand.
-
-## Experimentation tool
-
-To help decide how to further refine the design draft, we are
-releasing a translation tool.
-This is a tool that permits people to type check and run code written
-using the version of generics described in the design draft.
-It works by translating generic code into ordinary Go code.
-This translation process imposes some limitations, but we hope that it
-will be good enough for people to get a feel for what generic Go code
-might look like.
-The real implementation of generics, if they are accepted into the
-language, will work differently.
-(We have only just begun to sketch out what a direct compiler
-implementation would look like.)
-
-The tool is available on a variant of the Go playground at
-[https://go2goplay.golang.org](https://go2goplay.golang.org).
-This playground works just like the usual Go playground, but it
-supports generic code.
-
-You can also build and use the tool yourself.
-It is available in a branch of the master Go repo.
-Follow the [instructions on installing Go from
-source](https://golang.org/doc/install/source).
-Where those instructions direct you to check out the latest release
-tag, instead run `git checkout dev.go2go`.
-Then build the Go toolchain as directed.
-
-The translation tool is documented in
-[README.go2go](https://go.googlesource.com/go/+/refs/heads/dev.go2go/README.go2go.md).
-
-## Next steps
-
-We hope that the tool will give the Go community a chance to
-experiment with generics.
-There are two main things that we hope to learn.
-
-First, does generic code make sense?
-Does it feel like Go?
-What surprises do people encounter?
-Are the error messages useful?
-
-Second, we know that many people have said that Go needs generics, but
-we don’t necessarily know exactly what that means.
-Does this draft design address the problem in a useful way?
-If there is a problem that makes you think “I could solve this if Go
-had generics,” can you solve the problem when using this tool?
-
-We will use the feedback we gather from the Go community to decide how
-to move forward.
-If the draft design is well received and doesn’t need significant
-changes, the next step would be a [formal language change
-proposal](https://golang.org/s/proposal).
-To set expectations, if everybody is completely happy with the design
-draft and it does not require any further adjustments, the earliest
-that generics could be added to Go would be the Go 1.17 release,
-scheduled for August 2021.
-In reality, of course, there may be unforeseen problems, so this is an
-optimistic timeline; we can’t make any definite prediction.
-
-## Feedback
-
-The best way to provide feedback for the language changes will be on
-the mailing list `golang-nuts@googlegroups.com`.
-Mailing lists are imperfect, but they seem like our best option for
-initial discussion.
-When writing about the design draft, please put `[generics]` at the
-start of the Subject line and to start different threads for different
-specific topics.
-
-If you find bugs in the generics type checker or the translation tool,
-they should be filed in the standard Go issue tracker at
-[https://golang.org/issue](https://golang.org/issue).
-Please start the issue title with `cmd/go2go:`.
-Note that the issue tracker is not the best place to discuss changes
-to the language, because it does not provide threading and it is not
-well suited to lengthy conversations.
-
-We look forward to your feedback.
-
-## Acknowledgements
-
-We’re not finished, but we’ve come a long way.
-We would not be here without a lot of help.
-
-We’d like to thank Philip Wadler and his collaborators for thinking
-formally about generics in Go and helping us clarify the theoretical
-aspects of the design.
-Their paper [Featherweight Go](https://arxiv.org/abs/2005.11710)
-analyzes generics in a restricted version of Go, and they have
-developed a prototype [on GitHub](https://github.com/rhu1/fgg).
-
-We would also like to thank [the
-people](https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#acknowledgements)
-who provided detailed feedback on an earlier version of the design
-draft.
-
-And last but definitely not least, we’d like to thank many people on
-the Go team, many contributors to the Go issue tracker, and everybody
-else who shared ideas and feedback on earlier design drafts.
-We read all of it, and we’re grateful.  We wouldn’t be here without
-you.
diff --git a/_content/generics-proposal.article b/_content/generics-proposal.article
deleted file mode 100644
index 0f83878..0000000
--- a/_content/generics-proposal.article
+++ /dev/null
@@ -1,79 +0,0 @@
-# A Proposal for Adding Generics to Go
-12 Jan 2021
-Tags: go2, proposals, generics
-Summary: Generics is entering the language change proposal process
-
-Ian Lance Taylor
-
-## Generics proposal
-
-We’ve filed [a Go language change
-proposal](https://golang.org/issue/43651) to add support for type
-parameters for types and functions, permitting a form of generic
-programming.
-
-## Why generics?
-
-Generics can give us powerful building blocks that let us share code
-and build programs more easily.
-Generic programming means writing functions and data structures where
-some types are left to be specified later.
-For example, you can write a function that operates on a slice of some
-arbitrary data type, where the actual data type is only specified when
-the function is called.
-Or, you can define a data structure that stores values of any type,
-where the actual type to be stored is specified when you create an
-instance of the data structure.
-
-Since Go was first released in 2009, support for generics has been one
-of the most commonly requested language features.
-You can read more about why generics are useful in 
-[an earlier blog post](https://blog.golang.org/why-generics).
-
-Although generics have clear use cases, fitting them cleanly into a
-language like Go is a difficult task.
-One of the [first (flawed) attempts to add generics to
-Go](https://golang.org/design/15292/2010-06-type-functions) dates back
-all the way to 2010.
-There have been several others over the last decade.
-
-For the last couple of years we’ve been working on a series of design
-drafts that have culminated in [a design based on type
-parameters](https://golang.org/design/go2draft-type-parameters).
-This design draft has had a lot of input from the Go programming
-community, and many people have experimented with it using the
-[generics playground](https://go2goplay.golang.org) described in [an
-earlier blog post](https://blog.golang.org/generics-next-step).
-Ian Lance Taylor gave [a talk at GopherCon
-2019](https://www.youtube.com/watch?v=WzgLqE-3IhY)
-about why to add generics and the strategy we are now following.
-Robert Griesemer gave [a follow-up talk about changes in the design,
-and the implementation, at GopherCon
-2020](https://www.youtube.com/watch?v=TborQFPY2IM).
-The language changes are fully backward compatible, so existing Go
-programs will continue to work exactly as they do today.
-We have reached the point where we think that the design draft is good
-enough, and simple enough, to propose adding it to Go.
-
-## What happens now?
-
-The [language change proposal process](https://golang.org/s/proposal)
-is how we make changes to the Go language.
-We have now [started this process](https://golang.org/issue/43651)
-to add generics to a future version of Go.
-We invite substantive criticisms and comments, but please try to avoid
-repeating earlier comments, and please try to [avoid simple plus-one
-and minus-one comments](https://golang.org/wiki/NoPlusOne).
-Instead, add thumbs-up/thumbs-down emoji reactions to comments with
-which you agree or disagree, or to the proposal as a whole.
-
-As with all language change proposals, our goal is to drive toward a
-consensus to either add generics to the language or let the proposal
-drop.
-We understand that for a change of this magnitude it will be
-impossible to make everybody in the Go community happy, but we intend
-to get to a decision that everybody is willing to accept.
-
-If the proposal is accepted, our goal will be to have a complete,
-though perhaps not fully optimized, implementation for people to try
-by the end of the year, perhaps as part of the Go 1.18 betas.
diff --git a/_content/gif-decoder.article b/_content/gif-decoder.article
deleted file mode 100644
index d848210..0000000
--- a/_content/gif-decoder.article
+++ /dev/null
@@ -1,214 +0,0 @@
-# A GIF decoder: an exercise in Go interfaces
-25 May 2011
-Tags: gif, gopher, image, interface, lagomorph, lzw, moustache, rodent, technical
-Summary: How Go's interfaces work nicely in the Go GIF decoder.
-OldURL: /gif-decoder-exercise-in-go-interfaces
-
-Rob Pike
-
-## Introduction
-
-At the Google I/O conference in San Francisco on May 10,
-2011, we announced that the Go language is now available on Google App Engine.
-Go is the first language to be made available on App Engine that compiles
-directly to machine code,
-which makes it a good choice for CPU-intensive tasks such as image manipulation.
-
-In that vein, we demonstrated a program called [Moustachio](http://moustach-io.appspot.com/)
-that makes it easy to improve a picture such as this one:
-
-.image gif-decoder/image00.jpg
-
-by adding a moustache and sharing the result:
-
-.image gif-decoder/image02.jpg
-
-All the graphical processing, including rendering the antialiased moustache,
-is done by a Go program running on App Engine.
-(The source is available at [the appengine-go project](http://code.google.com/p/appengine-go/source/browse/example/moustachio/).)
-
-Although most images on the web—at least those likely to be moustachioed—are JPEGs,
-there are countless other formats floating around,
-and it seemed reasonable for Moustachio to accept uploaded images in a few of them.
-JPEG and PNG decoders already existed in the Go image library,
-but the venerable GIF format was not represented,
-so we decided to write a GIF decoder in time for the announcement.
-That decoder contains a few pieces that demonstrate how Go's interfaces
-make some problems easier to solve.
-The rest of this blog post describes a couple of instances.
-
-## The GIF format
-
-First, a quick tour of the GIF format.  A GIF image file is _paletted_,
-that is, each pixel value is an index into a fixed color map that is included in the file.
-The GIF format dates from a time when there were usually no more than 8
-bits per pixel on the display,
-and a color map was used to convert the limited set of values into the RGB (red,
-green, blue) triples needed to light the screen.
-(This is in contrast to a JPEG, for example,
-which has no color map because the encoding represents the distinct color
-signals separately.)
-
-A GIF image can contain anywhere from 1 to 8 bits per pixel, inclusive, but 8 bits per pixel is the most common.
-
-Simplifying somewhat, a GIF file contains a header defining the pixel depth
-and image dimensions,
-a color map (256 RGB triples for an 8-bit image),
-and then the pixel data.
-The pixel data is stored as a one-dimensional bit stream,
-compressed using the LZW algorithm, which is quite effective for computer-generated
-graphics although not so good for photographic imagery.
-The compressed data is then broken into length-delimited blocks with a one-byte
-count (0-255) followed by that many bytes:
-
-.image gif-decoder/image03.gif
-
-## Deblocking the pixel data
-
-To decode GIF pixel data in Go, we can use the LZW decompressor from the
-`compress/lzw` package.
-It has a NewReader function that returns an object that,
-as [the documentation](https://golang.org/pkg/compress/lzw/#NewReader) says,
-"satisfies reads by decompressing the data read from r":
-
-	func NewReader(r io.Reader, order Order, litWidth int) io.ReadCloser
-
-Here `order` defines the bit-packing order and `litWidth` is the word size in bits,
-which for a GIF file corresponds to the pixel depth, typically 8.
-
-But we can't just give `NewReader` the input file as its first argument
-because the decompressor needs a stream of bytes but the GIF data is a stream
-of blocks that must be unpacked.
-To address this problem, we can wrap the input `io.Reader` with some code to deblock it,
-and make that code again implement `Reader`.
-In other words, we put the deblocking code into the `Read` method of a new type,
-which we call `blockReader`.
-
-Here's the data structure for a `blockReader`.
-
-	type blockReader struct {
-	   r     reader    // Input source; implements io.Reader and io.ByteReader.
-	   slice []byte    // Buffer of unread data.
-	   tmp   [256]byte // Storage for slice.
-	}
-
-The reader, `r`, will be the source of the image data,
-perhaps a file or HTTP connection.
-The `slice` and `tmp` fields will be used to manage the deblocking.
-Here's the `Read` method in its entirety.
-It's a nice example of the use of slices and arrays in Go.
-
-	1  func (b *blockReader) Read(p []byte) (int, os.Error) {
-	2      if len(p) == 0 {
-	3          return 0, nil
-	4      }
-	5      if len(b.slice) == 0 {
-	6          blockLen, err := b.r.ReadByte()
-	7          if err != nil {
-	8              return 0, err
-	9          }
-	10          if blockLen == 0 {
-	11              return 0, os.EOF
-	12          }
-	13          b.slice = b.tmp[0:blockLen]
-	14          if _, err = io.ReadFull(b.r, b.slice); err != nil {
-	15              return 0, err
-	16          }
-	17      }
-	18      n := copy(p, b.slice)
-	19      b.slice = b.slice[n:]
-	20      return n, nil
-	21  }
-
-Lines 2-4 are just a sanity check: if there's no place to put data, return zero.
-That should never happen, but it's good to be safe.
-
-Line 5 asks if there's data left over from a previous call by checking the
-length of `b.slice`.
-If there isn't, the slice will have length zero and we need to read the
-next block from `r`.
-
-A GIF block starts with a byte count, read on line 6.
-If the count is zero, GIF defines this to be a terminating block,
-so we return `EOF` on line 11.
-
-Now we know we should read `blockLen` bytes,
-so we point `b.slice` to the first `blockLen` bytes of `b.tmp` and then
-use the helper function `io.ReadFull` to read that many bytes.
-That function will return an error if it can't read exactly that many bytes,
-which should never happen.
-Otherwise we have `blockLen` bytes ready to read.
-
-Lines 18-19 copy the data from `b.slice` to the caller's buffer.
-We are implementing `Read`, not `ReadFull`,
-so we are allowed to return fewer than the requested number of bytes.
-That makes it easy: we just copy the data from `b.slice` to the caller's buffer (`p`),
-and the return value from copy is the number of bytes transferred.
-Then we reslice `b.slice` to drop the first `n` bytes,
-ready for the next call.
-
-It's a nice technique in Go programming to couple a slice (`b.slice`) to an array (`b.tmp`).
-In this case, it means `blockReader` type's `Read` method never does any allocations.
-It also means we don't need to keep a count around (it's implicit in the slice length),
-and the built-in `copy` function guarantees we never copy more than we should.
-(For more about slices, see [this post from the Go Blog](https://blog.golang.org/2011/01/go-slices-usage-and-internals.html).)
-
-Given the `blockReader` type, we can unblock the image data stream just
-by wrapping the input reader,
-say a file, like this:
-
-	deblockingReader := &blockReader{r: imageFile}
-
-This wrapping turns a block-delimited GIF image stream into a simple stream
-of bytes accessible by calls to the `Read` method of the `blockReader`.
-
-## Connecting the pieces
-
-With `blockReader` implemented and the LZW compressor available from the library,
-we have all the pieces we need to decode the image data stream.
-We stitch them together with this thunderclap,
-straight from the code:
-
-	lzwr := lzw.NewReader(&blockReader{r: d.r}, lzw.LSB, int(litWidth))
-	if _, err = io.ReadFull(lzwr, m.Pix); err != nil {
-	   break
-	}
-
-That's it.
-
-The first line creates a `blockReader` and passes it to `lzw.NewReader`
-to create a decompressor.
-Here `d.r` is the `io.Reader` holding the image data,
-`lzw.LSB` defines the byte order in the LZW decompressor,
-and `litWidth` is the pixel depth.
-
-Given the decompressor, the second line calls `io.ReadFull` to decompress
-the data and store it in the image, `m.Pix`.
-When `ReadFull` returns, the image data is decompressed and stored in the image,
-`m`, ready to be displayed.
-
-This code worked first time. Really.
-
-We could avoid the temporary variable `lzwr` by placing the `NewReader`
-call into the argument list for `ReadFull`,
-just as we built the `blockReader` inside the call to `NewReader`,
-but that might be packing too much into a single line of code.
-
-## Conclusion
-
-Go's interfaces make it easy to construct software by assembling piece parts
-like this to restructure data.
-In this example, we implemented GIF decoding by chaining together a deblocker
-and a decompressor using the `io.Reader` interface,
-analogous to a type-safe Unix pipeline.
-Also, we wrote the deblocker as an (implicit) implementation of a `Reader` interface,
-which then required no extra declaration or boilerplate to fit it into the
-processing pipeline.
-It's hard to implement this decoder so compactly yet cleanly and safely in most languages,
-but the interface mechanism plus a few conventions make it almost natural in Go.
-
-That deserves another picture, a GIF this time:
-
-.image gif-decoder/image01.gif
-
-The GIF format is defined at [http://www.w3.org/Graphics/GIF/spec-gif89a.txt](http://www.w3.org/Graphics/GIF/spec-gif89a.txt).
diff --git a/_content/gif-decoder/image00.jpg b/_content/gif-decoder/image00.jpg
deleted file mode 100644
index 7301e46..0000000
--- a/_content/gif-decoder/image00.jpg
+++ /dev/null
Binary files differ
diff --git a/_content/gif-decoder/image01.gif b/_content/gif-decoder/image01.gif
deleted file mode 100644
index 060544a..0000000
--- a/_content/gif-decoder/image01.gif
+++ /dev/null
Binary files differ
diff --git a/_content/gif-decoder/image02.jpg b/_content/gif-decoder/image02.jpg
deleted file mode 100644
index e5122df..0000000
--- a/_content/gif-decoder/image02.jpg
+++ /dev/null
Binary files differ
diff --git a/_content/gif-decoder/image03.gif b/_content/gif-decoder/image03.gif
deleted file mode 100644
index 2d6321b..0000000
--- a/_content/gif-decoder/image03.gif
+++ /dev/null
Binary files differ
diff --git a/_content/go-brand.article b/_content/go-brand.article
deleted file mode 100644
index db2f3b6..0000000
--- a/_content/go-brand.article
+++ /dev/null
@@ -1,93 +0,0 @@
-# Go's New Brand
-26 Apr 2018
-Tags: brand
-Summary: Go’s new look and logo (don't worry, the mascot isn’t changing!).
-
-Steve Francia
-
-## Introduction
-
-I am delighted to announce the launch of Go’s new look and logo.
-
-Go has been on an amazing journey over the last 8+ years. Our project, community
-and users have evolved through this journey and we wanted the Go brand to
-reflect where we have been and convey where we are going.
-
-Go’s new brand is about our identity, our values, and our users. Over the past
-several months we have worked with a brand agency to develop a brand guide for
-Go. Our agency, [Within](http://within.us/), coordinated with and built upon
-the great foundation that Renee French established. Rest easy, our beloved
-Gopher Mascot remains at the center of our brand.
-
-## New Logo
-
-Our logo follows the brand’s core philosophy of simplicity over complexity.
-Using a modern, italicized sans-serif typeface combined with three simple motion
-lines forms a mark that resembles two wheels in rapid motion, communicating
-speed and efficiency. The circular shape of the letters hints at the eyes of the
-Go gopher, creating a familiar shape and allowing the mark and the mascot to
-pair well together.
-
-.image go-brand/logos.jpg
-
-Our new logo went through an extensive design process. Here are some of the
-revisions we went through…
-
-<div><center>
-.iframe //www.youtube.com/embed/V4t-ymImW6c 315 560
-</center></div>
-
-## New Brand Guide
-
-The brand guide establishes the mission, values and voice for the Go project. In
-general terms, a brand guide is a reference tool for establishing a consistent
-brand identity. It is sometimes referred to as “brand guidelines” or a “brand
-book”. It is a single document that serves as a guide and reference to
-designers, writers, and developers to create consistent, on-brand content.
-
-.image go-brand/Go-BB_cover.jpg
-.image go-brand/Go-BB_spread1.jpg
-.image go-brand/Go-BB_spread2.jpg
-
-## New presentation themes
-
-In addition to our brand guide we have also developed a presentation theme. This
-presentation theme will enable us to have a consistent representation of Go in
-person at meetups and conferences as well as online. Go community members are
-welcome to use this theme for their own presentations.
-
-.image go-brand/go-slides-4up.jpg
-
-The presentations are available as Google Slides presentations. We chose Google
-slides as it is easy to share and maintain updates. People are welcome to port
-them to keynote, powerpoint, etc.
-
-Like this blog and all our gopher images,
-the slide themes are Creative Commons Attribution 3.0 licensed.
-The photos in the slides are all from
-[unsplash](https://unsplash.com/) and are released under the unsplash license.
-
-Instructions to use slides:
-
-  - Open the [Go Slide Masters](https://golang.org/s/presentation-theme) presentation on Google slides.
-  - File > “Make a Copy” (you may need to login first)
-  - Create new slides using the layouts provided in the layouts menu.
-  - Use the included example slides to help guide the styling and creation of your presentation.
-
-### Download
-
-The brand guide, logo and themes are copyrighted by the Go authors.
-
-The brand guide contains the guidelines for acceptable logo use.
-
-  - [Brand Book (pdf)](https://golang.org/s/brandbook)
-  - [Go Logos (zip)](https://golang.org/s/logos)
-  - [Go Slide Masters (Google Slides)](https://golang.org/s/presentation-theme)
-
-## What’s happening next
-
-The website will be getting a refresh based on the new design. Since we are
-making significant changes, we are also taking this opportunity to update our
-website infrastructure to better serve our global community with internationalization
-and multilingual support. The migration will happen in stages over the
-next few months starting with this blog.
diff --git a/_content/go-brand/Go-BB_cover.jpg b/_content/go-brand/Go-BB_cover.jpg
deleted file mode 100644
index f290c2c..0000000
--- a/_content/go-brand/Go-BB_cover.jpg
+++ /dev/null
Binary files differ
diff --git a/_content/go-brand/Go-BB_spread1.jpg b/_content/go-brand/Go-BB_spread1.jpg
deleted file mode 100644
index 2f384bf..0000000
--- a/_content/go-brand/Go-BB_spread1.jpg
+++ /dev/null
Binary files differ
diff --git a/_content/go-brand/Go-BB_spread2.jpg b/_content/go-brand/Go-BB_spread2.jpg
deleted file mode 100644
index f888404..0000000
--- a/_content/go-brand/Go-BB_spread2.jpg
+++ /dev/null
Binary files differ
diff --git a/_content/go-brand/Go-Logo/EPS/Go-Logo_Versions.eps b/_content/go-brand/Go-Logo/EPS/Go-Logo_Versions.eps
deleted file mode 100644
index 6550d36..0000000
--- a/_content/go-brand/Go-Logo/EPS/Go-Logo_Versions.eps
+++ /dev/null
Binary files differ
diff --git a/_content/go-brand/Go-Logo/Go-Logo_Versions.ai b/_content/go-brand/Go-Logo/Go-Logo_Versions.ai
deleted file mode 100644
index ec7e4ac..0000000
--- a/_content/go-brand/Go-Logo/Go-Logo_Versions.ai
+++ /dev/null
Binary files differ
diff --git a/_content/go-brand/Go-Logo/Go-Logo_Versions.pdf b/_content/go-brand/Go-Logo/Go-Logo_Versions.pdf
deleted file mode 100644
index 1cd98e4..0000000
--- a/_content/go-brand/Go-Logo/Go-Logo_Versions.pdf
+++ /dev/null
Binary files differ
diff --git a/_content/go-brand/Go-Logo/JPG/Go-Logo_Aqua.jpg b/_content/go-brand/Go-Logo/JPG/Go-Logo_Aqua.jpg
deleted file mode 100644
index 9c2a71b..0000000
--- a/_content/go-brand/Go-Logo/JPG/Go-Logo_Aqua.jpg
+++ /dev/null
Binary files differ
diff --git a/_content/go-brand/Go-Logo/JPG/Go-Logo_Black.jpg b/_content/go-brand/Go-Logo/JPG/Go-Logo_Black.jpg
deleted file mode 100644
index f9bb6a6..0000000
--- a/_content/go-brand/Go-Logo/JPG/Go-Logo_Black.jpg
+++ /dev/null
Binary files differ
diff --git a/_content/go-brand/Go-Logo/JPG/Go-Logo_Blue.jpg b/_content/go-brand/Go-Logo/JPG/Go-Logo_Blue.jpg
deleted file mode 100644
index 05741fe..0000000
--- a/_content/go-brand/Go-Logo/JPG/Go-Logo_Blue.jpg
+++ /dev/null
Binary files differ
diff --git a/_content/go-brand/Go-Logo/JPG/Go-Logo_Fuchsia.jpg b/_content/go-brand/Go-Logo/JPG/Go-Logo_Fuchsia.jpg
deleted file mode 100644
index 42e55ab..0000000
--- a/_content/go-brand/Go-Logo/JPG/Go-Logo_Fuchsia.jpg
+++ /dev/null
Binary files differ
diff --git a/_content/go-brand/Go-Logo/JPG/Go-Logo_LightBlue.jpg b/_content/go-brand/Go-Logo/JPG/Go-Logo_LightBlue.jpg
deleted file mode 100644
index 566f403..0000000
--- a/_content/go-brand/Go-Logo/JPG/Go-Logo_LightBlue.jpg
+++ /dev/null
Binary files differ
diff --git a/_content/go-brand/Go-Logo/JPG/Go-Logo_Yellow.jpg b/_content/go-brand/Go-Logo/JPG/Go-Logo_Yellow.jpg
deleted file mode 100644
index 8b9223c..0000000
--- a/_content/go-brand/Go-Logo/JPG/Go-Logo_Yellow.jpg
+++ /dev/null
Binary files differ
diff --git a/_content/go-brand/Go-Logo/PNG/Go-Logo_Aqua.png b/_content/go-brand/Go-Logo/PNG/Go-Logo_Aqua.png
deleted file mode 100644
index 7af7746..0000000
--- a/_content/go-brand/Go-Logo/PNG/Go-Logo_Aqua.png
+++ /dev/null
Binary files differ
diff --git a/_content/go-brand/Go-Logo/PNG/Go-Logo_Black.png b/_content/go-brand/Go-Logo/PNG/Go-Logo_Black.png
deleted file mode 100644
index f68a065..0000000
--- a/_content/go-brand/Go-Logo/PNG/Go-Logo_Black.png
+++ /dev/null
Binary files differ
diff --git a/_content/go-brand/Go-Logo/PNG/Go-Logo_Blue.png b/_content/go-brand/Go-Logo/PNG/Go-Logo_Blue.png
deleted file mode 100644
index d6d98c3..0000000
--- a/_content/go-brand/Go-Logo/PNG/Go-Logo_Blue.png
+++ /dev/null
Binary files differ
diff --git a/_content/go-brand/Go-Logo/PNG/Go-Logo_Fuchsia.png b/_content/go-brand/Go-Logo/PNG/Go-Logo_Fuchsia.png
deleted file mode 100644
index 2f5cddd..0000000
--- a/_content/go-brand/Go-Logo/PNG/Go-Logo_Fuchsia.png
+++ /dev/null
Binary files differ
diff --git a/_content/go-brand/Go-Logo/PNG/Go-Logo_LightBlue.png b/_content/go-brand/Go-Logo/PNG/Go-Logo_LightBlue.png
deleted file mode 100644
index fcc24ed..0000000
--- a/_content/go-brand/Go-Logo/PNG/Go-Logo_LightBlue.png
+++ /dev/null
Binary files differ
diff --git a/_content/go-brand/Go-Logo/PNG/Go-Logo_White.png b/_content/go-brand/Go-Logo/PNG/Go-Logo_White.png
deleted file mode 100644
index 26d2288..0000000
--- a/_content/go-brand/Go-Logo/PNG/Go-Logo_White.png
+++ /dev/null
Binary files differ
diff --git a/_content/go-brand/Go-Logo/PNG/Go-Logo_Yellow.png b/_content/go-brand/Go-Logo/PNG/Go-Logo_Yellow.png
deleted file mode 100644
index 2fccc34..0000000
--- a/_content/go-brand/Go-Logo/PNG/Go-Logo_Yellow.png
+++ /dev/null
Binary files differ
diff --git a/_content/go-brand/Go-Logo/SVG/Go-Logo_Aqua.svg b/_content/go-brand/Go-Logo/SVG/Go-Logo_Aqua.svg
deleted file mode 100644
index bccf226..0000000
--- a/_content/go-brand/Go-Logo/SVG/Go-Logo_Aqua.svg
+++ /dev/null
@@ -1,60 +0,0 @@
-<?xml version="1.0" encoding="utf-8"?>
-<!-- Generator: Adobe Illustrator 22.1.0, SVG Export Plug-In . SVG Version: 6.00 Build 0)  -->
-<svg version="1.1" id="Layer_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px"
-	 viewBox="0 0 254.5 225" style="enable-background:new 0 0 254.5 225;" xml:space="preserve">
-<style type="text/css">
-	.st0{fill:#2DBCAF;}
-	.st1{fill:#5DC9E1;}
-	.st2{fill:#FDDD00;}
-	.st3{fill:#CE3262;}
-	.st4{fill:#00ACD7;}
-	.st5{fill:#FFFFFF;}
-</style>
-<g>
-	<g>
-		<g>
-			<g>
-				<path class="st0" d="M40.2,101.1c-0.4,0-0.5-0.2-0.3-0.5l2.1-2.7c0.2-0.3,0.7-0.5,1.1-0.5l35.7,0c0.4,0,0.5,0.3,0.3,0.6
-					l-1.7,2.6c-0.2,0.3-0.7,0.6-1,0.6L40.2,101.1z"/>
-			</g>
-		</g>
-	</g>
-	<g>
-		<g>
-			<g>
-				<path class="st0" d="M25.1,110.3c-0.4,0-0.5-0.2-0.3-0.5l2.1-2.7c0.2-0.3,0.7-0.5,1.1-0.5l45.6,0c0.4,0,0.6,0.3,0.5,0.6
-					l-0.8,2.4c-0.1,0.4-0.5,0.6-0.9,0.6L25.1,110.3z"/>
-			</g>
-		</g>
-	</g>
-	<g>
-		<g>
-			<g>
-				<path class="st0" d="M49.3,119.5c-0.4,0-0.5-0.3-0.3-0.6l1.4-2.5c0.2-0.3,0.6-0.6,1-0.6l20,0c0.4,0,0.6,0.3,0.6,0.7l-0.2,2.4
-					c0,0.4-0.4,0.7-0.7,0.7L49.3,119.5z"/>
-			</g>
-		</g>
-	</g>
-	<g>
-		<g id="CXHf1q_1_">
-			<g>
-				<g>
-					<path class="st0" d="M153.1,99.3c-6.3,1.6-10.6,2.8-16.8,4.4c-1.5,0.4-1.6,0.5-2.9-1c-1.5-1.7-2.6-2.8-4.7-3.8
-						c-6.3-3.1-12.4-2.2-18.1,1.5c-6.8,4.4-10.3,10.9-10.2,19c0.1,8,5.6,14.6,13.5,15.7c6.8,0.9,12.5-1.5,17-6.6
-						c0.9-1.1,1.7-2.3,2.7-3.7c-3.6,0-8.1,0-19.3,0c-2.1,0-2.6-1.3-1.9-3c1.3-3.1,3.7-8.3,5.1-10.9c0.3-0.6,1-1.6,2.5-1.6
-						c5.1,0,23.9,0,36.4,0c-0.2,2.7-0.2,5.4-0.6,8.1c-1.1,7.2-3.8,13.8-8.2,19.6c-7.2,9.5-16.6,15.4-28.5,17
-						c-9.8,1.3-18.9-0.6-26.9-6.6c-7.4-5.6-11.6-13-12.7-22.2c-1.3-10.9,1.9-20.7,8.5-29.3c7.1-9.3,16.5-15.2,28-17.3
-						c9.4-1.7,18.4-0.6,26.5,4.9c5.3,3.5,9.1,8.3,11.6,14.1C154.7,98.5,154.3,99,153.1,99.3z"/>
-				</g>
-				<g>
-					<path class="st0" d="M186.2,154.6c-9.1-0.2-17.4-2.8-24.4-8.8c-5.9-5.1-9.6-11.6-10.8-19.3c-1.8-11.3,1.3-21.3,8.1-30.2
-						c7.3-9.6,16.1-14.6,28-16.7c10.2-1.8,19.8-0.8,28.5,5.1c7.9,5.4,12.8,12.7,14.1,22.3c1.7,13.5-2.2,24.5-11.5,33.9
-						c-6.6,6.7-14.7,10.9-24,12.8C191.5,154.2,188.8,154.3,186.2,154.6z M210,114.2c-0.1-1.3-0.1-2.3-0.3-3.3
-						c-1.8-9.9-10.9-15.5-20.4-13.3c-9.3,2.1-15.3,8-17.5,17.4c-1.8,7.8,2,15.7,9.2,18.9c5.5,2.4,11,2.1,16.3-0.6
-						C205.2,129.2,209.5,122.8,210,114.2z"/>
-				</g>
-			</g>
-		</g>
-	</g>
-</g>
-</svg>
diff --git a/_content/go-brand/Go-Logo/SVG/Go-Logo_Black.svg b/_content/go-brand/Go-Logo/SVG/Go-Logo_Black.svg
deleted file mode 100644
index 666408b..0000000
--- a/_content/go-brand/Go-Logo/SVG/Go-Logo_Black.svg
+++ /dev/null
@@ -1,60 +0,0 @@
-<?xml version="1.0" encoding="utf-8"?>
-<!-- Generator: Adobe Illustrator 22.1.0, SVG Export Plug-In . SVG Version: 6.00 Build 0)  -->
-<svg version="1.1" id="Layer_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px"
-	 viewBox="0 0 254.5 225" style="enable-background:new 0 0 254.5 225;" xml:space="preserve">
-<style type="text/css">
-	.st0{fill:#2DBCAF;}
-	.st1{fill:#5DC9E1;}
-	.st2{fill:#FDDD00;}
-	.st3{fill:#CE3262;}
-	.st4{fill:#00ACD7;}
-	.st5{fill:#FFFFFF;}
-</style>
-<g>
-	<g>
-		<g>
-			<g>
-				<path d="M40.2,101.1c-0.4,0-0.5-0.2-0.3-0.5l2.1-2.7c0.2-0.3,0.7-0.5,1.1-0.5l35.7,0c0.4,0,0.5,0.3,0.3,0.6l-1.7,2.6
-					c-0.2,0.3-0.7,0.6-1,0.6L40.2,101.1z"/>
-			</g>
-		</g>
-	</g>
-	<g>
-		<g>
-			<g>
-				<path d="M25.1,110.3c-0.4,0-0.5-0.2-0.3-0.5l2.1-2.7c0.2-0.3,0.7-0.5,1.1-0.5l45.6,0c0.4,0,0.6,0.3,0.5,0.6l-0.8,2.4
-					c-0.1,0.4-0.5,0.6-0.9,0.6L25.1,110.3z"/>
-			</g>
-		</g>
-	</g>
-	<g>
-		<g>
-			<g>
-				<path d="M49.3,119.5c-0.4,0-0.5-0.3-0.3-0.6l1.4-2.5c0.2-0.3,0.6-0.6,1-0.6l20,0c0.4,0,0.6,0.3,0.6,0.7l-0.2,2.4
-					c0,0.4-0.4,0.7-0.7,0.7L49.3,119.5z"/>
-			</g>
-		</g>
-	</g>
-	<g>
-		<g id="CXHf1q_5_">
-			<g>
-				<g>
-					<path d="M153.1,99.3c-6.3,1.6-10.6,2.8-16.8,4.4c-1.5,0.4-1.6,0.5-2.9-1c-1.5-1.7-2.6-2.8-4.7-3.8c-6.3-3.1-12.4-2.2-18.1,1.5
-						c-6.8,4.4-10.3,10.9-10.2,19c0.1,8,5.6,14.6,13.5,15.7c6.8,0.9,12.5-1.5,17-6.6c0.9-1.1,1.7-2.3,2.7-3.7c-3.6,0-8.1,0-19.3,0
-						c-2.1,0-2.6-1.3-1.9-3c1.3-3.1,3.7-8.3,5.1-10.9c0.3-0.6,1-1.6,2.5-1.6c5.1,0,23.9,0,36.4,0c-0.2,2.7-0.2,5.4-0.6,8.1
-						c-1.1,7.2-3.8,13.8-8.2,19.6c-7.2,9.5-16.6,15.4-28.5,17c-9.8,1.3-18.9-0.6-26.9-6.6c-7.4-5.6-11.6-13-12.7-22.2
-						c-1.3-10.9,1.9-20.7,8.5-29.3c7.1-9.3,16.5-15.2,28-17.3c9.4-1.7,18.4-0.6,26.5,4.9c5.3,3.5,9.1,8.3,11.6,14.1
-						C154.7,98.5,154.3,99,153.1,99.3z"/>
-				</g>
-				<g>
-					<path d="M186.2,154.6c-9.1-0.2-17.4-2.8-24.4-8.8c-5.9-5.1-9.6-11.6-10.8-19.3c-1.8-11.3,1.3-21.3,8.1-30.2
-						c7.3-9.6,16.1-14.6,28-16.7c10.2-1.8,19.8-0.8,28.5,5.1c7.9,5.4,12.8,12.7,14.1,22.3c1.7,13.5-2.2,24.5-11.5,33.9
-						c-6.6,6.7-14.7,10.9-24,12.8C191.5,154.2,188.8,154.3,186.2,154.6z M210,114.2c-0.1-1.3-0.1-2.3-0.3-3.3
-						c-1.8-9.9-10.9-15.5-20.4-13.3c-9.3,2.1-15.3,8-17.5,17.4c-1.8,7.8,2,15.7,9.2,18.9c5.5,2.4,11,2.1,16.3-0.6
-						C205.2,129.2,209.5,122.8,210,114.2z"/>
-				</g>
-			</g>
-		</g>
-	</g>
-</g>
-</svg>
diff --git a/_content/go-brand/Go-Logo/SVG/Go-Logo_Blue.svg b/_content/go-brand/Go-Logo/SVG/Go-Logo_Blue.svg
deleted file mode 100644
index 64e9620..0000000
--- a/_content/go-brand/Go-Logo/SVG/Go-Logo_Blue.svg
+++ /dev/null
@@ -1,60 +0,0 @@
-<?xml version="1.0" encoding="utf-8"?>
-<!-- Generator: Adobe Illustrator 22.1.0, SVG Export Plug-In . SVG Version: 6.00 Build 0)  -->
-<svg version="1.1" id="Layer_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px"
-	 viewBox="0 0 254.5 225" style="enable-background:new 0 0 254.5 225;" xml:space="preserve">
-<style type="text/css">
-	.st0{fill:#2DBCAF;}
-	.st1{fill:#5DC9E1;}
-	.st2{fill:#FDDD00;}
-	.st3{fill:#CE3262;}
-	.st4{fill:#00ACD7;}
-	.st5{fill:#FFFFFF;}
-</style>
-<g>
-	<g>
-		<g>
-			<g>
-				<path class="st4" d="M40.2,101.1c-0.4,0-0.5-0.2-0.3-0.5l2.1-2.7c0.2-0.3,0.7-0.5,1.1-0.5l35.7,0c0.4,0,0.5,0.3,0.3,0.6
-					l-1.7,2.6c-0.2,0.3-0.7,0.6-1,0.6L40.2,101.1z"/>
-			</g>
-		</g>
-	</g>
-	<g>
-		<g>
-			<g>
-				<path class="st4" d="M25.1,110.3c-0.4,0-0.5-0.2-0.3-0.5l2.1-2.7c0.2-0.3,0.7-0.5,1.1-0.5l45.6,0c0.4,0,0.6,0.3,0.5,0.6
-					l-0.8,2.4c-0.1,0.4-0.5,0.6-0.9,0.6L25.1,110.3z"/>
-			</g>
-		</g>
-	</g>
-	<g>
-		<g>
-			<g>
-				<path class="st4" d="M49.3,119.5c-0.4,0-0.5-0.3-0.3-0.6l1.4-2.5c0.2-0.3,0.6-0.6,1-0.6l20,0c0.4,0,0.6,0.3,0.6,0.7l-0.2,2.4
-					c0,0.4-0.4,0.7-0.7,0.7L49.3,119.5z"/>
-			</g>
-		</g>
-	</g>
-	<g>
-		<g id="CXHf1q_3_">
-			<g>
-				<g>
-					<path class="st4" d="M153.1,99.3c-6.3,1.6-10.6,2.8-16.8,4.4c-1.5,0.4-1.6,0.5-2.9-1c-1.5-1.7-2.6-2.8-4.7-3.8
-						c-6.3-3.1-12.4-2.2-18.1,1.5c-6.8,4.4-10.3,10.9-10.2,19c0.1,8,5.6,14.6,13.5,15.7c6.8,0.9,12.5-1.5,17-6.6
-						c0.9-1.1,1.7-2.3,2.7-3.7c-3.6,0-8.1,0-19.3,0c-2.1,0-2.6-1.3-1.9-3c1.3-3.1,3.7-8.3,5.1-10.9c0.3-0.6,1-1.6,2.5-1.6
-						c5.1,0,23.9,0,36.4,0c-0.2,2.7-0.2,5.4-0.6,8.1c-1.1,7.2-3.8,13.8-8.2,19.6c-7.2,9.5-16.6,15.4-28.5,17
-						c-9.8,1.3-18.9-0.6-26.9-6.6c-7.4-5.6-11.6-13-12.7-22.2c-1.3-10.9,1.9-20.7,8.5-29.3c7.1-9.3,16.5-15.2,28-17.3
-						c9.4-1.7,18.4-0.6,26.5,4.9c5.3,3.5,9.1,8.3,11.6,14.1C154.7,98.5,154.3,99,153.1,99.3z"/>
-				</g>
-				<g>
-					<path class="st4" d="M186.2,154.6c-9.1-0.2-17.4-2.8-24.4-8.8c-5.9-5.1-9.6-11.6-10.8-19.3c-1.8-11.3,1.3-21.3,8.1-30.2
-						c7.3-9.6,16.1-14.6,28-16.7c10.2-1.8,19.8-0.8,28.5,5.1c7.9,5.4,12.8,12.7,14.1,22.3c1.7,13.5-2.2,24.5-11.5,33.9
-						c-6.6,6.7-14.7,10.9-24,12.8C191.5,154.2,188.8,154.3,186.2,154.6z M210,114.2c-0.1-1.3-0.1-2.3-0.3-3.3
-						c-1.8-9.9-10.9-15.5-20.4-13.3c-9.3,2.1-15.3,8-17.5,17.4c-1.8,7.8,2,15.7,9.2,18.9c5.5,2.4,11,2.1,16.3-0.6
-						C205.2,129.2,209.5,122.8,210,114.2z"/>
-				</g>
-			</g>
-		</g>
-	</g>
-</g>
-</svg>
diff --git a/_content/go-brand/Go-Logo/SVG/Go-Logo_Fuchsia.svg b/_content/go-brand/Go-Logo/SVG/Go-Logo_Fuchsia.svg
deleted file mode 100644
index 8def1e1..0000000
--- a/_content/go-brand/Go-Logo/SVG/Go-Logo_Fuchsia.svg
+++ /dev/null
@@ -1,60 +0,0 @@
-<?xml version="1.0" encoding="utf-8"?>
-<!-- Generator: Adobe Illustrator 22.1.0, SVG Export Plug-In . SVG Version: 6.00 Build 0)  -->
-<svg version="1.1" id="Layer_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px"
-	 viewBox="0 0 254.5 225" style="enable-background:new 0 0 254.5 225;" xml:space="preserve">
-<style type="text/css">
-	.st0{fill:#2DBCAF;}
-	.st1{fill:#5DC9E1;}
-	.st2{fill:#FDDD00;}
-	.st3{fill:#CE3262;}
-	.st4{fill:#00ACD7;}
-	.st5{fill:#FFFFFF;}
-</style>
-<g>
-	<g>
-		<g>
-			<g>
-				<path class="st3" d="M40.2,101.1c-0.4,0-0.5-0.2-0.3-0.5l2.1-2.7c0.2-0.3,0.7-0.5,1.1-0.5l35.7,0c0.4,0,0.5,0.3,0.3,0.6
-					l-1.7,2.6c-0.2,0.3-0.7,0.6-1,0.6L40.2,101.1z"/>
-			</g>
-		</g>
-	</g>
-	<g>
-		<g>
-			<g>
-				<path class="st3" d="M25.1,110.3c-0.4,0-0.5-0.2-0.3-0.5l2.1-2.7c0.2-0.3,0.7-0.5,1.1-0.5l45.6,0c0.4,0,0.6,0.3,0.5,0.6
-					l-0.8,2.4c-0.1,0.4-0.5,0.6-0.9,0.6L25.1,110.3z"/>
-			</g>
-		</g>
-	</g>
-	<g>
-		<g>
-			<g>
-				<path class="st3" d="M49.3,119.5c-0.4,0-0.5-0.3-0.3-0.6l1.4-2.5c0.2-0.3,0.6-0.6,1-0.6l20,0c0.4,0,0.6,0.3,0.6,0.7l-0.2,2.4
-					c0,0.4-0.4,0.7-0.7,0.7L49.3,119.5z"/>
-			</g>
-		</g>
-	</g>
-	<g>
-		<g id="CXHf1q_4_">
-			<g>
-				<g>
-					<path class="st3" d="M153.1,99.3c-6.3,1.6-10.6,2.8-16.8,4.4c-1.5,0.4-1.6,0.5-2.9-1c-1.5-1.7-2.6-2.8-4.7-3.8
-						c-6.3-3.1-12.4-2.2-18.1,1.5c-6.8,4.4-10.3,10.9-10.2,19c0.1,8,5.6,14.6,13.5,15.7c6.8,0.9,12.5-1.5,17-6.6
-						c0.9-1.1,1.7-2.3,2.7-3.7c-3.6,0-8.1,0-19.3,0c-2.1,0-2.6-1.3-1.9-3c1.3-3.1,3.7-8.3,5.1-10.9c0.3-0.6,1-1.6,2.5-1.6
-						c5.1,0,23.9,0,36.4,0c-0.2,2.7-0.2,5.4-0.6,8.1c-1.1,7.2-3.8,13.8-8.2,19.6c-7.2,9.5-16.6,15.4-28.5,17
-						c-9.8,1.3-18.9-0.6-26.9-6.6c-7.4-5.6-11.6-13-12.7-22.2c-1.3-10.9,1.9-20.7,8.5-29.3c7.1-9.3,16.5-15.2,28-17.3
-						c9.4-1.7,18.4-0.6,26.5,4.9c5.3,3.5,9.1,8.3,11.6,14.1C154.7,98.5,154.3,99,153.1,99.3z"/>
-				</g>
-				<g>
-					<path class="st3" d="M186.2,154.6c-9.1-0.2-17.4-2.8-24.4-8.8c-5.9-5.1-9.6-11.6-10.8-19.3c-1.8-11.3,1.3-21.3,8.1-30.2
-						c7.3-9.6,16.1-14.6,28-16.7c10.2-1.8,19.8-0.8,28.5,5.1c7.9,5.4,12.8,12.7,14.1,22.3c1.7,13.5-2.2,24.5-11.5,33.9
-						c-6.6,6.7-14.7,10.9-24,12.8C191.5,154.2,188.8,154.3,186.2,154.6z M210,114.2c-0.1-1.3-0.1-2.3-0.3-3.3
-						c-1.8-9.9-10.9-15.5-20.4-13.3c-9.3,2.1-15.3,8-17.5,17.4c-1.8,7.8,2,15.7,9.2,18.9c5.5,2.4,11,2.1,16.3-0.6
-						C205.2,129.2,209.5,122.8,210,114.2z"/>
-				</g>
-			</g>
-		</g>
-	</g>
-</g>
-</svg>
diff --git a/_content/go-brand/Go-Logo/SVG/Go-Logo_LightBlue.svg b/_content/go-brand/Go-Logo/SVG/Go-Logo_LightBlue.svg
deleted file mode 100644
index 55a5071..0000000
--- a/_content/go-brand/Go-Logo/SVG/Go-Logo_LightBlue.svg
+++ /dev/null
@@ -1,60 +0,0 @@
-<?xml version="1.0" encoding="utf-8"?>
-<!-- Generator: Adobe Illustrator 22.1.0, SVG Export Plug-In . SVG Version: 6.00 Build 0)  -->
-<svg version="1.1" id="Layer_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px"
-	 viewBox="0 0 254.5 225" style="enable-background:new 0 0 254.5 225;" xml:space="preserve">
-<style type="text/css">
-	.st0{fill:#2DBCAF;}
-	.st1{fill:#5DC9E1;}
-	.st2{fill:#FDDD00;}
-	.st3{fill:#CE3262;}
-	.st4{fill:#00ACD7;}
-	.st5{fill:#FFFFFF;}
-</style>
-<g>
-	<g>
-		<g>
-			<g>
-				<path class="st1" d="M40.2,101.1c-0.4,0-0.5-0.2-0.3-0.5l2.1-2.7c0.2-0.3,0.7-0.5,1.1-0.5l35.7,0c0.4,0,0.5,0.3,0.3,0.6
-					l-1.7,2.6c-0.2,0.3-0.7,0.6-1,0.6L40.2,101.1z"/>
-			</g>
-		</g>
-	</g>
-	<g>
-		<g>
-			<g>
-				<path class="st1" d="M25.1,110.3c-0.4,0-0.5-0.2-0.3-0.5l2.1-2.7c0.2-0.3,0.7-0.5,1.1-0.5l45.6,0c0.4,0,0.6,0.3,0.5,0.6
-					l-0.8,2.4c-0.1,0.4-0.5,0.6-0.9,0.6L25.1,110.3z"/>
-			</g>
-		</g>
-	</g>
-	<g>
-		<g>
-			<g>
-				<path class="st1" d="M49.3,119.5c-0.4,0-0.5-0.3-0.3-0.6l1.4-2.5c0.2-0.3,0.6-0.6,1-0.6l20,0c0.4,0,0.6,0.3,0.6,0.7l-0.2,2.4
-					c0,0.4-0.4,0.7-0.7,0.7L49.3,119.5z"/>
-			</g>
-		</g>
-	</g>
-	<g>
-		<g id="CXHf1q_7_">
-			<g>
-				<g>
-					<path class="st1" d="M153.1,99.3c-6.3,1.6-10.6,2.8-16.8,4.4c-1.5,0.4-1.6,0.5-2.9-1c-1.5-1.7-2.6-2.8-4.7-3.8
-						c-6.3-3.1-12.4-2.2-18.1,1.5c-6.8,4.4-10.3,10.9-10.2,19c0.1,8,5.6,14.6,13.5,15.7c6.8,0.9,12.5-1.5,17-6.6
-						c0.9-1.1,1.7-2.3,2.7-3.7c-3.6,0-8.1,0-19.3,0c-2.1,0-2.6-1.3-1.9-3c1.3-3.1,3.7-8.3,5.1-10.9c0.3-0.6,1-1.6,2.5-1.6
-						c5.1,0,23.9,0,36.4,0c-0.2,2.7-0.2,5.4-0.6,8.1c-1.1,7.2-3.8,13.8-8.2,19.6c-7.2,9.5-16.6,15.4-28.5,17
-						c-9.8,1.3-18.9-0.6-26.9-6.6c-7.4-5.6-11.6-13-12.7-22.2c-1.3-10.9,1.9-20.7,8.5-29.3c7.1-9.3,16.5-15.2,28-17.3
-						c9.4-1.7,18.4-0.6,26.5,4.9c5.3,3.5,9.1,8.3,11.6,14.1C154.7,98.5,154.3,99,153.1,99.3z"/>
-				</g>
-				<g>
-					<path class="st1" d="M186.2,154.6c-9.1-0.2-17.4-2.8-24.4-8.8c-5.9-5.1-9.6-11.6-10.8-19.3c-1.8-11.3,1.3-21.3,8.1-30.2
-						c7.3-9.6,16.1-14.6,28-16.7c10.2-1.8,19.8-0.8,28.5,5.1c7.9,5.4,12.8,12.7,14.1,22.3c1.7,13.5-2.2,24.5-11.5,33.9
-						c-6.6,6.7-14.7,10.9-24,12.8C191.5,154.2,188.8,154.3,186.2,154.6z M210,114.2c-0.1-1.3-0.1-2.3-0.3-3.3
-						c-1.8-9.9-10.9-15.5-20.4-13.3c-9.3,2.1-15.3,8-17.5,17.4c-1.8,7.8,2,15.7,9.2,18.9c5.5,2.4,11,2.1,16.3-0.6
-						C205.2,129.2,209.5,122.8,210,114.2z"/>
-				</g>
-			</g>
-		</g>
-	</g>
-</g>
-</svg>
diff --git a/_content/go-brand/Go-Logo/SVG/Go-Logo_White.svg b/_content/go-brand/Go-Logo/SVG/Go-Logo_White.svg
deleted file mode 100644
index 4a0a582..0000000
--- a/_content/go-brand/Go-Logo/SVG/Go-Logo_White.svg
+++ /dev/null
@@ -1,60 +0,0 @@
-<?xml version="1.0" encoding="utf-8"?>
-<!-- Generator: Adobe Illustrator 22.1.0, SVG Export Plug-In . SVG Version: 6.00 Build 0)  -->
-<svg version="1.1" id="Layer_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px"
-	 viewBox="0 0 254.5 225" style="enable-background:new 0 0 254.5 225;" xml:space="preserve">
-<style type="text/css">
-	.st0{fill:#2DBCAF;}
-	.st1{fill:#5DC9E1;}
-	.st2{fill:#FDDD00;}
-	.st3{fill:#CE3262;}
-	.st4{fill:#00ACD7;}
-	.st5{fill:#FFFFFF;}
-</style>
-<g>
-	<g>
-		<g>
-			<g>
-				<path class="st5" d="M40.2,101.1c-0.4,0-0.5-0.2-0.3-0.5l2.1-2.7c0.2-0.3,0.7-0.5,1.1-0.5l35.7,0c0.4,0,0.5,0.3,0.3,0.6
-					l-1.7,2.6c-0.2,0.3-0.7,0.6-1,0.6L40.2,101.1z"/>
-			</g>
-		</g>
-	</g>
-	<g>
-		<g>
-			<g>
-				<path class="st5" d="M25.1,110.3c-0.4,0-0.5-0.2-0.3-0.5l2.1-2.7c0.2-0.3,0.7-0.5,1.1-0.5l45.6,0c0.4,0,0.6,0.3,0.5,0.6
-					l-0.8,2.4c-0.1,0.4-0.5,0.6-0.9,0.6L25.1,110.3z"/>
-			</g>
-		</g>
-	</g>
-	<g>
-		<g>
-			<g>
-				<path class="st5" d="M49.3,119.5c-0.4,0-0.5-0.3-0.3-0.6l1.4-2.5c0.2-0.3,0.6-0.6,1-0.6l20,0c0.4,0,0.6,0.3,0.6,0.7l-0.2,2.4
-					c0,0.4-0.4,0.7-0.7,0.7L49.3,119.5z"/>
-			</g>
-		</g>
-	</g>
-	<g>
-		<g id="CXHf1q_2_">
-			<g>
-				<g>
-					<path class="st5" d="M153.1,99.3c-6.3,1.6-10.6,2.8-16.8,4.4c-1.5,0.4-1.6,0.5-2.9-1c-1.5-1.7-2.6-2.8-4.7-3.8
-						c-6.3-3.1-12.4-2.2-18.1,1.5c-6.8,4.4-10.3,10.9-10.2,19c0.1,8,5.6,14.6,13.5,15.7c6.8,0.9,12.5-1.5,17-6.6
-						c0.9-1.1,1.7-2.3,2.7-3.7c-3.6,0-8.1,0-19.3,0c-2.1,0-2.6-1.3-1.9-3c1.3-3.1,3.7-8.3,5.1-10.9c0.3-0.6,1-1.6,2.5-1.6
-						c5.1,0,23.9,0,36.4,0c-0.2,2.7-0.2,5.4-0.6,8.1c-1.1,7.2-3.8,13.8-8.2,19.6c-7.2,9.5-16.6,15.4-28.5,17
-						c-9.8,1.3-18.9-0.6-26.9-6.6c-7.4-5.6-11.6-13-12.7-22.2c-1.3-10.9,1.9-20.7,8.5-29.3c7.1-9.3,16.5-15.2,28-17.3
-						c9.4-1.7,18.4-0.6,26.5,4.9c5.3,3.5,9.1,8.3,11.6,14.1C154.7,98.5,154.3,99,153.1,99.3z"/>
-				</g>
-				<g>
-					<path class="st5" d="M186.2,154.6c-9.1-0.2-17.4-2.8-24.4-8.8c-5.9-5.1-9.6-11.6-10.8-19.3c-1.8-11.3,1.3-21.3,8.1-30.2
-						c7.3-9.6,16.1-14.6,28-16.7c10.2-1.8,19.8-0.8,28.5,5.1c7.9,5.4,12.8,12.7,14.1,22.3c1.7,13.5-2.2,24.5-11.5,33.9
-						c-6.6,6.7-14.7,10.9-24,12.8C191.5,154.2,188.8,154.3,186.2,154.6z M210,114.2c-0.1-1.3-0.1-2.3-0.3-3.3
-						c-1.8-9.9-10.9-15.5-20.4-13.3c-9.3,2.1-15.3,8-17.5,17.4c-1.8,7.8,2,15.7,9.2,18.9c5.5,2.4,11,2.1,16.3-0.6
-						C205.2,129.2,209.5,122.8,210,114.2z"/>
-				</g>
-			</g>
-		</g>
-	</g>
-</g>
-</svg>
diff --git a/_content/go-brand/Go-Logo/SVG/Go-Logo_Yellow.svg b/_content/go-brand/Go-Logo/SVG/Go-Logo_Yellow.svg
deleted file mode 100644
index 7733929..0000000
--- a/_content/go-brand/Go-Logo/SVG/Go-Logo_Yellow.svg
+++ /dev/null
@@ -1,60 +0,0 @@
-<?xml version="1.0" encoding="utf-8"?>
-<!-- Generator: Adobe Illustrator 22.1.0, SVG Export Plug-In . SVG Version: 6.00 Build 0)  -->
-<svg version="1.1" id="Layer_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px"
-	 viewBox="0 0 254.5 225" style="enable-background:new 0 0 254.5 225;" xml:space="preserve">
-<style type="text/css">
-	.st0{fill:#2DBCAF;}
-	.st1{fill:#5DC9E1;}
-	.st2{fill:#FDDD00;}
-	.st3{fill:#CE3262;}
-	.st4{fill:#00ACD7;}
-	.st5{fill:#FFFFFF;}
-</style>
-<g>
-	<g>
-		<g>
-			<g>
-				<path class="st2" d="M40.2,101.1c-0.4,0-0.5-0.2-0.3-0.5l2.1-2.7c0.2-0.3,0.7-0.5,1.1-0.5l35.7,0c0.4,0,0.5,0.3,0.3,0.6
-					l-1.7,2.6c-0.2,0.3-0.7,0.6-1,0.6L40.2,101.1z"/>
-			</g>
-		</g>
-	</g>
-	<g>
-		<g>
-			<g>
-				<path class="st2" d="M25.1,110.3c-0.4,0-0.5-0.2-0.3-0.5l2.1-2.7c0.2-0.3,0.7-0.5,1.1-0.5l45.6,0c0.4,0,0.6,0.3,0.5,0.6
-					l-0.8,2.4c-0.1,0.4-0.5,0.6-0.9,0.6L25.1,110.3z"/>
-			</g>
-		</g>
-	</g>
-	<g>
-		<g>
-			<g>
-				<path class="st2" d="M49.3,119.5c-0.4,0-0.5-0.3-0.3-0.6l1.4-2.5c0.2-0.3,0.6-0.6,1-0.6l20,0c0.4,0,0.6,0.3,0.6,0.7l-0.2,2.4
-					c0,0.4-0.4,0.7-0.7,0.7L49.3,119.5z"/>
-			</g>
-		</g>
-	</g>
-	<g>
-		<g id="CXHf1q_6_">
-			<g>
-				<g>
-					<path class="st2" d="M153.1,99.3c-6.3,1.6-10.6,2.8-16.8,4.4c-1.5,0.4-1.6,0.5-2.9-1c-1.5-1.7-2.6-2.8-4.7-3.8
-						c-6.3-3.1-12.4-2.2-18.1,1.5c-6.8,4.4-10.3,10.9-10.2,19c0.1,8,5.6,14.6,13.5,15.7c6.8,0.9,12.5-1.5,17-6.6
-						c0.9-1.1,1.7-2.3,2.7-3.7c-3.6,0-8.1,0-19.3,0c-2.1,0-2.6-1.3-1.9-3c1.3-3.1,3.7-8.3,5.1-10.9c0.3-0.6,1-1.6,2.5-1.6
-						c5.1,0,23.9,0,36.4,0c-0.2,2.7-0.2,5.4-0.6,8.1c-1.1,7.2-3.8,13.8-8.2,19.6c-7.2,9.5-16.6,15.4-28.5,17
-						c-9.8,1.3-18.9-0.6-26.9-6.6c-7.4-5.6-11.6-13-12.7-22.2c-1.3-10.9,1.9-20.7,8.5-29.3c7.1-9.3,16.5-15.2,28-17.3
-						c9.4-1.7,18.4-0.6,26.5,4.9c5.3,3.5,9.1,8.3,11.6,14.1C154.7,98.5,154.3,99,153.1,99.3z"/>
-				</g>
-				<g>
-					<path class="st2" d="M186.2,154.6c-9.1-0.2-17.4-2.8-24.4-8.8c-5.9-5.1-9.6-11.6-10.8-19.3c-1.8-11.3,1.3-21.3,8.1-30.2
-						c7.3-9.6,16.1-14.6,28-16.7c10.2-1.8,19.8-0.8,28.5,5.1c7.9,5.4,12.8,12.7,14.1,22.3c1.7,13.5-2.2,24.5-11.5,33.9
-						c-6.6,6.7-14.7,10.9-24,12.8C191.5,154.2,188.8,154.3,186.2,154.6z M210,114.2c-0.1-1.3-0.1-2.3-0.3-3.3
-						c-1.8-9.9-10.9-15.5-20.4-13.3c-9.3,2.1-15.3,8-17.5,17.4c-1.8,7.8,2,15.7,9.2,18.9c5.5,2.4,11,2.1,16.3-0.6
-						C205.2,129.2,209.5,122.8,210,114.2z"/>
-				</g>
-			</g>
-		</g>
-	</g>
-</g>
-</svg>
diff --git a/_content/go-brand/Go-Logo/copyright.txt b/_content/go-brand/Go-Logo/copyright.txt
deleted file mode 100644
index 73a9ed2..0000000
--- a/_content/go-brand/Go-Logo/copyright.txt
+++ /dev/null
@@ -1 +0,0 @@
-All content within this zip file is Copyright 2018 The Go Authors. All rights reserved.
\ No newline at end of file
diff --git a/_content/go-brand/Go-brand-book-v1.0.pdf b/_content/go-brand/Go-brand-book-v1.0.pdf
deleted file mode 100644
index 5145b4d..0000000
--- a/_content/go-brand/Go-brand-book-v1.0.pdf
+++ /dev/null
Binary files differ
diff --git a/_content/go-brand/go-logos-1.0.zip b/_content/go-brand/go-logos-1.0.zip
deleted file mode 100644
index 8f32da7..0000000
--- a/_content/go-brand/go-logos-1.0.zip
+++ /dev/null
Binary files differ
diff --git a/_content/go-brand/go-slides-4up.jpg b/_content/go-brand/go-slides-4up.jpg
deleted file mode 100644
index e67b222..0000000
--- a/_content/go-brand/go-slides-4up.jpg
+++ /dev/null
Binary files differ
diff --git a/_content/go-brand/logos.jpg b/_content/go-brand/logos.jpg
deleted file mode 100644
index b033829..0000000
--- a/_content/go-brand/logos.jpg
+++ /dev/null
Binary files differ
diff --git a/_content/go-cloud.article b/_content/go-cloud.article
deleted file mode 100644
index ff10fbf..0000000
--- a/_content/go-cloud.article
+++ /dev/null
@@ -1,183 +0,0 @@
-# Portable Cloud Programming with Go Cloud
-24 Jul 2018
-Summary: Announcing Go Cloud, for portable cloud programming with Go.
-
-Eno Compton
-
-Cassandra Salisbury
-
-## Introduction
-
-Today, the Go team at Google is releasing a new open source project,
-[Go Cloud](https://github.com/google/go-cloud),
-a library and tools for developing on the [open cloud](https://cloud.google.com/open-cloud/).
-With this project, we aim to make Go the language of choice for developers
-building portable cloud applications.
-
-This post explains why we started this project, the details of how Go Cloud works, and how to get involved.
-
-## Why portable cloud programming? Why now?
-
-We estimate there are now [over one million](https://research.swtch.com/gophercount)
-Go developers worldwide.
-Go powers many of the most critical cloud infrastructure projects,
-including Kubernetes, Istio, and Docker.
-Companies like Lyft, Capital One, Netflix and [many more](https://github.com/golang/go/wiki/GoUsers)
-are depending on Go in production.
-Over the years, we've found that developers love Go for cloud development
-because of its efficiency,
-productivity, built-in concurrency, and low latency.
-
-As part of our work to support Go's rapid growth,
-we have been interviewing teams who work with Go to understand how they
-use the language and how the Go ecosystem can improve further.
-One common theme with many organizations is the need for portability across cloud providers.
-These teams want to deploy robust applications in [multi-cloud](https://en.wikipedia.org/wiki/Cloud_computing#Multicloud)
-and [hybrid-cloud](https://en.wikipedia.org/wiki/Cloud_computing#Hybrid_cloud) environments,
-and migrate their workloads between cloud providers without significant
-changes to their code.
-
-To achieve this, some teams attempt to decouple their applications from
-provider-specific APIs in order to produce simpler and more portable code.
-However the short-term pressure to ship features means teams often sacrifice
-longer-term efforts toward portability.
-As a result, most Go applications running in the cloud are tightly coupled
-to their initial cloud provider.
-
-As an alternative, teams can use Go Cloud,
-a set of open generic cloud APIs, to write simpler and more portable cloud applications.
-Go Cloud also sets the foundation for an ecosystem of portable cloud libraries
-to be built on top of these generic APIs.
-Go Cloud makes it possible for teams to meet their feature development goals
-while also preserving the long-term flexibility for multi-cloud and hybrid-cloud architectures.
-Go Cloud applications can also migrate to the cloud providers that best meet their needs.
-
-## What is Go Cloud?
-
-We have identified common services used by cloud applications and have created
-generic APIs to work across cloud providers.
-Today, Go Cloud is launching with blob storage,
-MySQL database access, runtime configuration,
-and an HTTP server configured with request logging,
-tracing, and health checking.
-Go Cloud offers support for Google Cloud Platform (GCP) and Amazon Web Services (AWS).
-We plan to work with cloud industry partners and the Go community to add
-support for additional cloud providers very soon.
-
-Go Cloud aims to develop vendor-neutral generic APIs for the most-used services
-across cloud providers such that deploying a Go application on another cloud is simple and easy.
-Go Cloud also lays the foundation for other open source projects to write
-cloud libraries that work across providers.
-Community feedback, from all types of developers at all levels,
-will inform the priority of future APIs in Go Cloud.
-
-## How does it work?
-
-At the core of Go Cloud is a collection of generic APIs for portable cloud programming.
-Let's look at an example of using blob storage.
-You can use the generic type [`*blob.Bucket`](https://godoc.org/github.com/google/go-cloud/blob#Bucket)
-to copy a file from a local disk to a cloud provider.
-Let's start by opening an S3 bucket using the included [s3blob package](https://godoc.org/github.com/google/go-cloud/blob/s3blob):
-
-	// setupBucket opens an AWS bucket.
-	func setupBucket(ctx context.Context) (*blob.Bucket, error) {
-		// Obtain AWS credentials.
-		sess, err := session.NewSession(&aws.Config{
-			Region: aws.String("us-east-2"),
-		})
-		if err != nil {
-			return nil, err
-		}
-		// Open a handle to s3://go-cloud-bucket.
-		return s3blob.OpenBucket(ctx, sess, "go-cloud-bucket")
-	}
-
-Once a program has a `*blob.Bucket`, it can create a `*blob.Writer`,
-which implements `io.Writer`.
-From there, the program can use the `*blob.Writer` to write data to the bucket,
-checking that `Close` does not report an error.
-
-	ctx := context.Background()
-	b, err := setupBucket(ctx)
-	if err != nil {
-		log.Fatalf("Failed to open bucket: %v", err)
-	}
-	data, err := ioutil.ReadFile("gopher.png")
-	if err != nil {
-		log.Fatalf("Failed to read file: %v", err)
-	}
-	w, err := b.NewWriter(ctx, "gopher.png", nil)
-	if err != nil {
-		log.Fatalf("Failed to obtain writer: %v", err)
-	}
-	_, err = w.Write(data)
-	if err != nil {
-		log.Fatalf("Failed to write to bucket: %v", err)
-	}
-	if err := w.Close(); err != nil {
-		log.Fatalf("Failed to close: %v", err)
-	}
-
-Notice how the logic of using the bucket does not refer to AWS S3.
-Go Cloud makes swapping out cloud storage a matter of changing the function
-used to open the `*blob.Bucket`.
-The application could instead use Google Cloud Storage by constructing a
-`*blob.Bucket` using [`gcsblob.OpenBucket`](https://godoc.org/github.com/google/go-cloud/blob/gcsblob#OpenBucket)
-without changing the code that copies the file:
-
-	// setupBucket opens a GCS bucket.
-	func setupBucket(ctx context.Context) (*blob.Bucket, error) {
-		// Open GCS bucket.
-		creds, err := gcp.DefaultCredentials(ctx)
-		if err != nil {
-			return nil, err
-		}
-		c, err := gcp.NewHTTPClient(gcp.DefaultTransport(), gcp.CredentialsTokenSource(creds))
-		if err != nil {
-			return nil, err
-		}
-		// Open a handle to gs://go-cloud-bucket.
-		return gcsblob.OpenBucket(ctx, "go-cloud-bucket", c)
-	}
-
-While different steps are needed to access buckets on different cloud providers,
-the resulting type used by your application is the same: `*blob.Bucket`.
-This isolates application code from cloud-specific code.
-To increase interoperability with existing Go libraries,
-Go Cloud leverages established interfaces like `io.Writer`,
-`io.Reader`, and `*sql.DB`.
-
-The setup code needed to access cloud services tends to follow a pattern:
-higher abstractions are constructed from more basic abstractions.
-While you could write this code by hand, Go Cloud automates this with **Wire**,
-a tool that generates cloud-specific setup code for you.
-The [Wire documentation](https://github.com/google/go-cloud/tree/master/wire)
-explains how to install and use the tool and the [Guestbook sample](https://github.com/google/go-cloud/tree/master/samples/guestbook)
-shows Wire in action.
-
-## How can I get involved and learn more?
-
-To get started, we recommend following [the tutorial](https://github.com/google/go-cloud/tree/master/samples/tutorial)
-and then trying to build an application yourself.
-If you're already using AWS or GCP, you can try migrating parts of your
-existing application to use Go Cloud.
-If you're using a different cloud provider or an on-premise service,
-you can extend Go Cloud to support it by implementing the driver interfaces
-(like [`driver.Bucket`](https://godoc.org/github.com/google/go-cloud/blob/driver#Bucket)).
-
-We appreciate any and all input you have about your experience.
-[Go Cloud's](https://github.com/google/go-cloud) development is conducted on GitHub.
-We are looking forward to contributions, including pull requests.
-[File an issue](https://github.com/google/go-cloud/issues/new) to tell
-us what could be better or what future APIs the project should support.
-For updates and discussion about the project,
-join [the project's mailing list](https://groups.google.com/forum/#!forum/go-cloud).
-
-The project requires contributors to sign the same Contributor License Agreement
-as that of the Go project.
-Read the [contribution guidelines](https://github.com/google/go-cloud/blob/master/CONTRIBUTING.md) for more details.
-Please note, Go Cloud is covered by the Go [Code of Conduct](https://github.com/google/go-cloud/blob/master/CODE_OF_CONDUCT.md).
-
-Thank you for taking the time to learn about Go Cloud.
-We are excited to work with you to make Go the language of choice for developers
-building portable cloud applications.
diff --git a/_content/go-cloud2019.article b/_content/go-cloud2019.article
deleted file mode 100644
index 7c22a33..0000000
--- a/_content/go-cloud2019.article
+++ /dev/null
@@ -1,80 +0,0 @@
-# What's new in the Go Cloud Development Kit
-4 Mar 2019
-Summary: Recent changes to the Go Cloud Development Kit (Go CDK).
-OldURL: /gcdk-whats-new-in-march-2019
-
-The Go Cloud Development Kit team at Google
-
-## Introduction
-
-Last July, we [introduced](https://blog.golang.org/go-cloud) the [Go Cloud Development Kit](https://gocloud.dev)
-(previously referred to as simply "Go Cloud"),
-an open source project building libraries and tools to improve the experience
-of developing for the cloud with Go.
-We've made a lot of progress since then -- thank you to early contributors!
-We look forward to growing the Go CDK community of users and contributors,
-and are excited to work closely with early adopters.
-
-## Portable APIs
-
-Our first initiative is a set of portable APIs for common cloud services.
-You write your application using these APIs,
-and then deploy it on any combination of providers,
-including AWS, GCP, Azure, on-premise, or on a single developer machine for testing.
-Additional providers can be added by implementing an interface.
-
-These portable APIs are a great fit if any of the following are true:
-
-  - You develop cloud applications locally.
-  - You have on-premise applications that you want to run in the cloud (permanently, or as part of a migration).
-  - You want portability across multiple clouds.
-  - You are creating a new Go application that will use cloud services.
-
-Unlike traditional approaches where you would need to write new application
-code for each cloud provider,
-with the Go CDK you write your application code once using our portable
-APIs to access the set of services listed below.
-Then, you can run your application on any supported cloud with minimal config changes.
-
-Our current set of APIs includes:
-
-  - [blob](https://godoc.org/gocloud.dev/blob),
-    for persistence of blob data.
-    Supported providers include: AWS S3, Google Cloud Storage (GCS),
-    Azure Storage, the filesystem, and in-memory.
-  - [pubsub](https://godoc.org/gocloud.dev/pubsub) for publishing/subscribing
-    of messages to a topic.
-    Supported providers include: Amazon SNS/SQS,
-    Google Pub/Sub, Azure Service Bus, RabbitMQ, and in-memory.
-  - [runtimevar](https://godoc.org/gocloud.dev/runtimevar),
-    for watching external configuration variables.
-    Supported providers include AWS Parameter Store,
-    Google Runtime Configurator, etcd, and the filesystem.
-  - [secrets](https://godoc.org/gocloud.dev/secrets),
-    for encryption/decryption.
-    Supported providers include AWS KMS, GCP KMS,
-    Hashicorp Vault, and local symmetric keys.
-  - Helpers for connecting to cloud SQL providers. Supported providers include AWS RDS and Google Cloud SQL.
-  - We are also working on a document storage API (e.g. MongoDB, DynamoDB, Firestore).
-
-## Feedback
-
-We hope you're as excited about the Go CDK as we are -- check out our [godoc](https://godoc.org/gocloud.dev),
-walk through our [tutorial](https://github.com/google/go-cloud/tree/master/samples/tutorial),
-and use the Go CDK in your application(s).
-We'd love to hear your ideas for other APIs and API providers you'd like to see.
-
-If you're digging into Go CDK please share your experiences with us:
-
-  - What went well?
-  - Were there any pain points using the APIs?
-  - Are there any features missing in the API you used?
-  - Suggestions for documentation improvements.
-
-To send feedback, you can:
-
-  - Submit issues to our public [GitHub repository](https://github.com/google/go-cloud/issues/new/choose).
-  - Email [go-cdk-feedback@google.com](mailto:go-cdk-feedback@google.com).
-  - Post to our [public Google group](https://groups.google.com/forum/#!forum/go-cloud).
-
-Thanks!
diff --git a/_content/go-developer-network.article b/_content/go-developer-network.article
deleted file mode 100644
index 5e560f3..0000000
--- a/_content/go-developer-network.article
+++ /dev/null
@@ -1,33 +0,0 @@
-# The New Go Developer Network
-14 Mar 2019
-Tags: Community
-Summary: Announcing the Go Developer Network, a collection of Go user groups sharing best practices.
-
-GoBridge Leadership Team
-
-##
-
-A sense of community flourishes when we come together in person. As handles become names
-and avatars become faces, the smiles are real and true friendship can grow. There is joy
-in the sharing of knowledge and celebrating the accomplishments of our friends, colleagues,
-and neighbors. In our rapidly growing Go community this critical role is played by the
-Go user groups.
-
-To better support our Go user groups worldwide, the Go community leaders at [GoBridge](https://gobridge.org)
-and Google have joined forces to create a new program called the Go Developer Network
-(GDN). The GDN is a collection of Go user groups working together with a shared mission
-to empower developer communities with the knowledge, experience, and wisdom to build
-the next generation of software in Go.
-
-We have partnered with Meetup to create our own [Pro Network of Go Developers](https://meetup.com/pro/go)
-providing Go developers a single place to search for local user groups, events, and
-see what other Gophers are doing around the world.
-
-User groups that join the GDN will be recognized by GoBridge as the official user group
-for that city and be provided with the latest news, information, conduct policies, and
-procedures. GDN groups will have Meetup fees paid by the GDN and will have access to
-special swag and other fun items. Each organizer of a GDN local group will continue to
-own the group and maintain full admin rights. **If you currently run a user group**,
-please fill out this [application](https://j.mp/gdn-form) to request to join the GDN.
-
-We hope you are as excited about the GDN as we are.
diff --git a/_content/go-fonts.article b/_content/go-fonts.article
deleted file mode 100644
index 34e390b..0000000
--- a/_content/go-fonts.article
+++ /dev/null
@@ -1,298 +0,0 @@
-# Go fonts
-16 Nov 2016
-Summary: Announcing the Go font family, by Bigelow & Holmes.
-
-Nigel Tao
-
-Chuck Bigelow
-
-Rob Pike
-
-## An Announcement
-
-The experimental user interface toolkit being built at
-[`golang.org/x/exp/shiny`](https://godoc.org/golang.org/x/exp/shiny)
-includes several text elements, but there is a problem with testing them:
-What font should be used?
-Answering this question led us to today's announcement,
-the release of a family of high-quality [WGL4](https://en.wikipedia.org/wiki/Windows_Glyph_List_4) TrueType fonts,
-created by the [Bigelow & Holmes](http://bigelowandholmes.typepad.com/) type foundry specifically for the Go project.
-
-The font family, called Go (naturally), includes proportional- and fixed-width faces in normal,
-bold, and italic renderings.
-The fonts have been tested for technical uses, particularly programming.
-Go source code looks particularly good when displayed in Go fonts, as its name implies, with things like
-punctuation characters easily distinguishable and operators lined up and placed consistently:
-
-.image go-fonts/go-font-code.png _ 519
-
-Perhaps the most remarkable feature of the Go fonts is their license:
-They are licensed under the same open source license as the rest of the Go project's software,
-an unusually free arrangement for a high-quality font set.
-
-Here are samples of the proportionally-spaced...
-
-.image go-fonts/go-regular.png _ 600
-
-and monospaced fonts:
-
-.image go-fonts/go-mono.png _ 600
-
-## How to use them
-
-If you just want the TTF files, run
-
-	git clone https://go.googlesource.com/image
-
-and copy them from the subsequent `image/font/gofont/ttfs` directory.
-If you want to use Go (the fonts) with Go (the software), each font is provided by a separate package.
-To use the Go Regular font in a program, import `golang.org/x/image/font/gofont/goregular`, and write:
-
-	font, err := truetype.Parse(goregular.TTF)
-
-The [`github.com/golang/freetype/truetype`](https://godoc.org/github.com/golang/freetype/truetype)
-package provides the [`truetype.Parse`](https://godoc.org/github.com/golang/freetype/truetype#Parse) function today.
-There is also work underway to add a TrueType package under `golang.org/x`
-again licensed under the same open source license as the rest of the Go project's software.
-
-We leave it to you to find some of the other unusual properties the fonts have,
-but for an overview of the fonts' design we asked Chuck Bigelow to provide some background.
-The remainder of this blog post is his response.
-
-## Notes on the fonts, by Chuck Bigelow
-
-The Go fonts are divided into two sets, Go proportional, which is
-sans-serif, and Go Mono, which is slab-serif.
-
-## Go proportional fonts
-
-### Sans-serif
-
-Go proportional fonts are sans-serif, like several popular fonts
-for screen displays. There is some evidence that some sans-serif
-faces at small sizes and low resolutions on screens are slightly
-more legible than their seriffed counterparts, while at large sizes,
-there is not a significant difference in legibility between sans and
-seriffed faces, at least in the pair tested. [1] (The bracketed numbers
-refer to the references listed at the end of this article.)
-
-### Style
-
-Go sans-serif fonts are "humanist" rather than "grotesque" in
-style. This is an historical distinction, not an aesthetic judgment.
-Widely used sans-serif fonts like Helvetica and Arial are called
-grotesque because an early 19th century sans-serif typeface
-was named "Grotesque," and the name became generic.
-
-The shapes of modern grotesque fonts like Helvetica are sculpted,
-with smooth, assimilated forms.
-
-Humanist sans-serifs are derived from Humanist handwriting
-and early fonts of the Italian Renaissance and still show subtle
-traces of pen-written calligraphy. There is some evidence that
-humanist fonts are more legible than grotesque fonts. [2]
-
-### Italics
-
-Go proportional italics have the same width metrics as the roman
-fonts. Go italics are oblique versions of the romans, with one
-noticeable exception: the italic lowercase 'a' is redesigned as a
-cursive single-story form to harmonize with the bowl shapes of
-the b d g p q set, in which the upright forms also adapt well to
-slanting, The addition of cursive 'a' makes the italics appear more
-lively than a simply slanted roman. Some typographers believe that
-slanted roman sans-serif italics are preferable to truly "cursive" sans
-Italics, in part because of history and design. [3]
-
-.image go-fonts/abdgpq-proportional.png
-
-### The x-height
-
-The x-height of a typeface is the height of the lowercase 'x' relative
-to the body size. The x-height of Go fonts is 53.0% of body size, a
-bit larger than the x-heights of Helvetica (52.3%) or Arial (51.9%),
-but the difference is usually unnoticeable at normal reading sizes.
-Typographers believe that larger x-heights contribute to greater
-legibility in small sizes and on screens. A study of "print size"
-(particularly x-height) and reading noted that types for reading on
-screens and for small sizes tend to have large x-heights. [4]
-
-### DIN Legibility Standard
-
-The recent German DIN 1450 legibility standard recommends
-several features for font legibility, including differentiation of
-letter shapes to reduce confusion. The Go fonts conform to the
-1450 standard by carefully differentiating zero from capital O;
-numeral 1 from capital I (eye) and lowercase l (ell); numeral 5 from
-capital S; and numeral 8 from capital B. The shapes of bowls of
-b d p q follow the natural asymmetries of legible Renaissance
-handwriting, aiding differentiation to reduce confusion. [5]
-
-### Weights
-
-The Go proportional fonts come in three weights: Normal, Medium,
-and Bold. The Normal weight is strong enough that it maintains
-clarity on backlit screens, which often tend to erode letter features
-and thickness. The Medium weight has stem thickness 1.25 times
-the Normal, for greater sturdiness on bright screens or for users
-who prefer a sturdy font. The Bold weight has stem thickness
-1.5 times the Normal, bold enough to be distinct from the normal
-weight. These Go fonts have CSS numerical weights of 400, 500,
-and 600. Although CSS specifies "Bold" as a 700 weight and 600
-as Semibold or Demibold, the Go numerical weights match the
-actual progression of the ratios of stem thicknesses:
-Normal:Medium = 400:500; Normal:Bold = 400:600. The Bold
-weight name matches the use of “Bold” as the usual corresponding
-bold weight of a normal font. More discussion of the relationship of
-stem thicknesses, weight names, and CSS numbering is in [6].
-
-### WGL4 character set
-
-The WGL4 character set, originally developed by Microsoft, is often
-used as an informal standard character set. WGL4 includes Western
-and Eastern European Latin characters plus Modern Greek and
-Cyrillic, with additional symbols, signs, and graphical characters,
-totalling more than 650 characters in all. The Go WGL4 fonts can
-be used to compose a wide range of languages. [7]
-
-### Metric compatibility with Arial and Helvetica
-
-The Go sans-serif fonts are nearly metrically compatible with
-standard Helvetica or Arial characters. Texts set in Go occupy
-nearly the same space as texts in Helvetica or Arial (at the same
-size), but Go has a different look and texture because of its
-humanist style. Some Go letters with DIN legibility features are
-wider than corresponding letters in Helvetica or Arial, so some
-texts set in Go may take slightly more space.
-
-## Go Mono fonts
-
-### Monospaced
-
-Go Mono fonts are monospaced—each letter has the same width as
-the other letters. Monospaced fonts have been used in programming
-since the beginning of computing and are still widely used because the
-typewriter regularity of their spacing makes text align in columns and
-rows, a style also found in Greek inscriptions of the 5th century BC.
-(The ancient Greeks didn't have typewriters or computer keyboards,
-but they did have great mathematicians and a great sense of symmetry
-and pattern that shaped their alphabet.)
-
-### Slab-serif
-
-The Go Mono fonts have slab-shaped serifs, giving them a sturdy
-appearance.
-
-### Style
-
-The underlying letter shapes of Go Mono are, like the Go sans-serif fonts,
-derived from humanist handwriting, but the monospacing and slab serifs
-tend to obscure the historical and stylistic connections.
-
-### Italics
-
-Go Mono Italics are oblique versions of the romans, with the exception
-that the italic lowercase 'a' is redesigned as a cursive single-story form
-to harmonize with the bowl shapes of the b d g p q. The cursive 'a' makes
-the italics appear more lively than a simply slanted roman. As with many
-sans-serif fonts, it is believed that slanted roman slab-serifs fonts may
-be more legible than truly "cursive" italics.
-
-.image go-fonts/abdgpq-mono.png
-
-### The x-height
-
-Go Mono fonts have the same x-height as Go sans-serif fonts, 53% of
-the body size. Go Mono looks almost 18% bigger than Courier, which
-has an x-height 45% of body size. Yet Go Mono has the same width
-as Courier, so the bigger look is gained with no loss of economy in
-characters per line.
-
-### DIN Legibility Standard
-
-Go Mono fonts conform to the DIN 1450 standard by differentiating
-zero from capital O; numeral 1 from capital I (eye) and lowercase l (ell);
-numeral 5 from capital S; and numeral 8 from capital B. The shapes of
-bowls of b d p q follow the natural asymmetries of legible Renaissance
-handwriting, aiding differentiation and reducing confusion.
-
-### Weights
-
-Go Mono fonts have two weights: Normal and Bold. The normal weight
-stem is the same as in Go Normal and thus maintains clarity on backlit
-screens, which tend to erode letter features and stem thickness. The
-bold stem thickness is 1.5 times thicker than the normal weight, hence
-the Bold Mono has the same stem thickness as Bold Go proportional.
-Because the letter width of monospaced bold is identical to the width of
-monospaced normal, the bold Mono appears slightly bolder than the
-proportional Go Bold, as more black pixels are put into the same area.)
-
-### Metric compatibility with popular monospaced fonts
-
-Go Mono is metrically compatible with Courier and other monospaced
-fonts that match the "Pica" typewriter type widths of 10 characters per
-linear inch at 12 point. At 10 point, Go Mono fonts set 12 characters
-per inch. The TrueType fonts are scalable, of course, so Go Mono can
-be set at any size.
-
-### WGL4 character set
-
-The Go Mono fonts offer the WGL4 character set often used as an
-informal standard character set. WGL4 includes Western and Eastern
-European Latin characters plus Modern Greek and Cyrillic, with
-additional symbols, signs, and graphical characters. The 650+ characters
-of the Go WGL4 sets can be used for a wide range of languages.
-
-## References
-
-[1] Morris, R. A., Aquilante, K., Yager, D., & Bigelow, C.
-(2002, May). P‐13: Serifs Slow RSVP Reading at Very Small Sizes,
-but Don't Matter at Larger Sizes.
-In SID Symposium Digest of Technical Papers (Vol.
-33, No. 1, pp. 244-247). Blackwell Publishing Ltd.
-
-[2] Bryan Reimer et al. (2014) “Assessing the impact of typeface design
-in a text-rich automotive user interface”,
-Ergonomics, 57:11, 1643-1658.
-http://www.tandfonline.com/doi/abs/10.1080/00140139.2014.940000
-
-[3] Adrian Frutiger - Typefaces: The Complete Works.
-H. Osterer and P. Stamm, editors. Birkhäuser,
-Basel, 2009, page 257.
-
-[4] Legge, G. E., & Bigelow, C. A. (2011).
-Does print size matter for reading? A review of findings from vision science and typography.
-Journal of Vision, 11(5), 8-8. http://jov.arvojournals.org/article.aspx?articleid=2191906
-
-[5] Charles Bigelow. "Oh, oh, zero!" TUGboat, Volume 34 (2013), No. 2.
-https://tug.org/TUGboat/tb34-2/tb107bigelow-zero.pdf
-https://tug.org/TUGboat/tb34-2/tb107bigelow-wang.pdf
-
-[6] "Lucida Basic Font Weights" Bigelow & Holmes.
-http://lucidafonts.com/pages/facts
-
-[7] WGL4 language coverage: Afrikaans, Albanian, Asu, Basque,
-Belarusian, Bemba, Bena, Bosnian, Bulgarian, Catalan, Chiga,
-Colognian, Cornish, Croatian, Czech, Danish, Embu, English, Esperanto,
-Estonian, Faroese, Filipino, Finnish, French, Friulian, Galician,
-Ganda, German, Greek, Gusii, Hungarian, Icelandic, Inari Sami,
-Indonesian, Irish, Italian, Jola-Fonyi, Kabuverdianu, Kalaallisut,
-Kalenjin, Kamba, Kikuyu, Kinyarwanda, Latvian, Lithuanian, Lower
-Sorbian, Luo, Luxembourgish, Luyia, Macedonian, Machame, Makhuwa-Meetto,
-Makonde, Malagasy, Malay, Maltese, Manx, Meru, Morisyen, North
-Ndebele, Northern Sami, Norwegian Bokmål, Norwegian Nynorsk, Nyankole,
-Oromo, Polish, Portuguese, Romanian, Romansh, Rombo, Rundi, Russian,
-Rwa, Samburu, Sango, Sangu, Scottish Gaelic, Sena, Serbian, Shambala,
-Shona, Slovak, Slovenian, Soga, Somali, Spanish, Swahili, Swedish,
-Swiss German, Taita, Teso, Turkish, Turkmen, Upper Sorbian, Vunjo,
-Walser, Welsh, Zulu
-
-## Jabberwocky in Go Regular
-
-From [en.wikipedia.org/wiki/Jabberwocky](https://en.wikipedia.org/wiki/Jabberwocky):
-
-.image go-fonts/go-font-jabberwocky.png _ 500
-
-There is no Greek version listed. Instead, a pangram from [clagnut.com/blog/2380/#Greek](http://clagnut.com/blog/2380/#Greek):
-
-.image go-fonts/go-font-greek.png _ 530
diff --git a/_content/go-fonts/abdgpq-mono.png b/_content/go-fonts/abdgpq-mono.png
deleted file mode 100644
index 9f1455e..0000000
--- a/_content/go-fonts/abdgpq-mono.png
+++ /dev/null
Binary files differ
diff --git a/_content/go-fonts/abdgpq-proportional.png b/_content/go-fonts/abdgpq-proportional.png
deleted file mode 100644
index 1a000cd..0000000
--- a/_content/go-fonts/abdgpq-proportional.png
+++ /dev/null
Binary files differ
diff --git a/_content/go-fonts/go-font-code.png b/_content/go-fonts/go-font-code.png
deleted file mode 100644
index 630cccf..0000000
--- a/_content/go-fonts/go-font-code.png
+++ /dev/null
Binary files differ
diff --git a/_content/go-fonts/go-font-greek.png b/_content/go-fonts/go-font-greek.png
deleted file mode 100644
index 9a86101..0000000
--- a/_content/go-fonts/go-font-greek.png
+++ /dev/null
Binary files differ
diff --git a/_content/go-fonts/go-font-jabberwocky.png b/_content/go-fonts/go-font-jabberwocky.png
deleted file mode 100644
index 46386f2..0000000
--- a/_content/go-fonts/go-font-jabberwocky.png
+++ /dev/null
Binary files differ
diff --git a/_content/go-fonts/go-mono.png b/_content/go-fonts/go-mono.png
deleted file mode 100644
index e6ca797..0000000
--- a/_content/go-fonts/go-mono.png
+++ /dev/null
Binary files differ
diff --git a/_content/go-fonts/go-regular.png b/_content/go-fonts/go-regular.png
deleted file mode 100644
index d4ab399..0000000
--- a/_content/go-fonts/go-regular.png
+++ /dev/null
Binary files differ
diff --git a/_content/go.dev.article b/_content/go.dev.article
deleted file mode 100644
index ea7dccb..0000000
--- a/_content/go.dev.article
+++ /dev/null
@@ -1,46 +0,0 @@
-# Go.dev: a new hub for Go developers
-13 Nov 2019
-Summary: Announcing go.dev, which answers: who else is using Go, what do they use it for, and how can I find useful Go packages?
-
-Steve Francia and Julie Qiu
-julieqiu@golang.org
-
-##
-
-Over the last two years,
-as we’ve spoken with users at companies of all sizes,
-we’ve heard three questions repeatedly:
-who else is using Go,
-what do they use it for,
-and how can I find useful Go packages?
-
-Today we are launching [go.dev](https://go.dev), a new hub for Go developers,
-to help answer those questions.
-There you will find a wealth of learning resources to get started with the language,
-featured use cases, and case studies of companies using Go.
-
-.image go.dev/home.png _ 850
-
-(Note that [golang.org](https://golang.org/) is still the home for the
-open source Go project and the Go distribution.
-Go.dev is a companion site to provide these supporting resources.)
-
-Clicking on Explore brings you to [pkg.go.dev](https://pkg.go.dev/),
-a central source of information about Go packages and modules.
-Like [godoc.org](https://godoc.org/), pkg.go.dev serves Go documentation.
-However, it also understands modules and has information
-about all versions of a package, including
-[all releases of the standard library](https://pkg.go.dev/std?tab=versions)!
-And it detects and displays licenses and has a better search algorithm.
-You can follow
-[Go issue 33654](https://golang.org/issue/33654) for future developments.
-
-.image go.dev/http.png _ 850
-
-Today’s launch is our minimum viable product for go.dev,
-so we can share what we’ve built to help the community and get feedback.
-We intend to expand the site over time.
-If you have any ideas, suggestions or issues,
-please let us know via the “Share Feedback” and “Report an Issue” links at the bottom of every page.
-Or you can send your bugs, ideas, feature requests, and questions to
-[go-discovery-feedback@google.com](mailto:go-discovery-feedback@google.com).
diff --git a/_content/go.dev/home.png b/_content/go.dev/home.png
deleted file mode 100644
index 544418f..0000000
--- a/_content/go.dev/home.png
+++ /dev/null
Binary files differ
diff --git a/_content/go.dev/http.png b/_content/go.dev/http.png
deleted file mode 100644
index aa4b448..0000000
--- a/_content/go.dev/http.png
+++ /dev/null
Binary files differ
diff --git a/_content/go1-path.article b/_content/go1-path.article
deleted file mode 100644
index ce867ea..0000000
--- a/_content/go1-path.article
+++ /dev/null
@@ -1,26 +0,0 @@
-# The path to Go 1
-14 Mar 2013
-Tags: talk, video, go1
-Summary: Watch Rob Pike and Andrew Gerrand's talk, The Path to Go 1.
-OldURL: /the-path-to-go-1
-
-Andrew Gerrand
-
-##
-
-In July 2012, Rob Pike and I presented a talk at OSCON titled _The path to Go 1_.
-In it we explain how Go 1 came to be, and outline the process by which Go
-was refined and stabilized to become the clean,
-consistent programming environment that it is today.
-We present the major highlights of the release and discuss the details behind
-some specific libraries and tools.
-
-.iframe //www.youtube.com/embed/bj9T2c2Xk_s 309 550
-
-The slides for the talk are [available here](https://talks.golang.org/2012/go1.slide).
-
-It's almost a year since we cut Go 1.0 and we are now busy preparing Go 1.1.
-The release will include performance improvements to the gc compiler,
-garbage collector, and goroutine scheduler,
-some standard library additions, and many bug fixes and other improvements.
-Stay tuned, as we hope to release Go 1.1 in the coming weeks.
diff --git a/_content/go1-preview.article b/_content/go1-preview.article
deleted file mode 100644
index 6e3f474..0000000
--- a/_content/go1-preview.article
+++ /dev/null
@@ -1,49 +0,0 @@
-# A preview of Go version 1
-5 Oct 2011
-Tags: go1, release
-Summary: What the Go team is planning for Go version 1.
-OldURL: /preview-of-go-version-1
-
-Russ Cox
-
-##
-
-We want to be able to provide a stable base for people using Go.
-People should be able to write Go programs and expect that they will continue
-to compile and run without change,
-on a timescale of years.
-Similarly, people should be able to write books about Go,
-be able to say which version of Go the book is describing,
-and have that version number still be meaningful much later.
-None of these properties is true for Go today.
-
-We propose to issue a Go release early next year that will be called “Go version 1”,
-Go 1 for short, that will be the first Go release to be stable in this way.
-Code that compiles in Go version 1 should,
-with few exceptions, continue to compile throughout the lifetime of that version,
-as we issue updates and bug fixes such as Go version 1.1, 1.2, and so on.
-It will also be maintained with fixes for bugs and security flaws even as
-other versions may evolve.
-Also, production environments such as Google App Engine will support it
-for an extended time.
-
-Go version 1 will be a stable language with stable libraries.
-Other than critical fixes, changes made to the library and packages for versions 1.1,
-1.2 and so on may add functionality but will not break existing Go version 1 programs.
-
-Our goal is for Go 1 to be a stable version of today’s Go,
-not a wholesale rethinking of the language.
-In particular, we are explicitly resisting any efforts to design new language
-features “by committee.”
-
-However, there are various changes to the Go language and packages that
-we have intended for some time and prototyped but have not deployed yet,
-primarily because they are significant and backwards-incompatible.
-If Go 1 is to be long-lasting, it is important that we plan,
-announce, implement, and test these changes as part of the preparation of Go 1,
-rather than delay them until after it is released and thereby introduce
-divergence that contradicts our goals.
-
-Today, we are publishing our preliminary [plan for Go 1](https://docs.google.com/document/pub?id=1ny8uI-_BHrDCZv_zNBSthNKAMX_fR_0dc6epA6lztRE)
-for feedback from the Go community.
-If you have feedback, please reply to the [thread on the golang-nuts mailing list](http://groups.google.com/group/golang-nuts/browse_thread/thread/badc4f323431a4f6).
diff --git a/_content/go1.1.article b/_content/go1.1.article
deleted file mode 100644
index f2f26c6..0000000
--- a/_content/go1.1.article
+++ /dev/null
@@ -1,58 +0,0 @@
-# Go 1.1 is released
-13 May 2013
-Tags: release
-Summary: Go 1.1 is faster, less picky about return statements, and adds method expressions.
-OldURL: /go-11-is-released
-
-Andrew Gerrand
-
-##
-
-It is our great pleasure to announce the release of Go 1.1.
-
-.image go1.1/gopherbiplane5.jpg
-
-In March last year we released Go 1.0, and since then we have released three
-minor "point releases".
-The point releases were made to fix only critical issues,
-so the Go 1.0.3 you use today is still, in essence,
-the Go 1.0 we released in March 2012.
-
-Go 1.1 includes many improvements over 1.0.
-
-The most significant improvements are performance-related.
-We have made optimizations in the compiler and linker,
-garbage collector, goroutine scheduler, map implementation,
-and parts of the standard library.
-It is likely that your Go code will run noticeably faster when built with Go 1.1.
-
-There are some minor changes to the language itself,
-two of which are worth singling out here:
-the [changes to return requirements](https://golang.org/doc/go1.1#return) will
-lead to more succinct and correct programs,
-and the introduction of [method values](https://golang.org/doc/go1.1#method_values) provides
-an expressive way to bind a method to its receiver as a function value.
-
-Concurrent programming is safer in Go 1.1 with the addition of a race
-detector for finding memory synchronization errors in your programs.
-We will discuss the race detector more in an upcoming article,
-but for now [the manual](https://golang.org/doc/articles/race_detector.html) is
-a great place to get started.
-
-The tools and standard library have been improved and expanded.
-You can read the full story in the [release notes](https://golang.org/doc/go1.1).
-
-As per our [compatibility guidelines](https://golang.org/doc/go1compat.html),
-Go 1.1 remains compatible with Go 1.0 and we recommend all Go users upgrade to the new release.
-
-All this would not have been possible without the help of our contributors from
-the open source community.
-Since Go 1.0, the core received more than 2600 commits from 161 people outside Google.
-Thank you everyone for your time and effort.
-In particular, we would like to thank Shenghou Ma,
-Rémy Oudompheng, Dave Cheney, Mikio Hara,
-Alex Brainman, Jan Ziak, and Daniel Morsing for their outstanding contributions.
-
-To grab the new release, follow the usual [installation instructions](https://golang.org/doc/install). Happy hacking!
-
-_Thanks to Renée French for the gopher!_
diff --git a/_content/go1.1/gopherbiplane5.jpg b/_content/go1.1/gopherbiplane5.jpg
deleted file mode 100644
index 9b56e23..0000000
--- a/_content/go1.1/gopherbiplane5.jpg
+++ /dev/null
Binary files differ
diff --git a/_content/go1.10.article b/_content/go1.10.article
deleted file mode 100644
index dd423fc..0000000
--- a/_content/go1.10.article
+++ /dev/null
@@ -1,35 +0,0 @@
-# Go 1.10 is released
-16 Feb 2018
-Summary: Go 1.10 adds automatic caching of build & test results, and more.
-
-Brad Fitzpatrick
-bradfitz@golang.org
-
-##
-
-Happy Friday, happy weekend! Today the Go team is happy to announce the release of Go 1.10.
-You can get it from the [download page](https://golang.org/dl/).
-
-See the [Go 1.10 release notes](https://golang.org/doc/go1.10) for all the details.
-
-The most exciting part of this release for many people will probably
-be that the `go` tool now does
-[automatic caching of build & test results](https://golang.org/doc/go1.10#build).
-Of course, one of the hundreds of smaller changes may be **your** favorite.
-
-To celebrate the release, Go User Groups around the world are holding
-[release parties](https://github.com/golang/go/wiki/Go-1.10-Release-Party).
-See if there's one in your area, or feel free to organize one!
-
-Thanks to everyone who contributed to this release and everyone who
-helped test the Go 1.10 betas and release candidates to ensure a perfect,
-bug-free final release. However, if you do notice any bugs or unexpected
-changes not noted in the release notes, be sure to
-[file a bug](https://golang.org/issues/new).
-
-Enjoy the weekend, and enjoy the new release!
-
-P.S. Many of this year's Go conferences are accepting talk proposals
-this month. We always love to see new speakers and encourage you to
-think about proposing a talk. For more information, see
-[golang.org/wiki/NewSpeakers](https://golang.org/wiki/NewSpeakers).
diff --git a/_content/go1.11.article b/_content/go1.11.article
deleted file mode 100644
index b612ebc..0000000
--- a/_content/go1.11.article
+++ /dev/null
@@ -1,39 +0,0 @@
-# Go 1.11 is released
-24 Aug 2018
-Summary: Go 1.11 adds preliminary support for Go modules, WebAssembly, and more.
-
-Andrew Bonventre
-andybons@golang.org
-
-##
-
-Who says releasing on Friday is a bad idea?
-
-Today the Go team is happy to announce the release of Go 1.11.
-You can get it from the [download page](https://golang.org/dl/).
-
-There are many changes and improvements to the toolchain,
-runtime, and libraries, but two features stand out as being especially exciting:
-modules and WebAssembly support.
-
-This release adds preliminary support for a [new concept called “modules,”](https://golang.org/doc/go1.11#modules)
-an alternative to GOPATH with integrated support for versioning and package distribution.
-Module support is considered experimental,
-and there are still a few rough edges to smooth out,
-so please make liberal use of the [issue tracker](https://golang.org/issue/new).
-
-Go 1.11 also adds an experimental port to [WebAssembly](https://golang.org/doc/go1.11#wasm) (`js/wasm`).
-This allows programmers to compile Go programs to a binary format compatible with four major web browsers.
-You can read more about WebAssembly (abbreviated “Wasm”) at [webassembly.org](https://webassembly.org/)
-and see [this wiki page](https://golang.org/wiki/WebAssembly) on how to
-get started with using Wasm with Go.
-Special thanks to [Richard Musiol](https://github.com/neelance) for contributing the WebAssembly port!
-
-We also want to thank everyone who contributed to this release by writing code,
-filing bugs, providing feedback, and/or testing the betas and release candidates.
-Your contributions and diligence helped to ensure that Go 1.11 is as bug-free as possible.
-That said, if you do notice any problems, please [file an issue](https://golang.org/issues/new).
-
-For more detail about the changes in Go 1.11, see the [release notes](https://golang.org/doc/go1.11).
-
-Have a wonderful weekend and enjoy the release!
diff --git a/_content/go1.12.article b/_content/go1.12.article
deleted file mode 100644
index 79f0e25..0000000
--- a/_content/go1.12.article
+++ /dev/null
@@ -1,21 +0,0 @@
-# Go 1.12 is released
-25 Feb 2019
-Summary: Go 1.12 adds opt-in TLS 1.3, improved modules, and more.
-
-Andrew Bonventre
-andybons@golang.org
-
-##
-
-Today the Go team is happy to announce the release of Go 1.12.
-You can get it from the [download page](https://golang.org/dl/).
-
-For details about the changes in Go 1.12, see the [**Go 1.12 release notes**](https://golang.org/doc/go1.12).
-
-Some of the highlights include [opt-in support for TLS 1.3](https://golang.org/doc/go1.12#tls_1_3), [improved modules support](https://golang.org/doc/go1.12#modules) (in preparation [for being the default in Go 1.13](/modules2019)), support for `windows/arm`, and [improved macOS & iOS forwards compatibility.](https://golang.org/doc/go1.12#darwin)
-
-As always, we also want to thank everyone who contributed to this release by writing code, filing bugs, providing feedback, and/or testing the betas and release candidates.
-Your contributions and diligence helped to ensure that Go 1.12 is as stable as possible.
-That said, if you do notice any problems, please [file an issue](https://golang.org/issues/new).
-
-Enjoy the new release!
diff --git a/_content/go1.13-errors.article b/_content/go1.13-errors.article
deleted file mode 100644
index f5ffd84..0000000
--- a/_content/go1.13-errors.article
+++ /dev/null
@@ -1,345 +0,0 @@
-# Working with Errors in Go 1.13
-17 Oct 2019
-Tags: errors, technical
-Summary: How to use the new Go 1.13 error interfaces and functions.
-
-Damien Neil and Jonathan Amsterdam
-
-## Introduction
-
-Go’s treatment of [errors as values](https://blog.golang.org/errors-are-values)
-has served us well over the last decade. Although the standard library’s support
-for errors has been minimal—just the `errors.New` and `fmt.Errorf` functions,
-which produce errors that contain only a message—the built-in `error` interface
-allows Go programmers to add whatever information they desire. All it requires
-is a type that implements an `Error` method:
-
-	type QueryError struct {
-		Query string
-		Err   error
-	}
-
-	func (e *QueryError) Error() string { return e.Query + ": " + e.Err.Error() }
-
-Error types like this one are ubiquitous, and the information they store varies
-widely, from timestamps to filenames to server addresses. Often, that
-information includes another, lower-level error to provide additional context.
-
-The pattern of one error containing another is so pervasive in Go code that,
-after [extensive discussion](https://golang.org/issue/29934), Go 1.13 added
-explicit support for it. This post describes the additions to the standard
-library that provide that support: three new functions in the `errors` package,
-and a new formatting verb for `fmt.Errorf`.
-
-Before describing the changes in detail, let's review how errors are examined
-and constructed in previous versions of the language.
-
-## Errors before Go 1.13
-
-### Examining errors
-
-Go errors are values. Programs make decisions based on those values in a few
-ways. The most common is to compare an error to `nil` to see if an operation
-failed.
-
-	if err != nil {
-		// something went wrong
-	}
-
-Sometimes we compare an error to a known _sentinel_ value, to see if a specific error has occurred.
-
-	var ErrNotFound = errors.New("not found")
-
-	if err == ErrNotFound {
-		// something wasn't found
-	}
-
-An error value may be of any type which satisfies the language-defined `error`
-interface. A program can use a type assertion or type switch to view an error
-value as a more specific type.
-
-	type NotFoundError struct {
-		Name string
-	}
-
-	func (e *NotFoundError) Error() string { return e.Name + ": not found" }
-
-	if e, ok := err.(*NotFoundError); ok {
-		// e.Name wasn't found
-	}
-
-### Adding information
-
-Frequently a function passes an error up the call stack while adding information
-to it, like a brief description of what was happening when the error occurred. A
-simple way to do this is to construct a new error that includes the text of the
-previous one:
-
-	if err != nil {
-		return fmt.Errorf("decompress %v: %v", name, err)
-	}
-
-Creating a new error with `fmt.Errorf` discards everything from the original
-error except the text. As we saw above with `QueryError`, we may sometimes want
-to define a new error type that contains the underlying error, preserving it for
-inspection by code. Here is `QueryError` again:
-
-	type QueryError struct {
-		Query string
-		Err   error
-	}
-
-Programs can look inside a `*QueryError` value to make decisions based on the
-underlying error. You'll sometimes see this referred to as "unwrapping" the
-error.
-
-	if e, ok := err.(*QueryError); ok && e.Err == ErrPermission {
-		// query failed because of a permission problem
-	}
-
-The `os.PathError` type in the standard library is another example of one error which contains another.
-
-## Errors in Go 1.13
-
-### The Unwrap method
-
-Go 1.13 introduces new features to the `errors` and `fmt` standard library
-packages to simplify working with errors that contain other errors. The most
-significant of these is a convention rather than a change: an error which
-contains another may implement an `Unwrap` method returning the underlying
-error. If `e1.Unwrap()` returns `e2`, then we say that `e1` _wraps_ `e2`, and
-that you can _unwrap_ `e1` to get `e2`.
-
-Following this convention, we can give the `QueryError` type above an `Unwrap`
-method that returns its contained error:
-
-	func (e *QueryError) Unwrap() error { return e.Err }
-
-The result of unwrapping an error may itself have an `Unwrap` method; we call
-the sequence of errors produced by repeated unwrapping the _error chain_.
-
-### Examining errors with Is and As
-
-The Go 1.13 `errors` package includes two new functions for examining errors: `Is` and `As`.
-
-The `errors.Is` function compares an error to a value.
-
-	// Similar to:
-	//   if err == ErrNotFound { … }
-	if errors.Is(err, ErrNotFound) {
-		// something wasn't found
-	}
-
-The `As` function tests whether an error is a specific type.
-
-	// Similar to:
-	//   if e, ok := err.(*QueryError); ok { … }
-	var e *QueryError
-	// Note: *QueryError is the type of the error.
-	if errors.As(err, &e) {
-		// err is a *QueryError, and e is set to the error's value
-	}
-
-In the simplest case, the `errors.Is` function behaves like a comparison to a
-sentinel error, and the `errors.As` function behaves like a type assertion. When
-operating on wrapped errors, however, these functions consider all the errors in
-a chain. Let's look again at the example from above of unwrapping a `QueryError`
-to examine the underlying error:
-
-	if e, ok := err.(*QueryError); ok && e.Err == ErrPermission {
-		// query failed because of a permission problem
-	}
-
-Using the `errors.Is` function, we can write this as:
-
-	if errors.Is(err, ErrPermission) {
-		// err, or some error that it wraps, is a permission problem
-	}
-
-The `errors` package also includes a new `Unwrap` function which returns the
-result of calling an error's `Unwrap` method, or `nil` when the error has no
-`Unwrap` method. It is usually better to use `errors.Is` or `errors.As`,
-however, since these functions will examine the entire chain in a single call.
-
-Note: although it may feel odd to take a pointer to a pointer, in this case it
-is correct. Think of it instead as taking a pointer to a value of the error
-type; it so happens in this case that the returned error is a pointer type.
-
-### Wrapping errors with %w
-
-As mentioned earlier, it is common to use the `fmt.Errorf` function to add additional information to an error.
-
-	if err != nil {
-		return fmt.Errorf("decompress %v: %v", name, err)
-	}
-
-In Go 1.13, the `fmt.Errorf` function supports a new `%w` verb. When this verb
-is present, the error returned by `fmt.Errorf` will have an `Unwrap` method
-returning the argument of `%w`, which must be an error. In all other ways, `%w`
-is identical to `%v`.
-
-	if err != nil {
-		// Return an error which unwraps to err.
-		return fmt.Errorf("decompress %v: %w", name, err)
-	}
-
-Wrapping an error with `%w` makes it available to `errors.Is` and `errors.As`:
-
-	err := fmt.Errorf("access denied: %w", ErrPermission)
-	...
-	if errors.Is(err, ErrPermission) ...
-
-### Whether to Wrap
-
-When adding additional context to an error, either with `fmt.Errorf` or by
-implementing a custom type, you need to decide whether the new error should wrap
-the original. There is no single answer to this question; it depends on the
-context in which the new error is created. Wrap an error to expose it to
-callers. Do not wrap an error when doing so would expose implementation details.
-
-As one example, imagine a `Parse` function which reads a complex data structure
-from an `io.Reader`. If an error occurs, we wish to report the line and column
-number at which it occurred. If the error occurs while reading from the
-`io.Reader`, we will want to wrap that error to allow inspection of the
-underlying problem. Since the caller provided the `io.Reader` to the function,
-it makes sense to expose the error produced by it.
-
-In contrast, a function which makes several calls to a database probably should
-not return an error which unwraps to the result of one of those calls. If the
-database used by the function is an implementation detail, then exposing these
-errors is a violation of abstraction. For example, if the `LookupUser` function
-of your package `pkg` uses Go's `database/sql` package, then it may encounter a
-`sql.ErrNoRows` error. If you return that error with
-`fmt.Errorf("accessing DB: %v", err)`
-then a caller cannot look inside to find the `sql.ErrNoRows`. But if
-the function instead returns `fmt.Errorf("accessing DB: %w", err)`, then a
-caller could reasonably write
-
-	err := pkg.LookupUser(...)
-	if errors.Is(err, sql.ErrNoRows) …
-
-At that point, the function must always return `sql.ErrNoRows` if you don't want
-to break your clients, even if you switch to a different database package. In
-other words, wrapping an error makes that error part of your API. If you don't
-want to commit to supporting that error as part of your API in the future, you
-shouldn't wrap the error.
-
-It’s important to remember that whether you wrap or not, the error text will be
-the same. A _person_ trying to understand the error will have the same information
-either way; the choice to wrap is about whether to give _programs_ additional
-information so they can make more informed decisions, or to withhold that
-information to preserve an abstraction layer.
-
-## Customizing error tests with Is and As methods
-
-The `errors.Is` function examines each error in a chain for a match with a
-target value. By default, an error matches the target if the two are equal. In
-addition, an error in the chain may declare that it matches a target by
-implementing an `Is` _method_.
-
-As an example, consider this error inspired by the
-[Upspin error package](https://commandcenter.blogspot.com/2017/12/error-handling-in-upspin.html)
-which compares an error against a template, considering only fields which are
-non-zero in the template:
-
-	type Error struct {
-		Path string
-		User string
-	}
-
-	func (e *Error) Is(target error) bool {
-		t, ok := target.(*Error)
-		if !ok {
-			return false
-		}
-		return (e.Path == t.Path || t.Path == "") &&
-			   (e.User == t.User || t.User == "")
-	}
-
-	if errors.Is(err, &Error{User: "someuser"}) {
-		// err's User field is "someuser".
-	}
-
-The `errors.As` function similarly consults an `As` method when present.
-
-## Errors and package APIs
-
-A package which returns errors (and most do) should describe what properties of
-those errors programmers may rely on. A well-designed package will also avoid
-returning errors with properties that should not be relied upon.
-
-The simplest specification is to say that operations either succeed or fail,
-returning a nil or non-nil error value respectively. In many cases, no further
-information is needed.
-
-If we wish a function to return an identifiable error condition, such as "item
-not found," we might return an error wrapping a sentinel.
-
-	var ErrNotFound = errors.New("not found")
-
-	// FetchItem returns the named item.
-	//
-	// If no item with the name exists, FetchItem returns an error
-	// wrapping ErrNotFound.
-	func FetchItem(name string) (*Item, error) {
-		if itemNotFound(name) {
-			return nil, fmt.Errorf("%q: %w", name, ErrNotFound)
-		}
-		// ...
-	}
-
-There are other existing patterns for providing errors which can be semantically
-examined by the caller, such as directly returning a sentinel value, a specific
-type, or a value which can be examined with a predicate function.
-
-In all cases, care should be taken not to expose internal details to the user.
-As we touched on in "Whether to Wrap" above, when you return
-an error from another package you should convert the error to a form that does
-not expose the underlying error, unless you are willing to commit to returning
-that specific error in the future.
-
-	f, err := os.Open(filename)
-	if err != nil {
-		// The *os.PathError returned by os.Open is an internal detail.
-		// To avoid exposing it to the caller, repackage it as a new
-		// error with the same text. We use the %v formatting verb, since
-		// %w would permit the caller to unwrap the original *os.PathError.
-		return fmt.Errorf("%v", err)
-	}
-
-If a function is defined as returning an error wrapping some sentinel or type,
-do not return the underlying error directly.
-
-	var ErrPermission = errors.New("permission denied")
-
-	// DoSomething returns an error wrapping ErrPermission if the user
-	// does not have permission to do something.
-	func DoSomething() error {
-		if !userHasPermission() {
-			// If we return ErrPermission directly, callers might come
-			// to depend on the exact error value, writing code like this:
-			//
-			//     if err := pkg.DoSomething(); err == pkg.ErrPermission { … }
-			//
-			// This will cause problems if we want to add additional
-			// context to the error in the future. To avoid this, we
-			// return an error wrapping the sentinel so that users must
-			// always unwrap it:
-			//
-			//     if err := pkg.DoSomething(); errors.Is(err, pkg.ErrPermission) { ... }
-			return fmt.Errorf("%w", ErrPermission)
-		}
-		// ...
-	}
-
-## Conclusion
-
-Although the changes we’ve discussed amount to just three functions and a
-formatting verb, we hope they will go a long way toward improving how errors are
-handled in Go programs. We expect that wrapping to provide additional context
-will become commonplace, helping programs to make better decisions and helping
-programmers to find bugs more quickly.
-
-As Russ Cox said in his [GopherCon 2019 keynote](https://blog.golang.org/experiment),
-on the path to Go 2 we experiment, simplify and ship. Now that we’ve
-shipped these changes, we look forward to the experiments that will follow.
diff --git a/_content/go1.13.article b/_content/go1.13.article
deleted file mode 100644
index 156a0e9..0000000
--- a/_content/go1.13.article
+++ /dev/null
@@ -1,25 +0,0 @@
-# Go 1.13 is released
-3 Sep 2019
-Summary: Go 1.13 adds module authentication, new number literals, error wrapping, TLS 1.3 on by default, and more.
-
-Andrew Bonventre
-
-##
-
-Today the Go team is very happy to announce the release of Go 1.13. You can get it from the [download page](https://golang.org/dl).
-
-Some of the highlights include:
-
-  - The `go` command now downloads and authenticates modules [using the Go module mirror and Go checksum database by default](https://golang.org/doc/go1.13#introduction)
-  - [Improvements to number literals](https://golang.org/doc/go1.13#language)
-  - [Error wrapping](https://golang.org/doc/go1.13#error_wrapping)
-  - [TLS 1.3 on by default](https://golang.org/doc/go1.13#tls_1_3)
-  - [Improved modules support](https://golang.org/doc/go1.13#modules)
-
-For the complete list of changes and more information about the improvements above, see the [**Go 1.13 release notes**](https://golang.org/doc/go1.13).
-
-We want to thank everyone who contributed to this release by writing code, filing bugs, providing feedback, and/or testing the beta and release candidates.
-Your contributions and diligence helped to ensure that Go 1.13 is as stable as possible.
-That said, if you notice any problems, please [file an issue](https://golang.org/issue/new).
-
-We hope you enjoy the new release!
diff --git a/_content/go1.14.article b/_content/go1.14.article
deleted file mode 100644
index 9c6cefb..0000000
--- a/_content/go1.14.article
+++ /dev/null
@@ -1,26 +0,0 @@
-# Go 1.14 is released
-25 Feb 2020
-Summary: Go 1.14 adds production-ready module support, faster defers, better goroutine preemption, and more.
-
-Alex Rakoczy
-
-##
-
-Today the Go team is very happy to announce the release of Go 1.14. You can get it from the [download page](https://golang.org/dl).
-
-Some of the highlights include:
-
-  - Module support in the `go` command is now ready for production use. We encourage all users to [migrate to `go` modules for dependency management](https://golang.org/doc/go1.14#introduction).
-  - [Embedding interfaces with overlapping method sets](https://golang.org/doc/go1.14#language)
-  - [Improved defer performance](https://golang.org/doc/go1.14#runtime)
-  - [Goroutines are asynchronously preemptible](https://golang.org/doc/go1.14#runtime)
-  - [The page allocator is more efficient](https://golang.org/doc/go1.14#runtime)
-  - [Internal timers are more efficient](https://golang.org/doc/go1.14#runtime)
-
-For the complete list of changes and more information about the improvements above, see the [**Go 1.14 release notes**](https://golang.org/doc/go1.14).
-
-We want to thank everyone who contributed to this release by writing code, filing bugs, providing feedback, and/or testing the beta and release candidate.
-Your contributions and diligence helped to ensure that Go 1.14 is as stable as possible.
-That said, if you notice any problems, please [file an issue](https://golang.org/issue/new).
-
-We hope you enjoy the new release!
diff --git a/_content/go1.15-proposals.article b/_content/go1.15-proposals.article
deleted file mode 100644
index 7b1e493..0000000
--- a/_content/go1.15-proposals.article
+++ /dev/null
@@ -1,115 +0,0 @@
-# Proposals for Go 1.15
-28 Jan 2020
-Tags: go1.15, proposals, community, language, vet
-Summary: For Go 1.15, we propose three minor language cleanup changes.
-
-Robert Griesemer, for the Go team
-gri@golang.org
-
-## Status
-
-We are close to the Go 1.14 release, planned for February assuming all goes
-well, with an RC1 candidate almost ready. Per the process outlined in the
-[Go 2, here we come!](https://blog.golang.org/go2-here-we-come) blog post,
-it is again the time in our development and release cycle to consider if and
-what language or library changes we might want to include for our next release,
-Go 1.15, scheduled for August of this year.
-
-The primary goals for Go remain package and version management, better error
-handling support, and generics. Module support is in good shape and getting
-better with each day, and we are also making progress on the generics front
-(more on that later this year). Our attempt seven months ago at providing a
-better error handling mechanism, the
-[`try` proposal](https://golang.org/issue/32437), met good support
-but also strong opposition and we decided to abandon it. In its aftermath there
-were many follow-up proposals, but none of them seemed convincing enough,
-clearly superior to the `try` proposal, or less likely to cause similar
-controversy. Thus, we have not further pursued changes to error handling
-for now. Perhaps some future insight will help us to improve upon the status
-quo.
-
-## Proposals
-
-Given that modules and generics are actively being worked on, and with error
-handling changes out of the way for the time being, what other changes should
-we pursue, if any? There are some perennial favorites such as requests for
-enums and immutable types, but none of those ideas are sufficiently developed
-yet, nor are they urgent enough to warrant a lot of attention by the Go team,
-especially when also considering the cost of making a language change.
-
-After reviewing all potentially viable proposals, and more importantly, because
-we don’t want to incrementally add new features without a long-term plan, we
-concluded that it is better to hold off with major changes this time. Instead
-we concentrate on a couple of new `vet` checks and a minor adjustment to the
-language. We have selected the following three proposals:
-
-[\#32479](https://golang.org/issue/32479).
-Diagnose `string(int)` conversion in `go vet`.
-
-We were planning to get this done for the upcoming Go 1.14 release but we didn’t
-get around to it, so here it is again. The `string(int)` conversion was introduced
-early in Go for convenience, but it is confusing to newcomers (`string(10)` is
-`"\n"` not `"10"`) and not justified anymore now that the conversion is available
-in the `unicode/utf8` package.
-Since [removing this conversion](https://golang.org/issue/3939) is
-not a backwards-compatible change, we propose to start with a `vet` error instead.
-
-[\#4483](https://golang.org/issue/4483).
-Diagnose impossible interface-interface type assertions in `go vet`.
-
-Currently, Go permits any type assertion `x.(T)` (and corresponding type switch case)
-where the type of `x` and `T` are interfaces. Yet, if both `x` and `T` have a method
-with the same name but different signatures it is impossible for any value assigned
-to `x` to also implement `T`; such type assertions will always fail at runtime
-(panic or evaluate to `false`). Since we know this at compile time, the compiler
-might as well report an error. Reporting a compiler error in this case is not a
-backwards-compatible change, thus we also propose to start with a `vet` error
-instead.
-
-[\#28591](https://golang.org/issue/28591).
-Constant-evaluate index and slice expressions with constant strings and indices.
-
-Currently, indexing or slicing a constant string with a constant index, or indices,
-produces a non-constant `byte` or `string` value, respectively. But if all operands
-are constant, the compiler can constant-evaluate such expressions and produce a
-constant (possibly untyped) result. This is a fully backward-compatible change
-and we propose to make the necessary adjustments to the spec and compilers.
-
-(Correction: We found out after posting that this change is not backward-compatible;
-see [comment](https://golang.org/issue/28591#issuecomment-579993684) for details.)
-
-## Timeline
-
-We believe that none of these three proposals are controversial but there’s
-always a chance that we missed something important. For that reason we plan
-to have the proposals implemented at the beginning of the Go 1.15 release cycle
-(at or shortly after the Go 1.14 release) so that there is plenty of time to
-gather experience and provide feedback. Per the
-[proposal evaluation process](https://blog.golang.org/go2-here-we-come),
-the final decision will be made at the end of the development cycle, at the
-beginning of May, 2020.
-
-## And one more thing...
-
-We receive many more language change proposals
-([issues labeled LanguageChange](https://github.com/golang/go/labels/LanguageChange))
-than we can review thoroughly. For instance, just for error handling alone,
-there are 57 issues, of which five are currently still open. Since the cost
-of making a language change, no matter how small, is high and the benefits
-are often unclear, we must err on the side of caution. Consequently, most
-language change proposals get rejected sooner or later, sometimes with minimal
-feedback. This is unsatisfactory for all parties involved. If you have spent a
-lot of time and effort outlining your idea in detail, it would be nice to not
-have it immediately rejected. On the flip side, because the general
-[proposal process](https://github.com/golang/proposal/blob/master/README.md)
-is deliberately simple, it is very easy to create language change proposals
-that are only marginally explored, causing the review committee significant
-amounts of work. To improve this experience for everybody we are adding a new
-[questionnaire](https://github.com/golang/proposal/blob/master/go2-language-changes.md)
-for language changes: filling out that template will help reviewers evaluate
-proposals more efficiently because they don’t need to try to answer those
-questions themselves. And hopefully it will also provide better guidance for
-proposers by setting expectations right from the start. This is an experiment
-that we will refine over time as needed.
-
-Thank you for helping us improve the Go experience!
diff --git a/_content/go1.15.article b/_content/go1.15.article
deleted file mode 100644
index 1f71528..0000000
--- a/_content/go1.15.article
+++ /dev/null
@@ -1,26 +0,0 @@
-# Go 1.15 is released
-11 Aug 2020
-Summary: Go 1.15 adds a new linker, X.509 changes, runtime improvements, compiler improvements, GOPROXY improvements, and more.
-
-Alex Rakoczy
-
-##
-
-Today the Go team is very happy to announce the release of Go 1.15. You can get it from the [download page](https://golang.org/dl).
-
-Some of the highlights include:
-
-  - [Substantial improvements to the Go linker](https://golang.org/doc/go1.15#linker)
-  - [Improved allocation for small objects at high core counts](https://golang.org/doc/go1.15#runtime)
-  - [X.509 CommonName deprecation](https://golang.org/doc/go1.15#commonname)
-  - [GOPROXY supports skipping proxies that return errors](https://golang.org/doc/go1.15#go-command)
-  - [New embedded tzdata package](https://golang.org/doc/go1.15#time/tzdata)
-  - [A number of Core Library improvements](https://golang.org/doc/go1.15#library)
-
-For the complete list of changes and more information about the improvements above, see the [**Go 1.15 release notes**](https://golang.org/doc/go1.15).
-
-We want to thank everyone who contributed to this release by writing code, filing bugs, providing feedback, and/or testing the beta and release candidates.
-Your contributions and diligence helped to ensure that Go 1.15 is as stable as possible.
-That said, if you notice any problems, please [file an issue](https://golang.org/issue/new).
-
-We hope you enjoy the new release!
diff --git a/_content/go1.16.article b/_content/go1.16.article
deleted file mode 100644
index d7b5323..0000000
--- a/_content/go1.16.article
+++ /dev/null
@@ -1,50 +0,0 @@
-# Go 1.16 is released
-16 Feb 2021
-Summary: Go 1.16 adds embedded files, Apple silicon support, and more.
-
-Matt Pearring
-
-Dmitri Shuralyov
-
-##
-
-Today the Go team is very happy to announce the release of Go 1.16.
-You can get it from the [download page](https://golang.org/dl/).
-
-The new
-[embed package](https://golang.org/doc/go1.16#library-embed)
-provides access to files embedded at compile time using the new `//go:embed` directive.
-Now it is easy to bundle supporting data files into your Go programs,
-making developing with Go even smoother.
-You can get started using the
-[embed package documentation](https://pkg.go.dev/embed).
-Carl Johnson has also written a nice tutorial,
-“[How to use Go embed](https://blog.carlmjohnson.net/post/2021/how-to-use-go-embed/)”.
-
-Go 1.16 also adds
-[macOS ARM64 support](https://golang.org/doc/go1.16#darwin)
-(also known as Apple silicon).
-Since Apple’s announcement of their new arm64 architecture, we have been working closely with them to ensure Go is fully supported; see our blog post
-“[Go on ARM and Beyond](https://blog.golang.org/ports)”
-for more.
-
-Note that Go 1.16
-[requires use of Go modules by default](https://golang.org/doc/go1.16#modules),
-now that, according to our 2020 Go Developer Survey,
-96% of Go developers have made the switch.
-We recently added official documentation for [developing and publishing modules](https://golang.org/doc/modules/developing).
-
-Finally, there are many other improvements and bug fixes,
-including builds that are up to 25% faster and use as much as 15% less memory.
-For the complete list of changes and more information about the improvements above,
-see the
-[Go 1.16 release notes](https://golang.org/doc/go1.16).
-
-We want to thank everyone who contributed to this release by writing code
-filing bugs, providing feedback, and testing the beta and release candidate.
-
-Your contributions and diligence helped to ensure that Go 1.16 is as stable as possible.
-That said, if you notice any problems, please
-[file an issue](https://golang.org/issue/new).
-
-We hope you enjoy the new release!
diff --git a/_content/go1.3.article b/_content/go1.3.article
deleted file mode 100644
index 9fb837a..0000000
--- a/_content/go1.3.article
+++ /dev/null
@@ -1,58 +0,0 @@
-# Go 1.3 is released
-18 Jun 2014
-Summary: Go 1.3 adds better performance, static analysis in godoc, and more.
-
-Andrew Gerrand
-
-##
-
-Today we are happy to announce the release of [Go 1.3](https://golang.org/doc/go1.3).
-This release comes six months after our last major release and provides better
-performance, improved tools, support for running Go in new environments, and more.
-All Go users should upgrade to Go 1.3.
-You can grab the release from our [downloads page](https://golang.org/dl/) and
-find the full list of improvements and fixes in the
-[release notes](https://golang.org/doc/go1.3).
-What follows are some highlights.
-
-[Godoc](https://godoc.org/code.google.com/p/go.tools/cmd/godoc),
-the Go documentation server, now performs static analysis.
-When enabled with the -analysis flag, analysis results are presented
-in both the source and package documentation views, making it easier
-than ever to navigate and understand Go programs.
-See [the documentation](https://golang.org/lib/godoc/analysis/help.html) for the details.
-
-The gc toolchain now supports the Native Client (NaCl) execution sandbox on the
-32- and 64-bit Intel architectures.
-This permits the safe execution of untrusted code, useful in environments such as the
-[Playground](https://blog.golang.org/playground).
-To set up NaCl on your system see the [NativeClient wiki page](https://golang.org/wiki/NativeClient).
-
-Also included in this release is experimental support for the DragonFly BSD,
-Plan 9, and Solaris operating systems. To use Go on these systems you must
-[install from source](https://golang.org/doc/install/source).
-
-Changes to the runtime have improved the
-[performance](https://golang.org/doc/go1.3#performance) of Go binaries,
-with an improved garbage collector, a new
-["contiguous" goroutine stack management strategy](https://golang.org/s/contigstacks),
-a faster race detector, and improvements to the regular expression engine.
-
-As part of the general [overhaul](https://golang.org/s/go13linker) of the Go
-linker, the compilers and linkers have been refactored. The instruction
-selection phase that was part of the linker has been moved to the compiler.
-This can speed up incremental builds for large projects.
-
-The [garbage collector](https://golang.org/doc/go1.3#garbage_collector) is now
-precise when examining stacks (collection of the heap has been precise since Go
-1.1), meaning that a non-pointer value such as an integer will never be
-mistaken for a pointer and prevent unused memory from being reclaimed. This
-change affects code that uses package unsafe; if you have unsafe code you
-should read the [release notes](https://golang.org/doc/go1.3#garbage_collector)
-carefully to see if your code needs updating.
-
-We would like to thank the many people who contributed to this release;
-it would not have been possible without your help.
-
-So, what are you waiting for?
-Head on over to the [downloads page](https://golang.org/dl/) and start hacking.
diff --git a/_content/go1.4.article b/_content/go1.4.article
deleted file mode 100644
index 85b4c0f..0000000
--- a/_content/go1.4.article
+++ /dev/null
@@ -1,65 +0,0 @@
-# Go 1.4 is released
-10 Dec 2014
-Summary: Go 1.4 adds support for Android, go generate, optimizations, and more.
-
-Andrew Gerrand
-adg@golang.org
-
-##
-
-Today we announce Go 1.4, the fifth major stable release of Go, arriving six
-months after our previous major release [Go 1.3](https://blog.golang.org/go1.3).
-It contains a small language change, support for more operating systems
-and processor architectures, and improvements to the tool chain and libraries.
-As always, Go 1.4 keeps the promise of compatibility, and almost everything
-will continue to compile and run without change when moved to 1.4.
-For the full details, see the [Go 1.4 release notes](https://golang.org/doc/go1.4).
-
-The most notable new feature in this release is official support for Android.
-Using the support in the core and the libraries in the
-[golang.org/x/mobile](https://godoc.org/golang.org/x/mobile) repository,
-it is now possible to write simple Android apps using only Go code.
-At this stage, the support libraries are still nascent and under heavy development.
-Early adopters should expect a bumpy ride, but we welcome the community to get involved.
-
-The language change is a tweak to the syntax of for-range loops.
-You may now write "for range s {" to loop over each item from s,
-without having to assign the value, loop index, or map key.
-See the [release notes](https://golang.org/doc/go1.4#forrange) for details.
-
-The go command has a new subcommand, go generate, to automate the running of
-tools to generate source code before compilation.
-For example, it can be used to automate the generation of String methods for
-typed constants using the
-[new stringer tool](https://godoc.org/golang.org/x/tools/cmd/stringer/).
-For more information, see the [design document](https://golang.org/s/go1.4-generate).
-
-Most programs will run about the same speed or slightly faster in 1.4 than in
-1.3; some will be slightly slower.
-There are many changes, making it hard to be precise about what to expect.
-See the [release notes](https://golang.org/doc/go1.4#performance) for more discussion.
-
-And, of course, there are many more improvements and bug fixes.
-
-In case you missed it, a few weeks ago the sub-repositories were moved to new locations.
-For example, the go.tools packages are now imported from "golang.org/x/tools".
-See the [announcement post](https://groups.google.com/d/msg/golang-announce/eD8dh3T9yyA/HDOEU_ZSmvAJ) for details.
-
-This release also coincides with the project's move from Mercurial to Git (for
-source control), Rietveld to Gerrit (for code review), and Google Code to
-Github (for issue tracking and wiki).
-The move affects the core Go repository and its sub-repositories.
-You can find the canonical Git repositories at
-[go.googlesource.com](https://go.googlesource.com),
-and the issue tracker and wiki at the
-[golang/go GitHub repo](https://github.com/golang/go).
-
-While development has already moved over to the new infrastructure,
-for the 1.4 release we still recommend that users who
-[install from source](https://golang.org/doc/install/source)
-use the Mercurial repositories.
-
-For App Engine users, Go 1.4 is now available for beta testing.
-See [the announcement](https://groups.google.com/d/msg/google-appengine-go/ndtQokV3oFo/25wV1W9JtywJ) for details.
-
-From all of us on the Go team, please enjoy Go 1.4, and have a happy holiday season.
diff --git a/_content/go1.5.article b/_content/go1.5.article
deleted file mode 100644
index 348eea8..0000000
--- a/_content/go1.5.article
+++ /dev/null
@@ -1,78 +0,0 @@
-# Go 1.5 is released
-19 Aug 2015
-Summary: Go 1.5 adds a new, much faster garbage collector, more parallelism by default, go tool trace, and more.
-
-Andrew Gerrand
-adg@golang.org
-
-##
-
-Today the Go project is proud to release Go 1.5,
-the sixth major stable release of Go.
-
-This release includes significant changes to the implementation.
-The compiler tool chain was [translated from C to Go](https://golang.org/doc/go1.5#c),
-removing the last vestiges of C code from the Go code base.
-The garbage collector was [completely redesigned](https://golang.org/doc/go1.5#gc),
-yielding a [dramatic reduction](https://talks.golang.org/2015/go-gc.pdf)
-in garbage collection pause times.
-Related improvements to the scheduler allowed us to change the default
-[GOMAXPROCS](https://golang.org/pkg/runtime/#GOMAXPROCS) value
-(the number of concurrently executing goroutines)
-from 1 to the number of logical CPUs.
-Changes to the linker enable distributing Go packages as shared libraries to
-link into Go programs, and building Go packages into archives or shared
-libraries that may be linked into or loaded by C programs
-([design doc](https://golang.org/s/execmodes)).
-
-The release also includes [improvements to the developer tools](https://golang.org/doc/go1.5#go_command).
-Support for ["internal" packages](https://golang.org/s/go14internal)
-permits sharing implementation details between packages.
-[Experimental support](https://golang.org/s/go15vendor) for "vendoring"
-external dependencies is a step toward a standard mechanism for managing
-dependencies in Go programs.
-The new "[go tool trace](https://golang.org/cmd/trace/)" command enables the
-visualisation of  program traces generated by new tracing infrastructure in the
-runtime.
-The new "[go doc](https://golang.org/cmd/go/#hdr-Show_documentation_for_package_or_symbol)"
-command provides an improved command-line interface for viewing Go package documentation.
-
-There are also several [new operating system and architecture ports](https://golang.org/doc/go1.5#ports).
-The more mature new ports are darwin/arm,
-darwin/arm64 (Apple's iPhone and iPad devices),
-and linux/arm64.
-There is also experimental support for ppc64 and ppc64le
-(IBM 64-bit PowerPC, big and little endian).
-
-The new darwin/arm64 port and external linking features fuel the
-[Go mobile project](https://godoc.org/golang.org/x/mobile), an experiment to
-see how Go might be used for building apps on Android and iOS devices.
-(The Go mobile work itself is not part of this release.)
-
-The only language change is very minor,
-[the lifting of a restriction in the map literal syntax](https://golang.org/doc/go1.5#language)
-to make them more succinct and consistent with slice literals.
-
-The standard library saw many additions and improvements, too.
-The flag package now shows [cleaner usage messages](https://golang.org/doc/go1.5#flag).
-The math/big package now provides a [Float](https://golang.org/pkg/math/big/#Float)
-type for computing with arbitrary-precision floating point numbers.
-An [improvement](https://golang.org/doc/go1.5#net) to the DNS resolver on
-Linux and BSD systems has removed the cgo requirement for programs that do name
-lookups.
-The [go/types](https://golang.org/pkg/go/types/) package has been
-[moved](https://golang.org/doc/go1.5#go_types) to the standard library from
-the [golang.org/x/tools](https://godoc.org/golang.org/x/tools) repository.
-(The new [go/constant](https://golang.org/pkg/go/constant/) and
-[go/importer](https://golang.org/pkg/go/importer/) packages are also a result
-of this move.)
-The reflect package has added the
-[ArrayOf](https://golang.org/pkg/reflect/#ArrayOf) and
-[FuncOf](https://golang.org/pkg/reflect/#FuncOf) functions, analogous to the
-existing [SliceOf](https://golang.org/pkg/reflect/#SliceOf) function.
-And, of course, there is the usual
-[list of smaller fixes and improvements](https://golang.org/doc/go1.5#minor_library_changes).
-
-For the full story, see the [detailed release notes](https://golang.org/doc/go1.5).
-Or if you just can't wait to get started,
-head over to the [downloads page](https://golang.org/dl/) to get Go 1.5 now.
diff --git a/_content/go1.6.article b/_content/go1.6.article
deleted file mode 100644
index 6c5afeb..0000000
--- a/_content/go1.6.article
+++ /dev/null
@@ -1,92 +0,0 @@
-# Go 1.6 is released
-17 Feb 2016
-Summary: Go 1.6 adds HTTP/2, template blocks, and more.
-
-Andrew Gerrand
-adg@golang.org
-
-##
-
-Today we release [Go version 1.6](https://golang.org/doc/go1.6),
-the seventh major stable release of Go.
-You can grab it right now from the [download page](https://golang.org/dl/).
-Although [the release of Go 1.5](https://blog.golang.org/go1.5) six months ago
-contained dramatic implementation changes,
-this release is more incremental.
-
-The most significant change is support for [HTTP/2](https://http2.github.io/)
-in the [net/http package](https://golang.org/pkg/net/http/).
-HTTP/2 is a new protocol, a follow-on to HTTP that has already seen
-widespread adoption by browser vendors and major websites.
-In Go 1.6, support for HTTP/2 is [enabled by default](https://golang.org/doc/go1.6#http2)
-for both servers and clients when using HTTPS,
-bringing [the benefits](https://http2.github.io/faq/) of the new protocol
-to a wide range of Go projects,
-such as the popular [Caddy web server](https://caddyserver.com/download).
-
-The template packages have learned some new tricks,
-with support for [trimming spaces around template actions](https://golang.org/pkg/text/template/#hdr-Text_and_spaces)
-to produce cleaner template output,
-and the introduction of the [`{{block}}` action](https://golang.org/pkg/text/template/#hdr-Actions)
-that can be used to create templates that build on other templates.
-A [new template example program](https://github.com/golang/example/tree/master#template-godoc) demonstrates these new features.
-
-Go 1.5 introduced [experimental support](https://golang.org/s/go15vendor)
-for a “vendor” directory that was enabled by an environment variable.
-In Go 1.6, the feature is now [enabled by default](https://golang.org/doc/go1.6#go_command).
-Source trees that contain a directory named “vendor” that is not used in accordance with the new feature
-will require changes to avoid broken builds (the simplest fix is to rename the directory).
-
-The runtime has added lightweight, best-effort detection of concurrent misuse of maps.
-As always, if one goroutine is writing to a map, no other goroutine should be reading or writing the map concurrently.
-If the runtime detects this condition, it prints a diagnosis and crashes the program.
-The best way to find out more about the problem is to run it under the
-[race detector](https://blog.golang.org/race-detector),
-which will more reliably identify the race and give more detail.
-
-The runtime has also changed how it prints program-ending panics.
-It now prints only the stack of the panicking goroutine, rather than all existing goroutines.
-This behavior can be configured using the
-[GOTRACEBACK](https://golang.org/pkg/runtime/#hdr-Environment_Variables) environment variable
-or by calling the [debug.SetTraceback](https://golang.org/pkg/runtime/debug/#SetTraceback) function.
-
-Users of cgo should be aware of major changes to the rules for sharing pointers between Go and C code.
-The rules are designed to ensure that such C code can coexist with Go's garbage collector
-and are checked during program execution, so code may require changes to avoid crashes.
-See the [release notes](https://golang.org/doc/go1.6#cgo) and
-[cgo documentation](https://golang.org/cmd/cgo/#hdr-Passing_pointers) for the details.
-
-The compiler, linker, and go command have a new `-msan` flag
-analogous to `-race` and only available on linux/amd64,
-that enables interoperation with the
-[Clang MemorySanitizer](http://clang.llvm.org/docs/MemorySanitizer.html).
-This is useful for testing a program containing suspect C or C++ code.
-You might like to try it while testing your cgo code with the new pointer rules.
-
-Performance of Go programs built with Go 1.6 remains similar to those built with Go 1.5.
-Garbage-collection pauses are even lower than with Go 1.5,
-but this is particularly noticeable for programs using large amounts of memory.
-With regard to the performance of the compiler tool chain,
-build times should be similar to those of Go 1.5.
-
-The algorithm inside [sort.Sort](https://golang.org/pkg/sort/#Sort)
-was improved to run about 10% faster,
-but the change may break programs that expect a specific ordering
-of equal but distinguishable elements.
-Such programs should refine their `Less` methods to indicate the desired ordering
-or use [sort.Stable](https://golang.org/pkg/sort/#Stable)
-to preserve the input order for equal values.
-
-And, of course, there are many more additions, improvements, and fixes.
-You can find them all in the comprehensive [release notes](https://golang.org/doc/go1.6).
-
-To celebrate the release,
-[Go User Groups around the world](https://github.com/golang/go/wiki/Go-1.6-release-party)
-are holding release parties on the 17th of February.
-Online, the Go contributors are hosting a question and answer session
-on the [golang subreddit](https://reddit.com/r/golang) for the next 24 hours.
-If you have questions about the project, the release, or just Go in general,
-then please [join the discussion](https://www.reddit.com/r/golang/comments/46bd5h/ama_we_are_the_go_contributors_ask_us_anything/).
-
-Thanks to everyone that contributed to the release.
-Happy hacking.
diff --git a/_content/go1.7-binary-size.article b/_content/go1.7-binary-size.article
deleted file mode 100644
index b920d86..0000000
--- a/_content/go1.7-binary-size.article
+++ /dev/null
@@ -1,124 +0,0 @@
-# Smaller Go 1.7 binaries
-18 Aug 2016
-Summary: Go 1.7 includes some binary size reductions important for small devices.
-
-David Crawshaw
-crawshaw@golang.org
-
-## Introduction
-
-Go was designed for writing servers.
-That is how it is most widely used today, and as a result a lot of
-work on the runtime and compiler is focused on issues that matter to
-servers: latency, ease of deployment, precise garbage collection,
-fast startup time, performance.
-
-As Go gets used for a wider variety of programs, there are new issues that must be considered.
-One of these is binary size.
-It has been on the radar for a long time
-(issue [\#6853](https://golang.org/issue/6853) was filed over two
-years ago), but the growing interest in using Go for
-deploying binaries on smaller devices — such as the Raspberry Pi or
-mobile devices — means it received some attention for the Go 1.7
-release.
-
-## Work done in Go 1.7
-
-Three significant changes in Go 1.7 affect binary size.
-
-The first is the new SSA backend that was enabled for AMD64 in this release.
-While the primary motivation for SSA was improved performance, the
-better generated code is also smaller.
-The SSA backend shrinks Go binaries by ~5%.
-We expect larger gains for the more RISC-like architectures
-like ARM and MIPS when those backends have been converted to SSA in Go 1.8.
-
-The second change is method pruning.
-Until 1.6, all methods on all used types were kept, even if some of
-the methods were never called.
-This is because they might be called through an interface, or called
-dynamically using the reflect package.
-Now the compiler discards any unexported methods that do not match an
-interface.
-Similarly the linker can discard other exported methods, those that are only
-accessible through reflection, if the corresponding
-[reflection features](https://golang.org/pkg/reflect/#Value.Call)
-are not used anywhere in the program.
-That change shrinks binaries by 5–20%.
-
-The third change is a more compact format for run-time type
-information used by the reflect package.
-The encoding format was originally designed to make the decoder in
-the runtime and reflect packages as simple as possible. By making this
-code a bit harder to read we can compress the format without affecting
-the run-time performance of Go programs.
-The new format shrinks Go binaries by a further 5–15%.
-Libraries built for Android and archives built for iOS shrink further
-as the new format contains fewer pointers, each of which requires
-dynamic relocations in position independent code.
-
-In addition, there were many small improvements such as improved
-interface data layout, better static data layout, and simplified
-dependencies. For example, the HTTP client no longer links in the entire HTTP
-server.
-The full list of changes can be found in issue
-[\#6853](https://golang.org/issue/6853).
-
-## Results
-
-Typical programs, ranging from tiny toys to large production programs,
-are about 30% smaller when built with Go 1.7.
-
-The canonical hello world program goes from 2.3MB to 1.6MB:
-
-	package main
-
-	import "fmt"
-
-	func main() {
-		fmt.Println("Hello, World!")
-	}
-
-When compiled without debugging information the statically
-linked binary is now under a megabyte.
-
-.image go1.7-binary-size/graph.png
-
-A large production program used for testing this cycle, `jujud`, went from 94MB
-to 67MB.
-
-Position-independent binaries are 50% smaller.
-
-In a position-independent executable (PIE), a pointer in a read-only
-data section requires a dynamic relocation.
-Because the new format for type information replaces pointers by
-section offsets, it saves 28 bytes per pointer.
-
-Position-independent executables with debugging information removed
-are particularly important to mobile developers, as this is the kind
-of program shipped to phones.
-Big downloads make for a poor user experience, so the reduction here
-is good news.
-
-## Future Work
-
-Several changes to the run-time type information were too late for the
-Go 1.7 freeze, but will hopefully make it into 1.8, further shrinking
-programs, especially position-independent ones.
-
-These changes are all conservative, reducing binary size without increasing
-build time, startup time, overall execution time, or memory usage.
-We could take more radical steps to reduce binary size: the
-[upx](http://upx.sourceforge.net/) tool for compressing executables
-shrinks binaries by another 50% at the cost of increased startup time
-and potentially increased memory use.
-For extremely small systems (the kind that might live on a keychain)
-we could build a version of Go without reflection, though it is
-unclear whether such a restricted language would be sufficiently
-useful.
-For some algorithms in the runtime we could use slower but more
-compact implementations when every kilobyte counts.
-All of these call for more research in later development cycles.
-
-To the many contributors who helped make Go 1.7 binaries smaller,
-thank you!
diff --git a/_content/go1.7-binary-size/graph.png b/_content/go1.7-binary-size/graph.png
deleted file mode 100644
index 82af84b..0000000
--- a/_content/go1.7-binary-size/graph.png
+++ /dev/null
Binary files differ
diff --git a/_content/go1.7.article b/_content/go1.7.article
deleted file mode 100644
index f9ddae0..0000000
--- a/_content/go1.7.article
+++ /dev/null
@@ -1,64 +0,0 @@
-# Go 1.7 is released
-15 Aug 2016
-Summary: Go 1.7 adds faster x86 compiled code, context in the standard library, and more.
-
-Chris Broadfoot
-cbro@golang.org
-
-##
-
-Today we are happy to announce the release of Go 1.7.
-You can get it from the [download page](https://golang.org/dl/).
-There are several significant changes in this release: a port for
-[Linux on IBM z Systems](https://en.wikipedia.org/wiki/IBM_System_z) (s390x),
-compiler improvements, the addition of the [context](https://golang.org/pkg/context/) package,
-and support for [hierarchical tests and benchmarks](https://golang.org/pkg/testing/#hdr-Subtests_and_Sub_benchmarks).
-
-A new compiler back end, based on [static single-assignment](https://en.wikipedia.org/wiki/Static_single_assignment_form) form (SSA),
-has been under development for the past year.
-By representing a program in SSA form, a compiler may perform advanced optimizations more easily.
-This new back end generates more compact, more efficient code that includes
-optimizations like
-[bounds check elimination](https://en.wikipedia.org/wiki/Bounds-checking_elimination) and
-[common subexpression elimination](https://en.wikipedia.org/wiki/Common_subexpression_elimination).
-We observed a 5–35% speedup across our [benchmarks](https://golang.org/test/bench/go1/).
-For now, the new backend is only available for the 64-bit x86 platform ("amd64"),
-but we’re planning to convert more architecture backends to SSA in future releases.
-
-The compiler front end uses a new, more compact export data format, and
-processes import declarations more efficiently.
-While these [changes across the compiler toolchain](https://golang.org/doc/go1.7#compiler) are mostly invisible,
-users have [observed](http://dave.cheney.net/2016/04/02/go-1-7-toolchain-improvements)
-a significant speedup in compile time and a reduction in binary size by as much as 20–30%.
-
-Programs should run a bit faster due to speedups in the garbage collector and optimizations in the standard library.
-Programs with many idle goroutines will experience much shorter garbage collection pauses than in Go 1.6.
-
-Over the past few years, the [golang.org/x/net/context](https://godoc.org/golang.org/x/net/context/)
-package has proven to be essential to many Go applications.
-Contexts are used to great effect in applications related to networking, infrastructure, and microservices
-(such as [Kubernetes](http://kubernetes.io/) and [Docker](https://www.docker.com/)).
-They make it easy to enable cancelation, timeouts, and passing request-scoped data.
-To make use of contexts within the standard library and to encourage more extensive use,
-the package has been moved from the [x/net](https://godoc.org/golang.org/x/net/context/) repository
-to the standard library as the [context](https://golang.org/pkg/context/) package.
-Support for contexts has been added to the
-[net](https://golang.org/pkg/net/),
-[net/http](https://golang.org/pkg/net/http/), and
-[os/exec](https://golang.org/pkg/os/exec/) packages.
-For more information about contexts, see the [package documentation](https://golang.org/pkg/context)
-and the Go blog post [_Go Concurrency Patterns: Context_](https://blog.golang.org/context).
-
-Go 1.5 introduced experimental support for a ["vendor" directory](https://golang.org/cmd/go/#hdr-Vendor_Directories),
-enabled by the `GO15VENDOREXPERIMENT` environment variable.
-Go 1.6 enabled this behavior by default, and in Go 1.7, this switch has been removed and the "vendor" behavior is always enabled.
-
-Go 1.7 includes many more additions, improvements, and fixes.
-Find the complete set of changes, and details of the points above, in the
-[Go 1.7 release notes](https://golang.org/doc/go1.7.html).
-
-Finally, the Go team would like thank everyone who contributed to the release.
-170 people contributed to this release, including 140 from the Go community.
-These contributions ranged from changes to the compiler and linker, to the standard library, to documentation, and code reviews.
-We welcome contributions; if you'd like to get involved, check out the
-[contribution guidelines](https://golang.org/doc/contribute.html).
diff --git a/_content/go1.8.article b/_content/go1.8.article
deleted file mode 100644
index c6e5451..0000000
--- a/_content/go1.8.article
+++ /dev/null
@@ -1,49 +0,0 @@
-# Go 1.8 is released
-16 Feb 2017
-Summary: Go 1.8 adds faster non-x86 compiled code, sub-millisecond garbage collection pauses, HTTP/2 push, and more.
-
-Chris Broadfoot
-cbro@golang.org
-
-##
-
-Today the Go team is happy to announce the release of Go 1.8.
-You can get it from the [download page](https://golang.org/dl/).
-There are significant performance improvements and changes across the standard library.
-
-The compiler back end introduced in [Go 1.7](https://blog.golang.org/go1.7) for 64-bit x86 is now used
-on all architectures, and those architectures should see significant [performance improvements](https://golang.org/doc/go1.8#compiler).
-For instance, the CPU time required by our benchmark programs was reduced by 20-30% on 32-bit ARM systems.
-There are also some modest performance improvements in this release for 64-bit x86 systems.
-The compiler and linker have been made faster.
-Compile times should be improved by about 15% over Go 1.7.
-There is still more work to be done in this area: expect faster compilation speeds in future releases.
-
-Garbage collection pauses should be [significantly shorter](https://golang.org/doc/go1.8#gc),
-usually under 100 microseconds and often as low as 10 microseconds.