Will the generics support be enabled by default in Go 1.18?

[nil...@gmail.com]

Hi all,

We are really excited about the coming generics support in Go, our test drive of the generics support in 1.17 is so far pretty positive and it would also allow us to immediately delete tens of thousands lines of code from our main project. 

Our understanding is that Go team's current plan is to have the generics support enabled by default in the 1.18 release scheduled for Feb 2022. The question we are facing now is how much certainty we have on that. I mean if generics could get delayed until 1.19, which would be 10 months from now, then we should probably wait rather than switching to the full use of generics now. 

Could someone from the Go team provide us some guidance please? Shall we wait until the coming code freeze or maybe beta1 to expect more clarification? 

Cheers,

Lei  

[Ian Lance Taylor]

The current expectation is that Go 1.18 will support generics. The
tip Go compiler already supports generics. There are bugs, but as
they are reported they are being fixed. It is reasonably likely that
some generics corner cases will not compile in Go 1.18, but the
expectation is that straightforward uses of generics will work as
expected. It is also likely that performance in Go 1.18 will not be
as good as it will be in later releases.

Of course, it's impossible to guarantee this. Something completely
unexpected could happen. But that is the expectation. Hope this
helps.

Ian

[nil...@gmail.com]

Hi Ian, thanks for the reply. 

I totally understand that nothing is guaranteed. Just wondering what is Go team's release policy regarding the deadline. Is that a hard deadline? I guess the generics support is the biggest component in 1.18 (and also the one many people have been waiting for long :) ), if something unexpected happens to it close to the planned release date, will the Go team be willing to delay the release for a couple of weeks to allow generics to be included or the current release policy would require the team to disable the generics in 1.18 to ship the 1.18 on time?

Cheers,

Lei 

[peter.m...@gmail.com]

I'm curious, was any consideration given to hiding generics behind a flag in 1.18?  The idea being it's such a complex feature that one could imagine a backwards incompatible change being desirable if some weird issue is found.

[Ian Lance Taylor]

On Mon, Oct 11, 2021 at 12:59 AM nil...@gmail.com <nil...@gmail.com> wrote:
>
> I totally understand that nothing is guaranteed. Just wondering what is Go team's release policy regarding the deadline. Is that a hard deadline? I guess the generics support is the biggest component in 1.18 (and also the one many people have been waiting for long :) ), if something unexpected happens to it close to the planned release date, will the Go team be willing to delay the release for a couple of weeks to allow generics to be included or the current release policy would require the team to disable the generics in 1.18 to ship the 1.18 on time?

It's difficult to answer these kinds of questions as precisely as one
might wish. Go is an open source project with no paying customers.
We have policies that we do our best to follow, but they're a bit like
the pirate code: more what you'd call guidelines than actual rules.
In the case of conflicting plans we'll try to come to some consensus
as to how best to proceed.

I'll note that for the last few years almost every release has been a
week or two late, so the release date is definitely not a hard
deadline. But a big decision like pulling generics out would most
likely be made well ahead of the release date.

Ian

> On Monday, October 11, 2021 at 12:26:35 PM UTC+8 Ian Lance Taylor wrote:
>>
>> On Sun, Oct 10, 2021 at 2:55 AM nil...@gmail.com <nil...@gmail.com> wrote:
>> >
>> > We are really excited about the coming generics support in Go, our test drive of the generics support in 1.17 is so far pretty positive and it would also allow us to immediately delete tens of thousands lines of code from our main project.
>> >
>> > Our understanding is that Go team's current plan is to have the generics support enabled by default in the 1.18 release scheduled for Feb 2022. The question we are facing now is how much certainty we have on that. I mean if generics could get delayed until 1.19, which would be 10 months from now, then we should probably wait rather than switching to the full use of generics now.
>> >
>> > Could someone from the Go team provide us some guidance please? Shall we wait until the coming code freeze or maybe beta1 to expect more clarification?
>>
>> The current expectation is that Go 1.18 will support generics. The
>> tip Go compiler already supports generics. There are bugs, but as
>> they are reported they are being fixed. It is reasonably likely that
>> some generics corner cases will not compile in Go 1.18, but the
>> expectation is that straightforward uses of generics will work as
>> expected. It is also likely that performance in Go 1.18 will not be
>> as good as it will be in later releases.
>>
>> Of course, it's impossible to guarantee this. Something completely
>> unexpected could happen. But that is the expectation. Hope this
>> helps.
>>
>> Ian
>

> --
> You received this message because you are subscribed to the Google Groups "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/51357b46-a8cb-4f08-a945-a5c283a7d977n%40googlegroups.com.

[Ian Lance Taylor]

On Mon, Oct 11, 2021 at 2:36 AM peter.m...@gmail.com
<peter.m...@gmail.com> wrote:
>
> I'm curious, was any consideration given to hiding generics behind a flag in 1.18? The idea being it's such a complex feature that one could imagine a backwards incompatible change being desirable if some weird issue is found.

Yes, we considered that idea, and decided against it. Since many
people are interested in generics, the effect would be to split the Go
ecosystem: many projects would immediately adopt generics, and many
wouldn't. Then as people depended on other packages, and those
packages started using generics, people who were otherwise not using
generics would be forced to turn them on in a haphazard process. It
seems better for the ecosystem to just permit generics everywhere.

Ian

> On Monday, October 11, 2021 at 5:26:35 PM UTC+13 Ian Lance Taylor wrote:
>>
>> On Sun, Oct 10, 2021 at 2:55 AM nil...@gmail.com <nil...@gmail.com> wrote:
>> >
>> > We are really excited about the coming generics support in Go, our test drive of the generics support in 1.17 is so far pretty positive and it would also allow us to immediately delete tens of thousands lines of code from our main project.
>> >
>> > Our understanding is that Go team's current plan is to have the generics support enabled by default in the 1.18 release scheduled for Feb 2022. The question we are facing now is how much certainty we have on that. I mean if generics could get delayed until 1.19, which would be 10 months from now, then we should probably wait rather than switching to the full use of generics now.
>> >
>> > Could someone from the Go team provide us some guidance please? Shall we wait until the coming code freeze or maybe beta1 to expect more clarification?
>>
>> The current expectation is that Go 1.18 will support generics. The
>> tip Go compiler already supports generics. There are bugs, but as
>> they are reported they are being fixed. It is reasonably likely that
>> some generics corner cases will not compile in Go 1.18, but the
>> expectation is that straightforward uses of generics will work as
>> expected. It is also likely that performance in Go 1.18 will not be
>> as good as it will be in later releases.
>>
>> Of course, it's impossible to guarantee this. Something completely
>> unexpected could happen. But that is the expectation. Hope this
>> helps.
>>
>> Ian
>

> --
> You received this message because you are subscribed to the Google Groups "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/a2b05910-9cdc-4fb4-94d5-61bd12812089n%40googlegroups.com.

[roger peppe]

On Tue, 12 Oct 2021 at 01:42, Ian Lance Taylor <ia...@golang.org> wrote:

On Mon, Oct 11, 2021 at 2:36 AM peter.m...@gmail.com
<peter.m...@gmail.com> wrote:
>
> I'm curious, was any consideration given to hiding generics behind a flag in 1.18?  The idea being it's such a complex feature that one could imagine a backwards incompatible change being desirable if some weird issue is found.

Yes, we considered that idea, and decided against it.  Since many
people are interested in generics, the effect would be to split the Go
ecosystem: many projects would immediately adopt generics, and many
wouldn't.  Then as people depended on other packages, and those
packages started using generics, people who were otherwise not using
generics would be forced to turn them on in a haphazard process.  It
seems better for the ecosystem to just permit generics everywhere.

Ian

ISTM that in a sense, generics are behind a flag in 1.18, on a per-module basis at any rate - if your go.mod file doesn't declare a Go version of at least 1.18, then you can't use type parameters.

 

> On Monday, October 11, 2021 at 5:26:35 PM UTC+13 Ian Lance Taylor wrote:
>>
>> On Sun, Oct 10, 2021 at 2:55 AM nil...@gmail.com <nil...@gmail.com> wrote:
>> >
>> > We are really excited about the coming generics support in Go, our test drive of the generics support in 1.17 is so far pretty positive and it would also allow us to immediately delete tens of thousands lines of code from our main project.
>> >
>> > Our understanding is that Go team's current plan is to have the generics support enabled by default in the 1.18 release scheduled for Feb 2022. The question we are facing now is how much certainty we have on that. I mean if generics could get delayed until 1.19, which would be 10 months from now, then we should probably wait rather than switching to the full use of generics now.
>> >
>> > Could someone from the Go team provide us some guidance please? Shall we wait until the coming code freeze or maybe beta1 to expect more clarification?
>>
>> The current expectation is that Go 1.18 will support generics. The
>> tip Go compiler already supports generics. There are bugs, but as
>> they are reported they are being fixed. It is reasonably likely that
>> some generics corner cases will not compile in Go 1.18, but the
>> expectation is that straightforward uses of generics will work as
>> expected. It is also likely that performance in Go 1.18 will not be
>> as good as it will be in later releases.
>>
>> Of course, it's impossible to guarantee this. Something completely
>> unexpected could happen. But that is the expectation. Hope this
>> helps.
>>
>> Ian
>
> --
> You received this message because you are subscribed to the Google Groups "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/a2b05910-9cdc-4fb4-94d5-61bd12812089n%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUK64FN9%3DYuo0xFTfAz%2Ban8eq9vwgX9rkcFsAdU0P%3DkfQ%40mail.gmail.com.

[Axel Wagner]

On Wed, Oct 13, 2021 at 11:36 AM roger peppe <rogp...@gmail.com> wrote:

ISTM that in a sense, generics are behind a flag in 1.18, on a per-module basis at any rate - if your go.mod file doesn't declare a Go version of at least 1.18, then you can't use type parameters.

The (important) difference being that with a flag, we'd generally reserve the right to change the behavior in the future, should experimentation show it to be deficient, while this way, we can't - once we release generics, we are bound to that. And setting there is no way to opt in to other aspects of go 1.18 *without* also getting generics.

I guess in theory we could have a `language_experiments = (generics)` (or something) directive in go.mod, to *actually* get per-module opt-in to "beta-features". AIUI that's kind of what Haskell does. This might still split the ecosystem, though.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAJhgacjO%2BjhB0WyV1H1vJxXxymP7gkvdNoqvZuHngkEVd3DURw%40mail.gmail.com.

[Henry]

I thought that hiding generics behind a flag is already a thing in Go 1.17?

If a feature is solid enough for stable release, don't make it an opt-out. People can just avoid the language features they don't want to use. I disagree with the suggestion of adding stuffs to go.mod to enable or disable certain language features. If you are releasing a library for production and/or a public consumption, it should be stable enough that you don't need to include experimental language stuffs. If you include experimental stuffs in your projects, it is generally for your own toy projects that you should know well enough that you need to enable certain flags when building. No change to go.mod is necessary. Don't split the ecosystem. The last thing we need are libraries that are incompatible with one another. That happened to D. Even though they fixed it with D2, the language lost its moments and never recovered. I like D, but it is not a fad anymore and not many people use it.

[Ian Lance Taylor]

On Fri, Oct 15, 2021, 12:49 AM Henry <henry.ad...@gmail.com> wrote:

I thought that hiding generics behind a flag is already a thing in Go 1.17?

For the record: not really.  1.17 happens to have some incomplete and buggy support for type parameters, and there is an undocumented flag to turn that on.  But nobody should be using it.

Ian

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/1079497d-b665-48c4-9c36-aecac4b74c9cn%40googlegroups.com.