all: use built-in min/max

[callthingsoff]

Since go.mod is 1.21, we can simplify code by using these built-in functions.

[callthingsoff]

https://github.com/golangci/golangci-lint/blob/dafe1469eb4b35ca04af0b9725bed7d69f3c5918/go.mod#L3
The lint error is probably related to this.
The main branch uses Go 1.21, however, golangci-lint uses 1.20.
Should this PR be abandoned?

[jmhbnz]

https://github.com/golangci/golangci-lint/blob/dafe1469eb4b35ca04af0b9725bed7d69f3c5918/go.mod#L3 The lint error is probably related to this. The main branch uses Go 1.21, however, golangci-lint uses 1.20. Should this PR be abandoned?

Looks like golangci-lint supports go 1.21 fully from version v1.54.1, refer golangci/golangci-lint#3933.

We need to update our golangci-lint version here https://github.com/etcd-io/etcd/blob/main/.github/workflows/static-analysis.yaml#L18.

Can you please add a second commit to this pr @gocurr to bump that? I believe it will resolve the issue you're seeing and allow us to merge this.

[jmhbnz]

LGTM - Thanks for cleaning this up @gocurr 👍🏻

[ahrtr]

Users won't be able to build etcd (main) using golang 1.20.x any more if we merge this PR. Although we suggest to build the main branch using go 1.21, technically we should NOT prevent users from building main using go 1.20.x for now.

So suggest on hold this PR until go 1.20.x is out of support.

[ahrtr]

This can be merged separately.

[callthingsoff]

I think it should be kept to prevent new contributors
from using the new features of 1.21.

[ahrtr]

Explicitly mark this as request changes.

#16661 (comment)

[callthingsoff]

Seems awkward that you have to keep explaining to new contributors
why new features in 1.21(https://go.dev/doc/go1.21) is unacceptable.

But I understand, and a new PR (golangci-lint: bump to 1.54.1 from 1.53.3) will be created.

[serathius]

Users won't be able to build etcd (main) using golang 1.20.x any more if we merge this PR. Although we suggest to build the main branch using go 1.21, technically we should NOT prevent users from building main using go 1.20.x for now.

Not sure I understand the motivation. We have updated the go version in go.mod to 1.21. This is a clear suggestion that libraries we publish are go1.21 compatible. As for 1.20 backward compatibility, I would agree it's important, however only for release-3.4 and release-3.5 branches as we promise backward compatibility.

There is no reason to require go1.20 compatibility from main branch.

[ahrtr]

This is a clear suggestion that libraries we publish are go1.21 compatible.

Suggestion != mandatory

It forces the applications/users, which depend on/use etcd, to bump their golang version to 1.21.

Overall it isn't a big deal, since 1.20 will be out of support about 4~5 months later. But let's try not to bring bad user experience.

[jmhbnz]

For main I don't think we should be creating expectation that no new golang features will be adopted until the previous golang release is out of support.

It's a development branch with no guarantee around stability.

If there are exciting new features in golang these might come with a degree of complexity so the sooner we can get those features into our CI system and start observing their behavior over time the better.

This pr is a trivial example in terms of new feature, but I'm glad it's forced this discussion.

I acknowledge that updating golang minor version locally can be annoying, but as developers working on a development branch I think it's to be expected from time to time.

[serathius]

This is a clear suggestion that libraries we publish are go1.21 compatible.

Suggestion != mandatory

True, it's a suggestion because not every golang version introduces backward compatible changes which would make it mandatory.

[ahrtr]

The principle is simple, let's try not technically prevent users or user applications from using a go version (1.20.x) which is still officially supported by golang team. The change in this PR isn't a big deal, I suggest to on-hold this PR until 1.20.x is out of support.

Of course, just as I mentioned above #16661 (comment), it isn't a big deal. I will not insist on this if majority maintainers think we should do it.

[serathius]

Asked @liggitt, he said that Kubernetes doesn't even do this. If you want to propose this, then we should discuss this.

[serathius]

Still, I agree that just the min, max function are not worth of breaking compatibility.

[liggitt]

If you need to keep compatibility with older go versions, a possibility is to put the use of new language features in a go version-gated file and have an alternate implementation in a second file. Of course, that often negates the convenience of using the stdlib version in the first place.

[ahrtr]

a possibility is to put the use of new language features in a go version-gated file and have an alternate implementation in a second file.

thx for the suggestion. The change in this PR isn't worth of introducing additional complexity, nor breaking golang compatibility.

[callthingsoff]

Abandoned this for 1.20 compatibility.