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?
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.
One of the best things you can do a video on is entgo + gqlgen for full backend with graphql
Eeeeexcellent, said Mr. Burns xD
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?
One of the best channel for go keep up bro 💪
What is the theme you use for vscode? Thank you so much.
Very clear explanation, thanks!
Can someone plz tell me the name of this vscode theme? I love it
same! Really nice colours
Amazing content and explanations.
Cool 👍
Great explanation ty
Thanks a lot for the sharing
Why do I always hear "genetic" (instead of "generic")?
Ouelsh Akksent
Google translate too
Probably the Scotish accent. :)
hallo everyone. how people implement this without generic?
One function for each type (and yes, some code repetition)
What sweet VS Code theme is that?!
Hi! What colorscheme do you use?
Would like to know as well!
This is nice but I will wait for it to be released in stable
It's been released now!
doest this work for custom types?
Yes it does
Seems more like union types than generics itself
Using the "any" keyword will make it totally generic.
@@Max-bh8tg 😂
Well, i've got to say they finally gave people a reason to maybe use go. Up to now, the language has been completly useless