[grey-area]

There are areas where they will help, and be pretty transparent to the user, lots of places in the stdlib, one trivial example: math.Max(a,b) could take any numeric instead of just float64, sort could be neater etc.

Perhaps a Go 2 if they ever get there could be a generic std lib rewrite, largely transparent to the end user, with some minor incompatibilities allowed and lots of stuff rewritten behind the scenes. They could remove a few ugly corners in the stdlib naming specific types by using generics, add a few more container types perhaps, deprecate some old stuff and move it out.

[hnlmorg]

I'm hoping Go 2 replaces the file struct with an interface too. That's been a particular pain point for me.

[cpuguy83]

You mean like https://pkg.go.dev/io/fs#File?

[hnlmorg]

Sorry I should have been more specific. I mean the os file struct https://pkg.go.dev/os#File

The os package makes use of a *File struct rather than an interface. The authors acknowledged this was a mistake but it's some of the oldest code in Go and Go's backwards compatibility guarantee has meant that they cannot fix that.

Since I author a $SHELL written in Go, being able to add in my own *File methods would have allowed me to add in some cool features. But I've found workarounds in most cases. It's just not as clean code as it could have been.

[cpuguy83]

What I am saying is, there is already an interface, which os.File should be implementing.

[hnlmorg]

And what I'm saying is that interface was created after os.File was created and after go 1.0 was released thus that change now cannot happen without breaking the backward compatibility guarantee. Hence my point about go v2.0