Ian Lance Taylor
12 January 2021
We’ve filed a Go language change
proposal to add support for type
parameters for types and functions, permitting a form of generic
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.
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 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 described in an
earlier blog post.
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.
The language change proposal process
is how we make changes to the Go language.
We have now started this process
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.
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.
17 December 2020
The industry is abuzz about non-x86 processors recently,
so we thought it would be worth a brief post about Go’s support for them.
It has always been important to us for Go to be portable,
not overfitting to any particular operating system or architecture.
The initial open source release of Go
included support for two operating systems (Linux and Mac OS X) and three
architectures (64-bit x86,
32-bit x86, and 32-bit ARM).
Over the years, we’ve added support for many more operating systems and architecture combinations:
Although the x86-64 port got most of the attention in the early days of Go,
today all our target architectures are well supported by our SSA-based compiler back end
and produce excellent code.
We’ve been helped along the way by many contributors,
including engineers from Amazon, ARM, Atos,
IBM, Intel, and MIPS.
Go supports cross-compiling for all these systems out of the box with minimal effort.
For example, to build an app for 32-bit x86-based Windows from a 64-bit Linux system:
GOARCH=386 GOOS=windows go build myapp # writes myapp.exe
In the past year, several major vendors have made announcements of new ARM64
hardware for servers,
laptops and developer machines.
Go was well-positioned for this. For years now,
Go has been powering Docker, Kubernetes, and the rest of the Go ecosystem
on ARM64 Linux servers,
as well as mobile apps on ARM64 Android and iOS devices.
Since Apple’s announcement of the Mac transitioning to Apple silicon this summer,
Apple and Google have been working together to ensure that Go and the broader
Go ecosystem work well on them,
both running Go x86 binaries under Rosetta 2 and running native Go ARM64 binaries.
Earlier this week, we released the first Go 1.16 beta,
which includes native support for Macs using the M1 chip.
You can download and try the Go 1.16 beta for M1 Macs and all your other
systems on the Go download page.
(Of course, this is a beta release and, like all betas,
it certainly has bugs we don’t know about.
If you run into any problems, please report them at golang.org/issue/new.)
It’s always nice to use the same CPU architecture for local development as in production,
to remove one variation between the two environments.
If you deploy to ARM64 production servers,
Go makes it easy to develop on ARM64 Linux and Mac systems too.
But of course, it’s still as easy as ever to work on one system and cross-compile
for deployment to another,
whether you’re working on an x86 system and deploying to ARM,
working on Windows and deploying to Linux,
or some other combination.
The next target we’d like to add support for is ARM64 Windows 10 systems.
If you have expertise and would like to help,
we’re coordinating work on golang.org/issue/36439.
15 December 2020
With the introduction of Go modules and the growth of the Go ecosystem,
launched in 2019 to provide a central place
where developers can discover and evaluate Go packages and modules. Like
godoc.org, pkg.go.dev serves Go documentation, but it also supports modules,
better search functionality, and signals to help Go users to find the right
As we shared in January 2020, our
goal is to eventually redirect traffic from godoc.org to the corresponding page
on pkg.go.dev. We’ve also made it possible for users to opt in to redirecting
their own requests from godoc.org to pkg.go.dev.
We’ve received a lot of great feedback this year, which has been tracked and
resolved through the
milestones on the Go issue tracker. Your feedback resulted in support for
popular feature requests on pkg.go.dev,
open sourcing pkgsite, and most recently, a
redesign of pkg.go.dev.
The next step in this migration is to redirect all requests from godoc.org to
the corresponding page on pkg.go.dev.
This will happen in early 2021, once the work tracked at the
During this migration, updates will be posted to
Go issue 43178.
We encourage everyone to begin using pkg.go.dev today. You can do so by
visiting godoc.org?redirect=on, or clicking
“Always use pkg.go.dev” in the top right corner of any godoc.org page.
Will godoc.org URLs continue to work?
Yes! We will redirect all requests arriving at godoc.org to the equivalent page
on pkg.go.dev, so all your bookmarks and links will continue to take you to the
documentation you need.
What will happen to the golang/gddo repository?
The gddo repository will remain available
for anyone who wants to keep running it themselves, or even fork and improve
it. We will mark it archived to make clear that we will no longer accept
contributions. However, you will be able to continue forking the repository.
Will api.godoc.org continue to work?
This transition will have no impact on api.godoc.org. Until an API is available
for pkg.go.dev, api.godoc.org will continue to serve traffic. See
Go issue 36785 for updates on an API for
Will my godoc.org badges keep working?
Yes! Badge URLs will redirect to the equivalent URL on pkg.go.dev too. Your
page will automatically get a new pkg.go.dev badge. You can also generate a new
badge at pkg.go.dev/badge if you would like to
update your badge link.
As always, feel free to file an issue
on the Go issue tracker for any feedback.
Pkg.go.dev is an open source project. If
you’re interested in contributing to the pkgsite project, check out the
or join the
#pkgsite channel on Gophers Slack
to learn more.
Russ Cox, for the Go team
10 November 2020
Today we celebrate the eleventh birthday of the Go open source release.
The parties we had for
Go turning 10
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
shortly after Go’s 10th birthday.
In February, the Go 1.14 release
delivered the first officially “production-ready” implementation of Go modules,
along with many performance improvements,
non-cooperative goroutine preemption
to reduce scheduling
and garbage collection latency.
In early March, we launched a
new API for protocol buffers,
with much-improved support for protocol buffer reflection and custom messages.
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
to support contact tracing efforts all over the world.
In May, that group launched the
reference backend server,
written in Go.
We continued to improve gopls,
which enables advanced
in many editors.
In June, the
VSCode Go extension officially joined the Go project
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
as part of the Go project as well.
Later in June, we
released the latest design draft for generics,
along with a prototype tool and generics playground.
In July, we published and discussed three new design drafts for future changes:
new //go:build lines for file selection,
file system interfaces,
build-time file embedding.
(We’ll see all of those in 2021, as noted below.)
In August, the Go 1.15 release
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.
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
(videos at the link).
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
Mark your calendars!
In February, the Go 1.16 release will include the new
file system interfaces
build-time file embedding.
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,
which are far less error-prone than the
current // +build lines.
Another highly anticipated feature we hope will be ready for beta testing next year
support for fuzzing in the go test command.
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
for details about this final step in the journey from GOPATH to modules.)
From the start, the goal for Go modules
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
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
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
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
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
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,
redesign launching today.
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.
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.
The next feature on everyone’s minds is of course generics.
As we mentioned above, we published the
latest design draft for generics
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.
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.
We hope you are all staying safe and wish you all the best.
10 November 2020
Since launching pkg.go.dev, we’ve received a lot of great
feedback on design and usability.
In particular, it was clear that the way information was organized confused
users when navigating the site.
Today we’re excited to share a redesigned pkg.go.dev,
which we hope will be clearer and more helpful.
This blog post presents the highlights. For details,
see Go issue 41585.
The main change is that the pkg.go.dev/<path> page has been reorganized
around the idea of a path.
A path represents a directory in a particular version of a module.
Now, regardless of what’s in that directory,
every path page will have the same layout,
with the goal of making the experience consistently useful and predictable.
The path page will display the README at that path if there is one.
Previously, the overview tab only showed the README if present at the module root.
This is one of many changes we’re making to place the most important information up front.
The documentation section now displays an index along with a sidenav.
This gives the ability to see the full package API,
while having context as they are navigating the documentation section.
There is also a new Jump To input box in the left sidenav,
to search for identifiers.
See Go issue 41587 for details on changes in the documentation section.
The top bar on each page now shows additional metadata,
such as each package’s “imports” and “imported by” counts.
Banners also show information about the latest minor and major versions of a module.
See Go issue 41588 for details.
Last week at Google Open Source Live,
we presented a walkthrough of the new site experience in our talk,
Level Up: Go Package Discovery and Editor Tooling.
We’re excited to share this updated design with you.
As always, please let us know what you think via the “Share Feedback”
and “Report an Issue” links at the bottom of every page of the site.
And if you’re interested in contributing to this project, pkg.go.dev is open source! Check out the
to find out more.
See the index for more articles.