► 33% OFF on my Go + HTMX + Templ Course PRESALE bit.ly/3UFruxO ► Full Projects, Mini courses, Resume reviews, and Coaching thetotalcoder.com ► Join my Discord community for free education discord.com/invite/Ac7CWREe58 ► 60% OFF on my Golang course fulltimegodev.com Thanks for watching
I agree on dependency injection, but I disagree on using interfaces right away. I think abstractions are "needed when they are needed" and not when thinking about future possibilities that may or may not occur. Nonetheless I understand the general point you wanted to convey, thank you for the video!
One of the things I love about DI is that it really forces you to think and reason about your dependencies and the number of dependencies that you have. These implicit dependencies can be hiding in your code and until you make them explicit by requiring them to be passed in, sometimes you don't realize just how many you have. Or you may find that some of them are better if they were grouped together which can lead you to better abstractions. Of course, it's a balance, you could take it to far and push everything to the edges, even standard library functions, but I think that's also a part of DI, wrestling with those decisions about what needs to be an explicit dependency and what's okay to just use.
Something I'd also add is DLT. It's always nice to have separate topic where you have all rejected events with header containing reason why event was rejected.
Just wanted to share that I love how you talked about your community member here and didn’t assume the mistake was a skill issue. Hard-coded dependencies, especially instantiated again and again in a loop, would probably be best to avoid in any language, as others have said. Great video to put out there that helps demonstrate one way to avoid the issue while keeping things positive.
This isn't really a golang mistake. This has more to do with how apis or even codebases are structured. This concept of an interface that encapsulates a service is used everywhere outside of web apis too, heck even outside of the world of programming. Great video though! Creating abstractions to enable compatibility is certainly valuable knowledge that will help many developers.
I dont typically code in terms of "what if" scenarios. Doing so will make your code more abstract and complex. Also abstracting across your database is always a headache. Many databases do things fundamentally different and you will find problems attempting to make a suitable interface(s).
not totally true. depends on how well you define the “what if” scenario. if you as an engineer cannot see 5 or 6 iterations and wait for your PM to initiate new changes then thats basically like coding stories and going home. you havent built a system. i have been writing code for a while now and fortunately my premature abstractions have paid massive dividends. cause i was able to plan for future scope right from the get go. it has to be a balanced approach though
@@croncoder862 premature abstractions are like premature optimizations and premature everything… pre-mature does not carry a positive meaning, it is by definition something that happens before the right time 😉 Short iterations, test, release, fast feedback from the users or the P.O., refactor, rinse and repeat. After 25 years I’ve banned ORMs too in my projects: we “need” to support 5 rdbms.. really? never switched a database in production in the entire product life 😂😂
@@CodiceMente I think you might be prematurely dismissing a decent general concept. Making every single aspect of your code interchangeable at creation is too much but I'd make the counter argument that deeply tying your code to one specific technology or method of doing something is prematurely locking yourself down. Outside forces could arbitrarily force you to change. Your 25 yrs of experience would help prevent mistakes that this concept would make easier for a newer programmer to fix after they make the mistake.
@@Austin-dn3js I agree, ideally the right answer is always finding the right balance. The reality though is that commercial projects are driven by external forces, and there are more non functional constraints than functional ones. When you need to fit a tight budget, please the stakeholders, nail the deadlines, while hopefully write some decent code… well you need to give up most of the what ifs, and think in terms of “deliver value now” ;)
Thanks, as allways perfectly clever explanation. I have question about DI, like here - where and how should be resolved this abstraction? What the most rigth place in project and what style should we use to get balance on clean code, short code, testability etc. ?
I disagree. You should build that only when there's need for it. Otherwise you're choosing what to spend time on based in your intuition about the future.
I’m a addicted to Java way of thinking with Service locator. OF COURSE I Don’t have a service locator in golang but I’m embrace to 100% the strategy patterns. Maybe I will never need to add a second implementation of my service BUT my code is much cleaner since it’s make me create code that don’t depend directly on implémentation details and make my project structure simpler ^^
Dont' want a service locator, with Go i want to be esplicit on which "service" i'm using. I basically let the main() decide which type is going to satisfy my interfaces, so all the code under the main() is agnostic.
@@chepossofareI basically do the same too. I got in my internal module a file that create a golang Struct called « container » which hold my controllers and also a function that create a new Containers with all dependencies solved at hands since it’s easy. I know there are tools like google wire to do that but why bother when I can just keep it simple with Go.
Hi anthony, great video but i have a question. Can we say that we implemented interface seggregation principle here when creating interface and bind it with your struct in this specific example?
The language itself is very simple, there is not much to it. You can learn the majority of it's features in a pretty short time. It's just that when you want to build something out of it then it starts to get harder. Just look at something like building a house, most of the individual steps are fairly simple in their nature, but to know what to do and in what order requires a lot of skill and experience.
Because it is. I had experience in C, Java, JS/TS, PHP and after spending like 20 hours building project in go, you can basically go through any go project and know exactly what is happening. Can't say the same about lagnuages mentioned before, despite the fact that I have way more experience with them.
Why are you abstracting If you don't need it? I don't Abstract If i have No need for abstracting so i don't get IT. So what If you use rabbitmq instead of Kafka? Why don't you Abstract that away? Yes it doesn't make Sense so If he is Not planning to use anything else than mongodb why should he plan of using something else? Don't create Problems where there are None.
@@chepossofare you can Test and Mock your DB individually. Thats ok for me. But why create Abstraction? You can Put that DB Thing somewhere Else or AS injectable for Testing purposes but why give IT an Abstract generic Name? That Just creates complexity.
"you can put that DB thing somewhere else or as injectable..", yeah that's what Abstraction does "We would only use MongoDB".. that's a strong assumption, we never know... As for why abstraction specifically, wouldn't it be better to have configurable db implementation at runtime rather than tighly coupled? I mean, why wouldn't we abstract when there are no cons but potential pros?
For the sake of learning, I agree, but I would not recommend premature abstractions. In the end, 99% of the time, you'll find yourself sticking to the initial implementation.
This is more a design decision than a mistake. Having custom interfaces everywhere can get pretty chatty at times. On the other hand, what I really don't like is the ampersand in return &KafkaConsumer. This forces a heap allocation. Not like that's a problem when you're spawning a db connection for each operation, but it still isn't great.
How would do this while preventing the heap alloc ? This is exactly how we do it at my company, working on large scale production code. In our case this type of "New" functions are called only once during app initialization and the struct is then re-used/passed down the line to the rest of the code, so how bad can heap alloc really be?
@@Symbi0tik Sure, but make sure to double check this does actually do an alloc first. Multiple points: - I personally like to avoid any and all perf pessimization to the point where it heavily informs my code style, this is a preference. - You likely don't have this performance problem, so you don't need to solve it. - Two ways to do this better is to return the struct as a value or to have it as an initializer method. I don't actually like uninitialized structs floating around though, so for me, whenever possible, I return the value. - Use byte buffer pools when you need to pool objects for frequent reuse and abuse Reader/Writer heavily.
Clicking on a video titled “Don't Make this Golang Beginner Mistake!” just to comment that you use Rust and talk shit about Go really says a lot about you.
► 33% OFF on my Go + HTMX + Templ Course PRESALE bit.ly/3UFruxO
► Full Projects, Mini courses, Resume reviews, and Coaching thetotalcoder.com
► Join my Discord community for free education discord.com/invite/Ac7CWREe58
► 60% OFF on my Golang course fulltimegodev.com
Thanks for watching
The same group of people that criticize design patterns are teaching people how to use design patterns.
I agree on dependency injection, but I disagree on using interfaces right away. I think abstractions are "needed when they are needed" and not when thinking about future possibilities that may or may not occur.
Nonetheless I understand the general point you wanted to convey, thank you for the video!
Basically dependency injection + strategy pattern. This is a beginner mistake language agnostic
dependency inversion principle
yep and makes testing a nightmare if you don't do it and the most frustrating experience to work with other devs who dont get it.
@@mik3lon85Devyes, this principle is accomplished by using DI pattern
One of the things I love about DI is that it really forces you to think and reason about your dependencies and the number of dependencies that you have. These implicit dependencies can be hiding in your code and until you make them explicit by requiring them to be passed in, sometimes you don't realize just how many you have. Or you may find that some of them are better if they were grouped together which can lead you to better abstractions. Of course, it's a balance, you could take it to far and push everything to the edges, even standard library functions, but I think that's also a part of DI, wrestling with those decisions about what needs to be an explicit dependency and what's okay to just use.
Something I'd also add is DLT. It's always nice to have separate topic where you have all rejected events with header containing reason why event was rejected.
Just wanted to share that I love how you talked about your community member here and didn’t assume the mistake was a skill issue. Hard-coded dependencies, especially instantiated again and again in a loop, would probably be best to avoid in any language, as others have said. Great video to put out there that helps demonstrate one way to avoid the issue while keeping things positive.
This isn't really a golang mistake. This has more to do with how apis or even codebases are structured. This concept of an interface that encapsulates a service is used everywhere outside of web apis too, heck even outside of the world of programming.
Great video though! Creating abstractions to enable compatibility is certainly valuable knowledge that will help many developers.
I dont typically code in terms of "what if" scenarios. Doing so will make your code more abstract and complex. Also abstracting across your database is always a headache. Many databases do things fundamentally different and you will find problems attempting to make a suitable interface(s).
not totally true. depends on how well you define the “what if” scenario. if you as an engineer cannot see 5 or 6 iterations and wait for your PM to initiate new changes then thats basically like coding stories and going home. you havent built a system. i have been writing code for a while now and fortunately my premature abstractions have paid massive dividends. cause i was able to plan for future scope right from the get go. it has to be a balanced approach though
@@croncoder862 premature abstractions are like premature optimizations and premature everything… pre-mature does not carry a positive meaning, it is by definition something that happens before the right time 😉 Short iterations, test, release, fast feedback from the users or the P.O., refactor, rinse and repeat. After 25 years I’ve banned ORMs too in my projects: we “need” to support 5 rdbms.. really? never switched a database in production in the entire product life 😂😂
@@CodiceMente I think you might be prematurely dismissing a decent general concept. Making every single aspect of your code interchangeable at creation is too much but I'd make the counter argument that deeply tying your code to one specific technology or method of doing something is prematurely locking yourself down. Outside forces could arbitrarily force you to change. Your 25 yrs of experience would help prevent mistakes that this concept would make easier for a newer programmer to fix after they make the mistake.
@@Austin-dn3js I agree, ideally the right answer is always finding the right balance. The reality though is that commercial projects are driven by external forces, and there are more non functional constraints than functional ones. When you need to fit a tight budget, please the stakeholders, nail the deadlines, while hopefully write some decent code… well you need to give up most of the what ifs, and think in terms of “deliver value now” ;)
Thanks for the Input Anthony
Thanks, as allways perfectly clever explanation. I have question about DI, like here - where and how should be resolved this abstraction? What the most rigth place in project and what style should we use to get balance on clean code, short code, testability etc. ?
I disagree. You should build that only when there's need for it. Otherwise you're choosing what to spend time on based in your intuition about the future.
Also indirection makes code harder to read and debug.
A very nice video that helps newbies understand the use cases of interfaces in Go.
I’m a addicted to Java way of thinking with Service locator. OF COURSE I Don’t have a service locator in golang but I’m embrace to 100% the strategy patterns.
Maybe I will never need to add a second implementation of my service BUT my code is much cleaner since it’s make me create code that don’t depend directly on implémentation details and make my project structure simpler ^^
Dont' want a service locator, with Go i want to be esplicit on which "service" i'm using.
I basically let the main() decide which type is going to satisfy my interfaces, so all the code under the main() is agnostic.
@@chepossofareI basically do the same too.
I got in my internal module a file that create a golang Struct called « container » which hold my controllers and also a function that create a new Containers with all dependencies solved at hands since it’s easy.
I know there are tools like google wire to do that but why bother when I can just keep it simple with Go.
That's a good advice regardless the language you're using.
is the D of the SOLID principles, good job btw
Really glad I saw this video. I will never make this mistake since I only write rust. Phew!
Thanks for watching. I really appreciate your time.
The mistake is to ONLY write in a given language :D
Enjoy, though!
From when the 60% discount available for fulltimegodev?
Now
use this only if you actually need to use different types of persistors, don't think "what if" - that's a rabbit hole
Everyone yelling dependency injection.. this is the dependency inversion principle from SOLID principles.
Hi anthony, great video but i have a question. Can we say that we implemented interface seggregation principle here when creating interface and bind it with your struct in this specific example?
It seems like you should make some sleep in the end of for loop, for make free proccessor ? cause it could be a leak
Anthony sir I have seen your Twitter post you made a chart application how the hell you build it please teach us.
can I join total coder and pay for more than one month at a go ? like pay or 6 months or 1 year?
Every time I hear how easy golang is I feel really stupid. As a beginner coming from python it doesn't seem easy at all.
I think they mean that the type system is really straightforward and simple, which it sort of is. Types in python are way more complex and flexible
It is easy, but you need to study a little yet. Or maybe you are too much of a beginner, and really need to study more.
Simple and easy are not the same thing.
The language itself is very simple, there is not much to it. You can learn the majority of it's features in a pretty short time. It's just that when you want to build something out of it then it starts to get harder. Just look at something like building a house, most of the individual steps are fairly simple in their nature, but to know what to do and in what order requires a lot of skill and experience.
Because it is. I had experience in C, Java, JS/TS, PHP and after spending like 20 hours building project in go, you can basically go through any go project and know exactly what is happening. Can't say the same about lagnuages mentioned before, despite the fact that I have way more experience with them.
Why are you abstracting If you don't need it? I don't Abstract If i have No need for abstracting so i don't get IT. So what If you use rabbitmq instead of Kafka? Why don't you Abstract that away? Yes it doesn't make Sense so If he is Not planning to use anything else than mongodb why should he plan of using something else? Don't create Problems where there are None.
It also helps with testing.
That's very useful if you have to test and mock your db.
Tests save my ass EVERY TIME.
Write your tests, people.
@@chepossofare you can Test and Mock your DB individually. Thats ok for me. But why create Abstraction? You can Put that DB Thing somewhere Else or AS injectable for Testing purposes but why give IT an Abstract generic Name? That Just creates complexity.
"you can put that DB thing somewhere else or as injectable..", yeah that's what Abstraction does
"We would only use MongoDB".. that's a strong assumption, we never know... As for why abstraction specifically, wouldn't it be better to have configurable db implementation at runtime rather than tighly coupled?
I mean, why wouldn't we abstract when there are no cons but potential pros?
@@runtimeerror3754 Cons against Abstraction are more complexity. You shouldn't build a castle If a house suffice.
that's a general begginer mistake, not related to the language I would say.
Sorry to ask but what's the theme😅
Gruvbox ❤️
@@anthonygg_ really thanks to you.. also I really love to know about your vs code setup if you could make a video on this
For the sake of learning, I agree, but I would not recommend premature abstractions. In the end, 99% of the time, you'll find yourself sticking to the initial implementation.
Wow
Rookie mistake, could happen in many languages
This is more a design decision than a mistake. Having custom interfaces everywhere can get pretty chatty at times.
On the other hand, what I really don't like is the ampersand in return &KafkaConsumer. This forces a heap allocation. Not like that's a problem when you're spawning a db connection for each operation, but it still isn't great.
How would do this while preventing the heap alloc ? This is exactly how we do it at my company, working on large scale production code.
In our case this type of "New" functions are called only once during app initialization and the struct is then re-used/passed down the line to the rest of the code, so how bad can heap alloc really be?
@@Symbi0tik Sure, but make sure to double check this does actually do an alloc first.
Multiple points:
- I personally like to avoid any and all perf pessimization to the point where it heavily informs my code style, this is a preference.
- You likely don't have this performance problem, so you don't need to solve it.
- Two ways to do this better is to return the struct as a value or to have it as an initializer method. I don't actually like uninitialized structs floating around though, so for me, whenever possible, I return the value.
- Use byte buffer pools when you need to pool objects for frequent reuse and abuse Reader/Writer heavily.
A good reminder regardless of language or skill level, no matter the problem the answer is almost always to use Strategies.
this is not a mistake.. just ignorant
you lost me at interface
i use Rust bro, go was actually made as an insult to its users
username checks out
"I use rust bro" btw
Clicking on a video titled “Don't Make this Golang Beginner Mistake!” just to comment that you use Rust and talk shit about Go really says a lot about you.
Two different tools for two completely different use cases.
Go write some C if you wanna brag, btw 😛
@@catfan5618 Excuse me sir, do you have a moment to talk about our Lord and Savior, RUST?