In case you wonder if it is worth creating videos regularily, thanks for that a lot, your videos are super helpful and instructive, hope for many more ;)
This video is a nice explanation how to use interfaces instead of concrete instances, but it does not explain dependency injection at all. With dependency injection you build a provider (ioc container) that provides (injects) the concrete instances to methods.
Brilliant Video. Pls share more golang videos and most used patterns in real time production code and also how one can use external packages that contains interfaces and struct types and what and when we can initialise or embed the in our code? U got me subscribed with this one video and hoping to see more...
you show us some codes, but the intuition is start from hello word to wrote all words, without autocompletions lile copilot.... using copilot ia the the teacher that use paper to vopy past in broad.
I want to answer if I can, first of all, those are more like factory or generator functions, not constructors. Second, idk about Go but in C++ when you work with objects (or non primitive types), you usually want to pass the reference instead of the whole object. One reason for this is pass by value clones the entire object and also it's a different object every time because it's a clone. When you pass the pointer, it's the same object every time and in this case this is the desired outcome.
@@EverRusting Yeah but when I return pointer from function (method, constructor, whatever), doesn't it goes to heap? When I'm turning on gc in vscode or goland, it says that returned pointer goes to heap every time. And doesn't it means that garbage collector will do some work in the future, and doesn't it much bigger work than copy value from one stack frame to another?
@@gggalahad I have started reading Learning Go v2 recently and the author says the same thing. If you pass a pointer, it goes to the heap, and most times it's better to pass value instead of a pointer. Unless it's a struct with a lot of values. A quote from the book: "Most of the time, you should use a value. Values make it easier to understand how and when your data is modified. A secondary benefit is that using values reduces the amount of work that the garbage collector has to do." But I still see that most built-in go packages return pointer instead of a value. Like gzip.NewReader, errors.New etc.
In case you wonder if it is worth creating videos regularily, thanks for that a lot, your videos are super helpful and instructive, hope for many more ;)
Thank you! It’s been difficult to stay consistent, but im glad to be back at it
This video is a nice explanation how to use interfaces instead of concrete instances, but it does not explain dependency injection at all. With dependency injection you build a provider (ioc container) that provides (injects) the concrete instances to methods.
Best explanation. Thank you for this.
Brilliant Video. Pls share more golang videos and most used patterns in real time production code and also how one can use external packages that contains interfaces and struct types and what and when we can initialise or embed the in our code? U got me subscribed with this one video and hoping to see more...
thank you! planning to release a lot of Go videos
Clean! Thanks man
What if i have multiple dependencies like db, external service, ... other dependencies and they are dependent interdependent as well
you show us some codes, but the intuition is start from hello word to wrote all words, without autocompletions lile copilot....
using copilot ia the the teacher that use paper to vopy past in broad.
Great video. Could you explain please why constructor function always returns pointer ?
I want to answer if I can, first of all, those are more like factory or generator functions, not constructors.
Second, idk about Go but in C++ when you work with objects (or non primitive types), you usually want to pass the reference instead of the whole object.
One reason for this is pass by value clones the entire object and also it's a different object every time because it's a clone.
When you pass the pointer, it's the same object every time and in this case this is the desired outcome.
@@EverRusting Yeah but when I return pointer from function (method, constructor, whatever), doesn't it goes to heap? When I'm turning on gc in vscode or goland, it says that returned pointer goes to heap every time. And doesn't it means that garbage collector will do some work in the future, and doesn't it much bigger work than copy value from one stack frame to another?
@@gggalahad I have started reading Learning Go v2 recently and the author says the same thing. If you pass a pointer, it goes to the heap, and most times it's better to pass value instead of a pointer.
Unless it's a struct with a lot of values.
A quote from the book: "Most of the time, you should use a value. Values make it easier to understand how and when your data is modified. A secondary benefit is that using values reduces the amount of work that the garbage collector has to do."
But I still see that most built-in go packages return pointer instead of a value. Like gzip.NewReader, errors.New etc.
Ide?
font name?
I believe that's jetbrains mono
berkeleygraphics.com/typefaces/berkeley-mono/