Great question - my understanding is that you can't use type constraints (in this case Currency) as a type in a normal function - only in a generic function. The reason has to do with how the compiler works, non-generic functions always compile once to handle that function. But a generic function will compile multiple times for each type that it handles. The constraint `Currency` can't be used as a type to compile into a function which works for all implementations of `Currency` - so we need to use a generic function. At least this is how I remember it working in go 1.18 - it's been a while since I looked this deeply at it 😅
@@leetwareltd You can use type constraint interfaces in non generic functions. When you define an interface you don't declair in any way that it is designed for generics or not. The differences are in other keys. For example, a non generic function with interface parameter is compiled to machine code once while a generic function compiles to more versions, one for each unique param types combinations. The compiler looks for each generic function invokation and creates at compile time a version for each different types params. So for example, if you have a generic function that you invoke it for int64 only then the compiler will compile just one version for this function using the int64 type. If it happens you invoke that generic function for both int64 and float64 then the compiler will compile one version of the function for int64 and one version for float64 and will invoke these accordingly. All these at compile time, therefore at runtime will run the appropriate machine code. The generic version provides more type safety and potentially better performance, but at the cost of increased compilation complexity and potential code bloat if used with many different types. The non-generic version offers more flexibility but with a small runtime cost for interface method dispatch. Thanks for your tutorials.
This was the best explanation of go generics I've found, subscribed!
Thanks mate, appreciate the kind words
that was really helpful and so well explained 🎉
In your video at 8:52 Where have you defined type A,B,C?
I was confused at first to see that TSM is doing golang videos nowadays...
Quite a nice video with clear examples. Thanks :)
The best video that explains generics in go, Thanks :)
Thanks mate, means a lot to hear you say that 😊
Very well explained, thanks for creating this video. 👍
thanks, I really like the Currency example, shows what Go generics are capable of!
This is so far the best video on explaining GENERICS. 👍x10000
thank you :)
I don't get the last example. What is difference between `func PrintBalance[T Currency](b T )` with the function `func PrintBalance(b Currency)`?
Great question - my understanding is that you can't use type constraints (in this case Currency) as a type in a normal function - only in a generic function.
The reason has to do with how the compiler works, non-generic functions always compile once to handle that function. But a generic function will compile multiple times for each type that it handles. The constraint `Currency` can't be used as a type to compile into a function which works for all implementations of `Currency` - so we need to use a generic function.
At least this is how I remember it working in go 1.18 - it's been a while since I looked this deeply at it 😅
Great question. I still don't understand this bit.
@@leetwareltd You can use type constraint interfaces in non generic functions. When you define an interface you don't declair in any way that it is designed for generics or not. The differences are in other keys. For example, a non generic function with interface parameter is compiled to machine code once while a generic function compiles to more versions, one for each unique param types combinations. The compiler looks for each generic function invokation and creates at compile time a version for each different types params. So for example, if you have a generic function that you invoke it for int64 only then the compiler will compile just one version for this function using the int64 type. If it happens you invoke that generic function for both int64 and float64 then the compiler will compile one version of the function for int64 and one version for float64 and will invoke these accordingly. All these at compile time, therefore at runtime will run the appropriate machine code.
The generic version provides more type safety and potentially better performance, but at the cost of increased compilation complexity and potential code bloat if used with many different types. The non-generic version offers more flexibility but with a small runtime cost for interface method dispatch.
Thanks for your tutorials.
Broda u r just awesome
Its the best so far for Generics
Thanks, good tutorial!
Thanks, very good content here!
Great tutorial, thank you!
Nice video!
Voice over is pretty cloudy, but nice video
Golang is sexy!