Golang 1.18 Upgrade Discussion

[beeme1mr]

Overview

Golang 1.18 introduces generics, which would be useful for the Golang OpenFeature SDK. However, since1.18 is only a few months old we need to way the pros and cons of switching.

[beeme1mr]

Can a Golang 1.18 library be used in 1.17? If not, we should wait until 1.18 is more widely supported.

[skyerus]

Can a Golang 1.18 library be used in 1.17? If not, we should wait until 1.18 is more widely supported.

It seems that we could upgrade to 1.18 and be backwards compatible provided that we don't use any of the new features e.g. generics (https://go.dev/ref/mod#go-mod-file-go)

For packages within the module, the compiler rejects use of language features introduced after the version specified by the go directive. For example, if a module has the directive go 1.12, its packages may not use numeric literals like 1_000_000, which were introduced in Go 1.13.

cc @toddbaert @james-milligan

[toddbaert]

It's nice that the compiler rejects the new features, but then in makes the upgrade somewhat less valuable. Still probably worth doing.

After reading your link though, I think that we should add a go directive targeting a specific version, so that we can explicitly agree on minimum supported consumer version.

[davejohnston]

I think we could almost seperate the discussion of supported version and generics (to an extent)

When I started work on the SDK I’d thought about using generics per the spec recommendation to use it in a language if available. I think it would be reasonable to support it in golang, but decided not to do it initially as I haven’t seen it widely used in the community yet and figured not using it probably lowers the bar for integration.

The last 2 versions of golang are supported, so I think it’s good practice to target the lower of the two (1.17). That said it’s about to end of life end of Aug, though you imagine some people will trail behind for 3 months or more.

The question is then do we want to support generics ? I think for the next 6-12 months this will still be mixture of users who haven’t embraced generics and those who do. Are any of you guys using generics in your own projects ? I get the feeling that there isn’t an immediate need for it and having a non generics API gives some flexibility with older versions for golang. The flip side is if it gives a better user experience maybe we should adopt it now ?

[beeme1mr]

Perhaps we postpone this conversation and pick it back up in a few months. I don't think there's an immediate need to upgrade to 1.18.

[InbarPerry]

I think we should upgrade to 1.18, consumers of the SDK can upgrade their projects as well to 1.18 without any breaking changes to their projects, and they don't have to use generics if they don't want to.

[skyerus]

Fuzzing is a repository requirement (go-sdk issue).
Fuzzing is natively supported in 1.18, another reason to consider upgrading.

Note that 1.18 has been available for considerably longer since our last review of this topic (5 months vs 10).

[toddbaert]

I agree it's about time, especially since fuzzing is supported natively.

[james-milligan]

Flagd is already using 1.19, which released back in August

https://tip.golang.org/doc/go1.19

[skyerus]

One of the concerns of upgrading here is to not break compatibility with applications using an older version of Go. This doesn't apply to flagd as external applications don't import it directly.