Black Lives Matter. Support the Equal Justice Initiative.

The Go Blog

A Proposal for Adding Generics to Go

Ian Lance Taylor
12 January 2021

Generics proposal

We’ve filed a Go language change proposal 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.

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 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 described in an earlier blog post. Ian Lance Taylor gave a talk at GopherCon 2019 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. 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 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 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.

Go on ARM and Beyond

Russ Cox
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:

  • Go 1 (March 2012) supported the original systems as well as FreeBSD, NetBSD, and OpenBSD on 64-bit and 32-bit x86, and Plan 9 on 32-bit x86.
  • Go 1.3 (June 2014) added support for Solaris on 64-bit x86.
  • Go 1.4 (December 2014) added support for Android on 32-bit ARM and Plan 9 on 64-bit x86.
  • Go 1.5 (August 2015) added support for Linux on 64-bit ARM and 64-bit PowerPC, as well as iOS on 32-bit and 64-bit ARM.
  • Go 1.6 (February 2016) added support for Linux on 64-bit MIPS, as well as Android on 32-bit x86. It also added an official binary download for Linux on 32-bit ARM, primarily for Raspberry Pi systems.
  • Go 1.7 (August 2016) added support for Linux on z Systems (S390x) and Plan 9 on 32-bit ARM.
  • Go 1.8 (February 2017) added support for Linux on 32-bit MIPS, and it added official binary downloads for Linux on 64-bit PowerPC and z Systems.
  • Go 1.9 (August 2017) added official binary downloads for Linux on 64-bit ARM.
  • Go 1.12 (February 2018) added support for Windows 10 IoT Core on 32-bit ARM, such as the Raspberry Pi 3. It also added support for AIX on 64-bit PowerPC.
  • Go 1.14 (February 2019) added support for Linux on 64-bit RISC-V.

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.

Redirecting godoc.org requests to pkg.go.dev

Julie Qiu
15 December 2020

With the introduction of Go modules and the growth of the Go ecosystem, pkg.go.dev was 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 packages.

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 pkgsite/godoc.org-redirect and pkgsite/design-2020 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.

Next Steps

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 pkgsite/godoc.org-redirect milestone is complete.

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.

FAQs

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 pkg.go.dev.

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.

Feedback

As always, feel free to file an issue on the Go issue tracker for any feedback.

Contributing

Pkg.go.dev is an open source project. If you’re interested in contributing to the pkgsite project, check out the contribution guidelines or join the #pkgsite channel on Gophers Slack to learn more.

Eleven Years of Go

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, including faster defers and non-cooperative goroutine preemption to reduce scheduling and garbage collection latency.

In early March, we launched a new API for protocol buffers, google.golang.org/protobuf, 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 Go-aware support 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, and 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).

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. Mark your calendars!

Go Releases

In February, the Go 1.16 release will include the new file system interfaces and 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 is support for fuzzing in the go test command.

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 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 (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 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 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. 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.

Generics

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.

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.

Pkg.go.dev has a new look!

Julie Qiu
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.

Consistent landing page for all paths

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.

Landing page for cloud.google.com/go/storage
Fig 1. Landing page for https://pkg.go.dev/cloud.google.com/go/storage.

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.

Documentation navigation

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.

Jump To feature navigating net/http
Fig 2. Jump To feature on https://pkg.go.dev/net/http.

See Go issue 41587 for details on changes in the documentation section.

Metadata on main page

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.

Header metadata for github.com/russross/blackfriday
Fig 3. Header metadata for https://pkg.go.dev/github.com/russross/blackfriday.

Video Walkthrough

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.

Feedback

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 contribution guidelines to find out more.

See the index for more articles.