I honestly waited for you to explain how these would be useful in Go. I am not disappointed once again, and you did a great job explaining it with a practical example. I want to add that it is important to underline that Generics in Go can only be applied when the logic is exactly the same. Otherwise it is always best to type check the inputs via an empty interface (where specific types follow specific logic). One example is JSON marshaling, which cannot be implemented using generics. Thanks for this video, and cheers for giving clarity on this topic.
Generics aren't alternatives to type checking, they work well together. If you were implementing a Power function without generics, for example, you would have to create two functions for numbers in general: floatPower(n float64) and intPower(n int64). If you wanted to make it possible for types of every size, you'd have to create even more functions such as: float32Power(n float32), int8Power(n int8), etc. Or, you could use the empty interface approach, but you would have to treat cases such as power("hello"). That means you would have to either have the possibility of a unexpected behavior or you would have to return an error, so you'd have to check that error _every single time_ you call that function just because it is syntactically possible for the user to send something that's not a number into your function. With Go generics, you can just have a func power[num int8 | int16 | int32 | int64 | float32 | float64](n num) and still perform the type check for different operations, if that's the case.
Awesome, I think it `s something to expect in a language these days. Since you cannot cast the value anymore if you use any, you cannot create a generic list to store interfaces, string, numbers, etc.. and then extract the values to continue working with them?
