The Go Blog

Go 1.14 is released

Alex Rakoczy
25 February 2020

Today the Go team is very happy to announce the release of Go 1.14. You can get it from the download page.

Some of the highlights include:

For the complete list of changes and more information about the improvements above, see the Go 1.14 release notes.

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.

We hope you enjoy the new release!

Next steps for pkg.go.dev

Julie Qiu
31 January 2020

Introduction

In 2019, we launched go.dev, a new hub for Go developers.

As part of the site, we also launched pkg.go.dev, a central source of information about Go packages and modules. Like godoc.org, pkg.go.dev serves Go documentation. However, it also understands modules and has information about past versions of a package!

Throughout this year, we will be adding features to pkg.go.dev to help our users better understand their dependencies and help them make better decisions around what libraries to import.

Redirecting godoc.org requests to pkg.go.dev

To minimize confusion about which site to use, later this year we are planning to redirect traffic from godoc.org to the corresponding page on pkg.go.dev. We need your help to ensure that pkg.go.dev addresses all of our users' needs. We encourage everyone to begin using pkg.go.dev today for all of their needs and provide feedback.

Your feedback will inform our transition plan, with the goal of making pkg.go.dev our primary source of information and documentation for packages and modules. We’re sure there are things that you want to see on pkg.go.dev, and we want to hear from you about what those features are!

You can share your feedback with us on these channels:

As part of this transition, we will also be discussing plans for API access to pkg.go.dev. We will be posting updates on Go issue 33654.

Frequently asked questions

Since our launch in November, we’ve received tons of great feedback about pkg.go.dev from Go users. For the remainder of this post, we thought it would be helpful to answer some frequently asked questions.

My package doesn’t show up on pkg.go.dev! How do I add it?

We monitor the Go Module Index regularly for new packages to add to pkg.go.dev. If you don’t see a package on pkg.go.dev, you can add it by fetching the module version from proxy.golang.org. See go.dev/about for instructions.

My package has license restrictions. What’s wrong with it?

We understand it can be a frustrating experience to not be able to see the package you want in its entirety on pkg.go.dev. We appreciate your patience as we improve our license detection algorithm.

Since our launch in November, we've made the following improvements:

  • Updated our license policy to include the list of licenses that we detect and recognize
  • Worked with the licensecheck team to improve detection for copyright notices
  • Established a manual review process for special cases

As always, our license policy is at pkg.go.dev/license-policy. If you are having issues, feel free to file an issue on the Go issue tracker, or email go-discovery-feedback@google.com so that we can work with you directly!

Will pkg.go.dev be open-sourced so I can run it at work for my private code?

We understand that corporations with private code want to run a documentation server that provides module support. We want to help meet that need, but we feel we don’t yet understand it as well as we need to.

We’ve heard from users that running the godoc.org server is more complex than it should be, because it is designed for serving at public internet scale instead of just within a company. We believe the current pkg.go.dev server would have the same problem.

We think a new server is more likely to be the right answer for use with private code, instead of exposing every company to the complexity of running the internet-scale pkg.go.dev codebase. In addition to serving documentation, a new server could also serve information to goimports and gopls.

If you want to run such a server, please fill out this 3-5 minute survey to help us better understand your needs. This survey will be available until March 1st, 2020.

We’re excited about the future of pkg.go.dev in 2020, and we hope you are too! We look forward to hearing your feedback and working with the Go community on this transition.

Proposals for Go 1.15

Robert Griesemer, for the Go team
28 January 2020

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! 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, 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. 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 is not a backwards-compatible change, we propose to start with a vet error instead.

#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. 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 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, 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) 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 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 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!

Announcing the 2019 Go Developer Survey

Todd Kulesza
20 November 2019

Help shape the future of Go

Since 2016, thousands of Gophers around the world have helped the Go project by sharing your thoughts via our annual Go Developer Survey. Your feedback has played an enormous role in driving changes to our language, ecosystem, and community, including the gopls language server, new error-handling mechanics, the module mirror, and so much more from the latest Go 1.13 release. And of course, we publicly share each year's results, so we can all benefit from the community's insights.

Today we are launching the 2019 Go Developer Survey. We'd love to hear from everyone who uses Go, used to use Go, or is interested in using Go, to help ensure the language, community, and ecosystem fit the needs of the people closest to it. Please help us shape Go's future by participating in this 15-minute survey by December 15th: Take the 2019 Go Developer Survey.

Spread the word!

We need as many Gophers as possible to participate in this survey to help us better understand our global user base. We'd be grateful if you would spread the word by sharing this post on your social network feeds, around the office, at meet-ups, and in other communities. Thank you!

Go.dev: a new hub for Go developers

Steve Francia and Julie Qiu
13 November 2019

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

(Note that 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, a central source of information about Go packages and modules. Like 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! And it detects and displays licenses and has a better search algorithm. You can follow Go issue 33654 for future developments.

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.

See the index for more articles.