7 ms·

Go 1.17 Release Candidate 1

93 points by dustinmoris 5y ago

kyrra 5y ago
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 https://mobile.twitter.com/golang/status/1414721238224838666 EDIT: TLS clients, not server.
- deleted 5y ago
  [deleted]
- deleted 5y ago
  [deleted]
- tedunangst 5y ago
  https://groups.google.com/g/golang-announce/c/n9FxMelZGAQ/m/4ZhvTx0dAQAJ https://groups.google.com/g/golang-announce/c/n9FxMelZGAQ/m/...
icey 5y ago
Release notes: https://tip.golang.org/doc/go1.17 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 5y ago
  Function calls now pass arguments in registers instead of via the stack gaining ~5% improved performance.
  - nappy-doo 5y ago
    On AMD64. ARM64 (landing in 1.18) has shown improvements of 10-17%.
- kjksf 5y ago
  Minor on the surface, yes. Under the hood changing calling conventions is seriously large rework of the compiler and runtime.
  - icey 5y ago
    Ah yeah, what I get for not reading the entire release notes first :)
- FiloSottile 5y ago
  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.
Zababa 5y ago
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!
- nine_k 5y ago
  Introduction of generics would need a major version number change. It would involve not just a complier rework, but also a large stdlib rework.
  - cube2222 5y ago
    That is not true, generics are and have been planned for 1.18. They'll be introduced in a backwards compatible way.
  - verdverm 5y ago
    https://golang.org/doc/go1compat 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 5y ago
      "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.
    - nine_k 5y ago
      Even if the new stdlib is 100% backwards compatible (which I think is the goal), it still needs rework to make it use generics where appropriate.
      - verdverm 5y ago
        why does the stdlib need to adopt generics? That would break the Go1 promise. They would likely introduce new functions rather than changing existing ones. RE: what they did with the ioutil package
welder 5y ago
Please fix SSL system cert verification on Windows! https://github.com/golang/go/issues/16736 https://github.com/golang/go/issues/16736
GiorgioG 5y ago
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.
- tschellenbach 5y ago
  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.
  - LukeShu 5y ago
    For 7 years I felt that way. That yeah, generics might be nice-to-have in Go, but if you were really sweating it that it meant you were still thinking in Java instead of Go. But then I switched teams at work and... > Me: Nothing has ever made me want generics in Go the way that the telepresence2 codebase has made me want generics in Go. > CTO: Is this because of the problem domain or the incidental structure of the code? > Me: I'm honestly not sure. I want to say the incidental structure of the code, but I'm not sure how else I'd structure it. I implemented codegen/template based generics, but eagerly await being able to replace that with actual generics in Go 1.18. So, I guess the lesson is that it's easy to write off it off when it's someone else having the problem?
    - pjmlp 5y ago
      Borland C++ for MS-DOS used pre-processor macros in BIDS 1.0, while BIDS 2.0 replaced that hack with templates. In 2002, Visual Studio T4 was used for generating .NET code shortly after it was introduced. In 2005, Eclipse EMF was used for generating Java code, eventually Java 5 made that unnecessary. As you see, that is a path well known for the last 30 years. Eagerly waiting for Go 1.18, even with CLU like generics.
laverya 5y ago
> 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#L112-L144 https://github.com/replicatedhq/kots/blob/v1.47.0/go.mod#L11... 1: https://github.com/kubernetes/kubernetes/blob/v1.21.2/go.mod#L110-L137 https://github.com/kubernetes/kubernetes/blob/v1.21.2/go.mod...
- LukeShu 5y ago
  > like fixing whatever makes k8s import + override v0.0.0 What needs fixing is the kubernetes.git release process. kubernetes.git/go.mod "overrides" v0.0.0 not with another version (as you do), but with a local directory, because the sources-of-truth for each of those are the kubernetes.git/staging/XXX/ directories. Because of this, if you're working in kubernetes.git the version number never actually matters, so they just leave it with a dummy v0.0.0. But it does matter if you want to import kubernetes.git! If you have nested Go modules in one repo like that, the thing to do to keep your importers happy is that whenever you do a release, you `go mod edit -require=NESTED_MODULE@VERSION` to bump the version number to the one you're about to release. This is what we do in Telepresence[1], if only we could get the Kubernetes folks to do it too... [1]: https://github.com/telepresenceio/telepresence/blob/v2.3.4/build-aux/main.mk#L102 https://github.com/telepresenceio/telepresence/blob/v2.3.4/b...
LukeShu 5y ago
From the linked release notes: > Note that the new conversion from slice to array pointer is the first case in which a type conversion can panic at run time. Analysis tools that assume type conversions can never panic should be updated to consider this possibility. I'm not worried about updating tools, I'm worried about updating humans that assume type conversions can never panic at run time. This change feels like adding a substantial foot-gun.
aarchi 5y ago
> The P521 curve implementation has been rewritten using code generated by the fiat-crypto project, which is based on a formally-verified model of the arithmetic operations. It is now constant-time and three times faster on amd64 and arm64. The observable behavior has not otherwise changed. This is exciting to see formally-verified Coq code being pulled into Go. https://github.com/mit-plv/fiat-crypto https://github.com/mit-plv/fiat-crypto

93 points by dustinmoris 5y ago

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 https://mobile.twitter.com/golang/status/1414721238224838666 EDIT: TLS clients, not server.

deleted 5y ago
[deleted]
deleted 5y ago
[deleted]
tedunangst 5y ago
https://groups.google.com/g/golang-announce/c/n9FxMelZGAQ/m/4ZhvTx0dAQAJ https://groups.google.com/g/golang-announce/c/n9FxMelZGAQ/m/...

icey 5y ago

Release notes: https://tip.golang.org/doc/go1.17 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 5y ago
Function calls now pass arguments in registers instead of via the stack gaining ~5% improved performance.
- nappy-doo 5y ago
  On AMD64. ARM64 (landing in 1.18) has shown improvements of 10-17%.
kjksf 5y ago
Minor on the surface, yes. Under the hood changing calling conventions is seriously large rework of the compiler and runtime.
- icey 5y ago
  Ah yeah, what I get for not reading the entire release notes first :)
FiloSottile 5y ago
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.

Zababa 5y ago

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!

nine_k 5y ago
Introduction of generics would need a major version number change. It would involve not just a complier rework, but also a large stdlib rework.
- cube2222 5y ago
  That is not true, generics are and have been planned for 1.18. They'll be introduced in a backwards compatible way.
- verdverm 5y ago
  https://golang.org/doc/go1compat 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 5y ago
    "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.
  - nine_k 5y ago
    Even if the new stdlib is 100% backwards compatible (which I think is the goal), it still needs rework to make it use generics where appropriate.
    - verdverm 5y ago
      why does the stdlib need to adopt generics? That would break the Go1 promise. They would likely introduce new functions rather than changing existing ones. RE: what they did with the ioutil package

welder 5y ago

Please fix SSL system cert verification on Windows! https://github.com/golang/go/issues/16736 https://github.com/golang/go/issues/16736

GiorgioG 5y ago

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.

tschellenbach 5y ago
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.
- LukeShu 5y ago
  For 7 years I felt that way. That yeah, generics might be nice-to-have in Go, but if you were really sweating it that it meant you were still thinking in Java instead of Go. But then I switched teams at work and... > Me: Nothing has ever made me want generics in Go the way that the telepresence2 codebase has made me want generics in Go. > CTO: Is this because of the problem domain or the incidental structure of the code? > Me: I'm honestly not sure. I want to say the incidental structure of the code, but I'm not sure how else I'd structure it. I implemented codegen/template based generics, but eagerly await being able to replace that with actual generics in Go 1.18. So, I guess the lesson is that it's easy to write off it off when it's someone else having the problem?
  - pjmlp 5y ago
    Borland C++ for MS-DOS used pre-processor macros in BIDS 1.0, while BIDS 2.0 replaced that hack with templates. In 2002, Visual Studio T4 was used for generating .NET code shortly after it was introduced. In 2005, Eclipse EMF was used for generating Java code, eventually Java 5 made that unnecessary. As you see, that is a path well known for the last 30 years. Eagerly waiting for Go 1.18, even with CLU like generics.

laverya 5y ago

> 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#L112-L144 https://github.com/replicatedhq/kots/blob/v1.47.0/go.mod#L11... 1: https://github.com/kubernetes/kubernetes/blob/v1.21.2/go.mod#L110-L137 https://github.com/kubernetes/kubernetes/blob/v1.21.2/go.mod...

LukeShu 5y ago
> like fixing whatever makes k8s import + override v0.0.0 What needs fixing is the kubernetes.git release process. kubernetes.git/go.mod "overrides" v0.0.0 not with another version (as you do), but with a local directory, because the sources-of-truth for each of those are the kubernetes.git/staging/XXX/ directories. Because of this, if you're working in kubernetes.git the version number never actually matters, so they just leave it with a dummy v0.0.0. But it does matter if you want to import kubernetes.git! If you have nested Go modules in one repo like that, the thing to do to keep your importers happy is that whenever you do a release, you `go mod edit -require=NESTED_MODULE@VERSION` to bump the version number to the one you're about to release. This is what we do in Telepresence[1], if only we could get the Kubernetes folks to do it too... [1]: https://github.com/telepresenceio/telepresence/blob/v2.3.4/build-aux/main.mk#L102 https://github.com/telepresenceio/telepresence/blob/v2.3.4/b...

LukeShu 5y ago

From the linked release notes: > Note that the new conversion from slice to array pointer is the first case in which a type conversion can panic at run time. Analysis tools that assume type conversions can never panic should be updated to consider this possibility. I'm not worried about updating tools, I'm worried about updating humans that assume type conversions can never panic at run time. This change feels like adding a substantial foot-gun.

aarchi 5y ago

> The P521 curve implementation has been rewritten using code generated by the fiat-crypto project, which is based on a formally-verified model of the arithmetic operations. It is now constant-time and three times faster on amd64 and arm64. The observable behavior has not otherwise changed. This is exciting to see formally-verified Coq code being pulled into Go. https://github.com/mit-plv/fiat-crypto https://github.com/mit-plv/fiat-crypto