content: add go2-next-steps.article

Change-Id: I697ab189ecf305f973072468e8b57f8315be28be
Reviewed-on: https://go-review.googlesource.com/c/blog/+/183921
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Andrew Bonventre <andybons@golang.org>

1 files changed, 153 insertions, 0 deletions

diff --git a/content/go2-next-steps.article b/content/go2-next-steps.article
new file mode 100644
index 0000000..07f6abe
--- /dev/null
+++ b/content/go2-next-steps.article
@@ -0,0 +1,153 @@
+Next steps toward Go 2
+26 Jun 2019
+Tags: go2, proposals, community
+
+Robert Griesemer, for the Go team
+
+* Status
+
+We’re well on the way towards the release of Go 1.13,
+hopefully in early August of this year.
+This is the first release that will include concrete changes
+to the language (rather than just minor adjustments to the spec),
+after a longer moratorium on any such changes.
+
+To arrive at these language changes,
+we started out with a small set of viable proposals,
+selected from the much larger list of
+[[https://github.com/golang/go/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+label%3AGo2+label%3AProposal][Go 2 proposals]],
+per the new proposal evaluation process outlined
+in the
+“[[https://blog.golang.org/go2-here-we-come][Go 2, here we come!]]” blog post.
+We wanted our initial selection of proposals
+to be relatively minor and mostly uncontroversial,
+to have a reasonably high chance of having them
+make it through the process.
+The proposed changes had to be backward-compatible
+to be minimally disruptive since
+[[https://blog.golang.org/using-go-modules][modules]],
+which eventually will allow module-specific language version selection,
+are not the default build mode quite yet.
+In short, this initial round of changes was more about
+getting the ball rolling again and gaining experience
+with the new process, rather than tackling big issues.
+
+Our
+[[https://blog.golang.org/go2-here-we-come][original list of proposals]] –
+[[https://golang.org/issue/20706][general Unicode identifiers]],
+[[https://golang.org/issue/19308][binary integer literals]],
+[[https://golang.org/issue/28493][separators for number literals]],
+[[https://golang.org/issue/19113][signed integer shift counts]] –
+got both trimmed and expanded.
+The general Unicode identifiers didn’t make the cut
+as we didn’t have a concrete design document in place in time.
+The proposal for binary integer literals was expanded significantly
+and led to a comprehensive overhaul and modernization of
+[[https://golang.org/design/19308-number-literals][Go’s number literal syntax]].
+And we added the Go 2 draft design proposal on
+[[https://golang.org/design/go2draft-error-inspection][error inspection]],
+which has been
+[[https://golang.org/issue/29934#issuecomment-489682919][partially accepted]].
+
+With these initial changes in place for Go 1.13,
+it’s now time to look forward to Go 1.14
+and determine what we want to tackle next.
+
+* Proposals for Go 1.14
+
+The goals we have for Go today are the same as in 2007: to
+[[https://blog.golang.org/toward-go2][make software development scale]].
+The three biggest hurdles on this path to improved scalability for Go are
+package and version management,
+better error handling support,
+and generics.
+
+With Go module support getting increasingly stronger,
+support for package and version management is being addressed.
+This leaves better error handling support and generics.
+We have been working on both of these and presented
+[[https://golang.org/design/go2draft][draft designs]]
+at last year’s GopherCon in Denver.
+Since then we have been iterating those designs.
+For error handling, we have published a concrete,
+significantly revised and simplified proposal (see below).
+For generics, we are making progress, with a talk
+(“Generics in Go” by Ian Lance Taylor)
+[[https://www.gophercon.com/agenda/session/49028][coming up]]
+at this year’s GopherCon in San Diego,
+but we have not reached the concrete proposal stage yet.
+
+We also want to continue with smaller
+improvements to the language.
+For Go 1.14, we have selected the following proposals:
+
+[[https://golang.org/issue/32437][#32437]].
+A built-in Go error check function, “try”
+([[https://golang.org/design/32437-try-builtin][design doc]]).
+
+This is our concrete proposal for improved error handling.
+While the proposed, fully backwards-compatible language extension
+is minimal, we expect an outsize impact on error handling code.
+This proposal has already attracted an enormous amount of comments,
+and it’s not easy to follow up.
+We recommend starting with the
+[[https://golang.org/issue/32437#issue-452239211][initial comment]]
+for a quick outline and then to read the detailed design doc.
+The initial comment contains a couple of links leading to summaries
+of the feedback so far.
+Please follow the feedback recommendations
+(see the “Next steps” section below) before posting.
+
+[[https://golang.org/issue/6977][#6977]].
+Allow embedding overlapping interfaces
+([[https://golang.org/design/6977-overlapping-interfaces][design doc]]).
+
+This is an old, backwards-compatible proposal for making interface embedding more tolerant.
+
+[[https://golang.org/issue/32479][#32479]] Diagnose `string(int)` conversion in `go`vet`.
+
+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.
+
+[[https://golang.org/issue/32466][#32466]] Adopt crypto principles
+([[https://golang.org/design/cryptography-principles][design doc]]).
+
+This is a request for feedback on a set of design principles for
+cryptographic libraries that we would like to adopt.
+See also the related
+[[https://golang.org/issue/32716][proposal to remove SSLv3 support]]
+from `crypto/tls`.
+
+* Next steps
+
+We are actively soliciting feedback on all these proposals.
+We are especially interested in fact-based evidence
+illustrating why a proposal might not work well in practice,
+or problematic aspects we might have missed in the design.
+Convincing examples in support of a proposal are also very helpful.
+On the other hand, comments containing only personal opinions
+are less actionable:
+we can acknowledge them but we can’t address them
+in any constructive way.
+Before posting, please take the time to read the detailed
+design docs and prior feedback or feedback summaries.
+Especially in long discussions, your concern may have already
+been raised and discussed in earlier comments.
+
+Unless there are strong reasons to not even proceed into the
+experimental phase with a given proposal,
+we are planning to have all these implemented at the
+start of the
+[[https://golang.org/wiki/Go-Release-Cycle][Go 1.14 cycle]]
+(beginning of August, 2019)
+so that they can be evaluated in practice.
+Per the
+[[https://blog.golang.org/go2-here-we-come][proposal evaluation process]],
+the final decision will be
+made at the end of the development cycle (beginning of November, 2019).
+
+Thank you for helping making Go a better language!