Update to Go 1.18

[andrerfcsantos]

Go 1.18 is a very anticipated release of the language due to the inclusion of generics, among other things. We should update the tooling of the Go track to support solutions using Go 1.18.

This is a tracking issue for the updates to the track tooling:

• [x] https://github.com/exercism/go-test-runner/issues/68
• [x] https://github.com/exercism/go-analyzer/issues/32
• [x] https://github.com/exercism/go-representer/issues/20

Other than the updates to the individual tools, here in the main repo we should evaluate some exercises to be updated to use generics. Here's some of them that I think would be a natural fit for generics:

• Strain - requires the writing of 3 Keep functions that are exactly the same except for its types.
• List Ops - same reason
• Custom Set - could be a good example on how to make a generic set data structure
• Binary Search - another opportunity to make a generic data structure and use constraints
• Binary Search Tree - same reason
• Simple Linked List - same reason
• Linked List - same reason

There might be other cases where generics can be used but these exercises are the ones I think generics will fit more naturally.

I also think it shouldn't be our intent to use as much generics as possible, so I also see as a possibility intentionally not using generics in some of these exercises, just for the sake of keeping their difficulty down and keep them accessible for someone totally new to the language.

[TheFranconianCoder]

Instead of other languages, I'm used to use the latest Go version for years. I'm sure students will do so and wondering, when it doesn't work. See this forum post: https://forum.exercism.org/t/go-use-of-a-deprecated-function-in-an-exercise/6163

Any reason not directly go up-to-date?

[andrerfcsantos]

We do try to run the lastest major on our infrastructure, so that students can use more recent versions of Go, provided they also update their go.mod accordingly. We are running Go 1.20 (https://github.com/exercism/go/pull/2609)

The main reason we don't update all the go.mods is because despite being a trivial change, it causes all the people who already solved the exercise to have to update the exercise, and that can be annoying. Exercism does have an option to auto-update exercises if they pass the tests and while that's great, it can cause overload on the exercism infrastructure since all solutions ever on Go suddenly need to be re-tested. So we should be mindful of the frequency we do this.

Even with the auto-update feature, one still needs to update the local copy of the exercises manually (or with a special script), and "forcing" people to do this every 6 months seems a bit too much, especially if they are not very active on the track.

One possible solution is to consider having go.mods with different versions for different exercises, but this also makes the track a bit inconsistent, since the minimum Go version of the track will then be the highest version in any of the go.mods.

There is some evidence that most people do use the latest version of Go, or the one before that, but that's true for people who use Go a lot, which might no be reflective of all the users in Exercism. They might install Go to try a few exercises, play around a bit, but then leave it and come back later in a few months. When they come back, they might necessarily not want to update Go and/or all the exercises in the track to get the new go.mod. So, keeping the go.mod a few versions below the infrastructure gives some margin for people to be able to come back and not have to change a lot on their environment and just focus on the exercises.

But of course, we don't want to get too behind, so it's always a fine balance.

Even if you use the most recent version of Go, the compiler will warn if you are trying to use a feature that your go.mod doesn't allow, and you can update the go.mod then and submit it to Exercism and that should work.