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!
31 January 2020
In 2019, we launched go.dev, a new hub for Go
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
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.
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.
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
go.dev/about for instructions.
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:
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
so that we can work with you directly!
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
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.
Robert Griesemer, for the Go team
28 January 2020
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
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:
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.
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
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.)
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.
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
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
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!
20 November 2019
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.
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!
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
See the index for more articles.