When creating your interfaces, all this is easy to understand. It's when you are using imports (even from the standard library), is when it gets hard. There is no clear way to tell (that I'm aware of) what interface a stuct implements without digging through the code finding what functions an interface implements, and then checking if the struct you want to use implements those same ones
The go language server (gopls) does implement this functionality, however I do agree if you are just reading code without the use of an external tool, implicit interfaces are definitely not as nice as explicit
Hey Flo, just wanted to say how much I like your teaching style. Your videos are great! Please cover more advanced Golang topics such as Go concurrency patterns and best practices. Thank you!
The kind of thinking of interfaces being a contract is not wrong, but kinda abstract. Think of an interface as a membership, named after whatever you decide to call your interface, in this case "Shape". For any struct/class that wants to have that membership, they have to implement the functions described in that interface, much like how you may want to meet certain criteria to have a gym membership. So for Circle and Rectangle, they have to implement all Shape functions/methods to have a Shape membership. This is convenient because perhaps there could be a function somewhere that only takes Shape members to operate on them (calculateArea), and if Circle and Rectangle are Shape members, that function can operate on either one of them
Why don't we embed interface into structures? For example, If you intend to make a structure implement an interface, simply add "implement interface_name" in structure definition. That will add clarity in code. Right?
Thanks for the video, the explanations are easy to understand. One thing I didn't fully get is how by passing the CalculationError{msg: "Invalid input"} struct instance on the performCalculation() the performCalculation() would use the Error() method of the CalculationError struct, I would've thought that we would need to call the Error() method of the struct but this is not the case, so what I gather with this is that the compiler implicitly deduces that since we are returning a value of type error and because we're using the CalculationError{msg: "Invalid input value"} struct instance as its return value it "sees" that this struct instance has a method that implements the Error() function and hence it uses it. So this is some sort of implicit default method for specific type returns or something like that, I honestly don't no how to refer to this behavior, I had no knowledge if this behavior but is good to know. Thanks again for putting this video together.
error interface is already defined in Go's standard library. We don't need to define it ourselves; we only need to implement it. We don't need to write err.Error() explicitly. when we do fmt.Printf(error instance/objects of error struct ) In most cases, you don't need to call the Error() method explicitly. Go will call it automatically in certain situations: When you use fmt.Println() or fmt.Printf() with an error value. When you convert an error to a string (e.g., with err.Error() or string(err)).
Nice video, but on the language accordance with logic of interface design, let's said that a Shape has a perimeter. So it does reduce the understand about what is the idea to implement a new interface to any duty contract. I would better think about Position as a new interface. Because a shape will have any area, perimeter by logic. But the position it can have is not due to the fact it is a shape, but because this shape can be somewhere. So, for example, An interface named Object can be the resulted union about Shape and Position. This (in my mind) is the way to think about contract interface in Golang (and most probably, in interface in general). Tell me if you are ok with this observation, please.
As far as I've understood it, they're basically like a class in C++ where everything is virtual. Generally we'd refer to that as an abstract class. That and error codes instead of exceptions I copied as features for my own language. I don't like that they use it as a sort of replacement for genericity syntax though. It's basically another void pointer, but with the requirements for casting turned 180 degrees. So better, but not good enough in my opinion. Looks like you do both Rust and Go, but perhaps you should add more languages to your repertoire like plain C and demonstrate how different constructs work at a fundamental level by converting them to C.
The shape interface is the same explanation everywhere. Why can’t someone make a video with thing we would actually use so the real world usage would make sense
Because of the unoriginality of our era. What get's me though is when I watch a video with a title like this one which says that you are not going to need another tutorial and then proceeds to copy the same examples and same way of presenting the information from other videos.
Thank you both for the valuable feedback! Do you know how to showcase the concepts in a more real-world use case? I am currently experimenting with different videos with simple projects (like a text analyzer) to apply the learned concept at the end of the video.
@@FloWoelki Think of something you impliment everyday. Im writing GRPC microservices everyday, creating factories, builder models etc. Maybe just a simple user database writer? Also, something that REALLY GETS MY GOAT (can you tell?) is that every dev on yt just writes a main.go file. Dont be lazy and actually impliment the hex model like you would write an actual service and show how it all works together. This will be INVALUABLE to new devs learnign go!
You are not missing anything! I personally also think that it is not always 100% clear if a struct uses a specific interface. I like more the explicit design, like in other languages.
Well, it's kind of a vibe :D It should be relaxing and enjoyable to watch the video. Usually, I just have some music at the beginning and at the end of the video.
If you want to make it clear that a struct implements a particular interface, you can do a compile time assertion. var _ MyInterface = (*MyStruct)(nil) So you get the explicitness while still allowing consumers to define their own interfaces for which your struct can also satisfy. Not saying to do this, just sharing some knowledge.
Took me a good year before it just for some reason made sense lol now it’s like oh ya I get but the explanations are ugh idk I don’t like the contract explanation
Cant learn from watching somebody, teachers would do well to generate written lessons or just classify as entertainment but there is no middle ground. So much time is wasted “learning” from videos
![Blox Fruits Dragon Rework Update [Full Stream]](http://i.ytimg.com/vi/EqDAp8udhm0/mqdefault.jpg)
When creating your interfaces, all this is easy to understand. It's when you are using imports (even from the standard library), is when it gets hard. There is no clear way to tell (that I'm aware of) what interface a stuct implements without digging through the code finding what functions an interface implements, and then checking if the struct you want to use implements those same ones
It drives me nuts. Rust spoiled me :)
The go language server (gopls) does implement this functionality, however I do agree if you are just reading code without the use of an external tool, implicit interfaces are definitely not as nice as explicit
I've been struggling with how interfaces work for a while now and I think this video finally got it to click for me. Thank you.
I am glad to hear that!
Hey Flo, just wanted to say how much I like your teaching style. Your videos are great! Please cover more advanced Golang topics such as Go concurrency patterns and best practices. Thank you!
Thank you so much for the great feedback!
Go Concurrency patterns is definitely a video on my todo list :)
This teacher is so logical, thanks!!
Thank you :D
Bro everything in this video is amazing, the quality of the explanation, camera, audio and code examples, thanks for this excelente tutorial
Thank you for your comment and for watching the video! Glad I could help you :)
The kind of thinking of interfaces being a contract is not wrong, but kinda abstract.
Think of an interface as a membership, named after whatever you decide to call your interface, in this case "Shape". For any struct/class that wants to have that membership, they have to implement the functions described in that interface, much like how you may want to meet certain criteria to have a gym membership.
So for Circle and Rectangle, they have to implement all Shape functions/methods to have a Shape membership. This is convenient because perhaps there could be a function somewhere that only takes Shape members to operate on them (calculateArea), and if Circle and Rectangle are Shape members, that function can operate on either one of them
That's also a nice way to see it, except that I can always have a membership of something without meeting any requirement or using the membership :D
Why don't we embed interface into structures? For example, If you intend to make a structure implement an interface, simply add "implement interface_name" in structure definition. That will add clarity in code. Right?
Damn man, that was a direct hit. So clear and tqsm
Ahh, such a lovely explanation! Finally clicked for me how and why Error interface works!
Nice to hear that! So awesome that you found it helpful :)
Thanks for the video, the explanations are easy to understand. One thing I didn't fully get is how by passing the CalculationError{msg: "Invalid input"} struct instance on the performCalculation() the performCalculation() would use the Error() method of the CalculationError struct, I would've thought that we would need to call the Error() method of the struct but this is not the case, so what I gather with this is that the compiler implicitly deduces that since we are returning a value of type error and because we're using the CalculationError{msg: "Invalid input value"} struct instance as its return value it "sees" that this struct instance has a method that implements the Error() function and hence it uses it. So this is some sort of implicit default method for specific type returns or something like that, I honestly don't no how to refer to this behavior, I had no knowledge if this behavior but is good to know.
Thanks again for putting this video together.
error interface is already defined in Go's standard library. We don't need to define it ourselves; we only need to implement it. We don't need to write err.Error() explicitly. when we do fmt.Printf(error instance/objects of error struct ) In most cases, you don't need to call the Error() method explicitly. Go will call it automatically in certain situations:
When you use fmt.Println() or fmt.Printf() with an error value.
When you convert an error to a string (e.g., with err.Error() or string(err)).
I'm new to Go and your video's help me a lot, thanks 🙏. Keep it up 💪
Glad to hear it! Thank you so much :)
I've never seen someone explain something that clearly
Wow, thank you! :)
I want to go back to Java already, this Go gets more and more complex as I learn
Your videos are amazing.
Thank you so much! :)
Can you explain the layered architecture in go?
Nice video, but on the language accordance with logic of interface design, let's said that a Shape has a perimeter. So it does reduce the understand about what is the idea to implement a new interface to any duty contract.
I would better think about Position as a new interface. Because a shape will have any area, perimeter by logic. But the position it can have is not due to the fact it is a shape, but because this shape can be somewhere. So, for example, An interface named Object can be the resulted union about Shape and Position.
This (in my mind) is the way to think about contract interface in Golang (and most probably, in interface in general).
Tell me if you are ok with this observation, please.
As far as I've understood it, they're basically like a class in C++ where everything is virtual. Generally we'd refer to that as an abstract class. That and error codes instead of exceptions I copied as features for my own language. I don't like that they use it as a sort of replacement for genericity syntax though. It's basically another void pointer, but with the requirements for casting turned 180 degrees. So better, but not good enough in my opinion. Looks like you do both Rust and Go, but perhaps you should add more languages to your repertoire like plain C and demonstrate how different constructs work at a fundamental level by converting them to C.
This was great!
I am glad you've liked it :)
Thanks This helped a lot.
I am glad it helped :)
Nice explanation my friend!
Thank you! Cheers!
thank you so much
Glad I could help you :)
Thanks so much 💝 this really helped me, keep on goin
You're welcome 😊
Great stuff! Subbed
Much appreciated! :)
Nice explanation. Thanks. Subscribed.
Awesome, thank you!
Nice explanation, please bring video on golang projects too
Thank you! I'll try my best :)
Very nice! Thank you +sub
Thank you! :)
What is the font name?
I am using `monaspace` :)
I knew I could rely on this already being asked 😂
excellent..Thx a lot
Thank you for watching :)
The shape interface is the same explanation everywhere. Why can’t someone make a video with thing we would actually use so the real world usage would make sense
Because of the unoriginality of our era. What get's me though is when I watch a video with a title like this one which says that you are not going to need another tutorial and then proceeds to copy the same examples and same way of presenting the information from other videos.
Thank you both for the valuable feedback! Do you know how to showcase the concepts in a more real-world use case? I am currently experimenting with different videos with simple projects (like a text analyzer) to apply the learned concept at the end of the video.
@@FloWoelki Think of something you impliment everyday. Im writing GRPC microservices everyday, creating factories, builder models etc. Maybe just a simple user database writer? Also, something that REALLY GETS MY GOAT (can you tell?) is that every dev on yt just writes a main.go file. Dont be lazy and actually impliment the hex model like you would write an actual service and show how it all works together. This will be INVALUABLE to new devs learnign go!
Unless im missing something, its Honestly a bad design by Go designers. How would I know what interfaces a type implements off the bat ?
You are not missing anything! I personally also think that it is not always 100% clear if a struct uses a specific interface. I like more the explicit design, like in other languages.
thanks
Sure thing :)
ur explanation is very good but please change the background music. I makes us sleepy
Well, it's kind of a vibe :D It should be relaxing and enjoyable to watch the video. Usually, I just have some music at the beginning and at the end of the video.
Does not cover type constraints. For example type Likeint interface {~int}
👌
implicit implementation of interfaces is a bit weird in Go. Would prefer the rusty way!
I prefer the explicit interface implementation as well, because things are much clearer.
If you want to make it clear that a struct implements a particular interface, you can do a compile time assertion.
var _ MyInterface = (*MyStruct)(nil)
So you get the explicitness while still allowing consumers to define their own interfaces for which your struct can also satisfy.
Not saying to do this, just sharing some knowledge.
@@jordanhasgul4401 Damm didn't know this, thanks!
Is Rust gay?
Yes. I heard it is
Took me a good year before it just for some reason made sense lol now it’s like oh ya I get but the explanations are ugh idk I don’t like the contract explanation
Cant learn from watching somebody, teachers would do well to generate written lessons or just classify as entertainment but there is no middle ground.
So much time is wasted “learning” from videos
You look like magnus
Well, I've never heard that before :D