content: generics-proposal: new blog post
Trust: Ian Lance Taylor <email@example.com>
Reviewed-by: Ian Lance Taylor <firstname.lastname@example.org>
diff --git a/content/generics-proposal.article b/content/generics-proposal.article
new file mode 100644
@@ -0,0 +1,79 @@
+# 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
+## 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
+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
+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
+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/NNNNN)
+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
+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.