[HN Gopher] Go 1.17 Release Candidate 1
___________________________________________________________________
Go 1.17 Release Candidate 1
Author : dustinmoris
Score : 64 points
Date : 2021-07-13 20:33 UTC (2 hours ago)
(HTM) web link (groups.google.com)
(TXT) w3m dump (groups.google.com)
| kyrra wrote:
| As an aside, go 1.16.6 was also released today to fix a CVE that
| can panic tls clients.
|
| https://mobile.twitter.com/golang/status/1414721238224838666
|
| EDIT: TLS clients, not server.
| tedunangst wrote:
| https://groups.google.com/g/golang-announce/c/n9FxMelZGAQ/m/...
| [deleted]
| [deleted]
| icey wrote:
| Release notes: https://tip.golang.org/doc/go1.17
|
| Looks like a pretty minor release.
|
| Go 1.17 includes three small enhancements to the language:
| Conversions from slice to array pointer, unsafe.Add, unsafe.Slice
| Zariel wrote:
| Function calls now pass arguments in registers instead of via
| the stack gaining ~5% improved performance.
| FiloSottile wrote:
| Those are just the changes to the language! Many releases have
| none at all. Keep scrolling for a lot of improvements to the
| toolchain and standard library, including a couple security
| changes that might cause necessary behavior changes.
| kjksf wrote:
| Minor on the surface, yes.
|
| Under the hood changing calling conventions is seriously large
| rework of the compiler and runtime.
| GiorgioG wrote:
| How far are we from Golang 2.0 RCs? Are they trying to exceed
| Scala 3's development cycle?
|
| As much as I'd like to use a pragmatic language like golang, I
| can't live without generics (many folks feel the same way.) Feels
| like I'm better off learning Rust. Go's loss is Rust's gain.
| tptacek wrote:
| There aren't many productive language discussions that include
| sentences like "Blub's loss is Floop's gain". If you want to
| learn Rust, go learn Rust. We call them "languages", but
| they're just tools we use to solve problems. Use the one that
| makes sense for you. We use both Blub and Floop; it works out
| fine.
| LukeShu wrote:
| # Go 2
|
| In 2017[1] it was decided that the "Go 2" project would be done
| incrementally adding features in Go 1.x releases, as long as
| those features can be added in backward-compatible ways, and
| there will likely only be a actual 2.x release if they need to
| make backward incompatible changes:
|
| _> Once all the backwards-compatible work is done, say in Go
| 1.20, then we can make the backwards-incompatible changes in Go
| 2.0. If there turn out to be no backwards-incompatible changes,
| maybe we just declare that Go 1.20_ is _Go 2.0._ [1]
|
| With that, they developed a formal language-change proposal and
| acceptance process, and the Go 2 proposals transitioned from
| being pie in the sky ideas to concrete proposals, and a number
| of proposals for "go2" features were selected[2] to be included
| in 1.13. And so in September 2019, Go 1.13 became the first
| "go2" release[3], the first release since 2012 to include
| significant language changes.
|
| And so we've been seeing language changes land incrementally in
| releases for the last several years now, rather than waiting
| for a "big bang" 2.0 release.
|
| # Development cycle
|
| Go does a release every 6 months, in February and in August.
| ("But above you said 1.13 was in September!" Yes, it slipped
| from August to September 3rd.)
|
| # Generics
|
| Generics[4] are currently slated to be in Go 1.18 (February
| 2022).[5]
|
| [1]: https://blog.golang.org/toward-go2
|
| [2]: https://blog.golang.org/go2-here-we-come
|
| [3]: https://blog.golang.org/go2-next-steps
|
| [4]: https://github.com/golang/go/issues/43651
|
| [5]: https://blog.golang.org/generics-proposal
| DangitBobby wrote:
| I may not love the language but I _do_ love this release
| plan!
| tschellenbach wrote:
| You learn to work around the lack of generics quite easily.
| Sometimes this means having to write the same code a few times.
| But if I look at our entire codebase you're looking at
| something that impacts less than 1%. I think for most projects
| the lack of generics is not a major issue.
| _ph_ wrote:
| The first implementation of generics is planned for Go 1.18, so
| no need for a Go 2.0.
| Zababa wrote:
| > As much as I'd like to use a pragmatic language like golang,
| I can't live without generics (many folks feel the same way.)
| Feels like I'm better off learning Rust. Go's loss is Rust's
| gain.
|
| You can usually have "generics" by way of code generation, or
| losing type safety. Both aren't perfect but they still work. I
| wonder, what do you use generics for? Maybe Go isn't suited for
| that type of work in general.
|
| > Feels like I'm better off learning Rust. Go's loss is Rust's
| gain.
|
| Or just Java, Go isn't just competing with Rust. Again, that
| will depend on your problem space.
| Zababa wrote:
| I thought that the 1.17 was going to be the generics release, I
| guess I was wrong. The 5% performance improvment is very nice,
| congratulations!
| LukeShu wrote:
| "Originally" they were, but it was bumped to 1.18 (February
| 2022) a while back.
| Zababa wrote:
| Thanks, I missed that info.
| nine_k wrote:
| Introduction of generics would need a major version number
| change. It would involve not just a complier rework, but also a
| large stdlib rework.
| verdverm wrote:
| https://golang.org/doc/go1compat
|
| Generally, adding features does not break backwards
| compatibility. Note that ioutil was depreciated while it is
| unlikely to ever be removed
| 37ef_ced3 wrote:
| "The io/ioutil package has turned out to be a poorly
| defined and hard to understand collection of things. All
| functionality provided by the package has been moved to
| other packages. The io/ioutil package remains and will
| continue to work as before, but we encourage new code to
| use the new definitions in the io and os packages."
|
| It will never be removed, thankfully.
| cube2222 wrote:
| That is not true, generics are and have been planned for
| 1.18.
|
| They'll be introduced in a backwards compatible way.
| laverya wrote:
| > If a module specifies go 1.17 or higher in its go.mod file, its
| transitive requirements are now loaded lazily, avoiding the need
| to download or read go.mod files for otherwise-irrelevant
| dependencies. To support lazy loading, in Go 1.17 modules the go
| command maintains explicit requirements in the go.mod file for
| every dependency that provides any package transitively imported
| by any package or test within the module. See the design document
| for more detail.
|
| Wait, does this mean we can import things that themselves import
| kubernetes without also having to include this huge list of
| overrides [0] due to the huge list of v0.0.0 imports that k8s
| then overrides?
|
| Or is that going to take other changes... (like fixing whatever
| makes k8s import + override v0.0.0)
|
| 0:
| https://github.com/replicatedhq/kots/blob/v1.47.0/go.mod#L11...
|
| 1:
| https://github.com/kubernetes/kubernetes/blob/v1.21.2/go.mod...
| welder wrote:
| Please fix SSL system cert verification on Windows!
|
| https://github.com/golang/go/issues/16736
___________________________________________________________________
(page generated 2021-07-13 23:00 UTC)