Don't Make this Golang Beginner Mistake!

Подписаться 59 тыс.

Просмотров 19 тыс.

50% 1

In this video, we'll talk about a common mistake that beginners make in Golang when dealing with interfaces. Learn how to avoid this error and improve your Golang coding skills!
► Join my Discord community for FREE education 👉 / discord
► Full Projects, Mini courses, Resume reviews, and Coaching 👉 thetotalcoder.com
► 33% OFF on my Go + HTMX + Templ Course 👉bit.ly/3UFruxO
► Enjoy a 60% Black Friday Discount on My Golang Course 👉 fulltimegodev.com
► Follow me on Twitter 👉 / anthdm
► Follow me on GitHub 👉 github.com/anthdm

Опубликовано:

27 май 2024

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 67

@anthonygg_ Месяц назад

► 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

@moneymaker7307 Месяц назад

The same group of people that criticize design patterns are teaching people how to use design patterns.

@beneditomauroo Месяц назад

Basically dependency injection + strategy pattern. This is a beginner mistake language agnostic

@mik3lon85Dev 29 дней назад

dependency inversion principle

@el_carbonara 29 дней назад

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.

@beneditomauroo 26 дней назад

@@mik3lon85Devyes, this principle is accomplished by using DI pattern

@temperkan3727 29 дней назад

A very nice video that helps newbies understand the use cases of interfaces in Go.

@myrachoantonio8832 9 дней назад

Thanks for the Input Anthony

@RockyNeurock 28 дней назад

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.

@karix02 Месяц назад

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.

@tmanley1985 Месяц назад

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.

@mquanit Месяц назад

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?

@dandogamer 29 дней назад

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).

@croncoder862 28 дней назад

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

@CodiceMente 25 дней назад

@@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 😂😂

@Austin-dn3js 23 дня назад

@@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.

@CodiceMente 22 дня назад

@@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” ;)

@user-hn1ph6ry8l 2 дня назад

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. ?

@mik3lon85Dev 29 дней назад

is the D of the SOLID principles, good job btw

@mainawachira1828 Месяц назад

can I join total coder and pay for more than one month at a go ? like pay or 6 months or 1 year?

@Load_Overlord Месяц назад

From when the 60% discount available for fulltimegodev?

@anthonygg_ Месяц назад

Now

@chepossofare 29 дней назад

That's a good advice regardless the language you're using.

@gungun974 Месяц назад

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 ^^

@chepossofare 29 дней назад

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.

@gungun974 29 дней назад

@@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.

@maxbro2598 23 дня назад

It seems like you should make some sleep in the end of for loop, for make free proccessor ? cause it could be a leak

@dmitrynizhnikov657 25 дней назад

use this only if you actually need to use different types of persistors, don't think "what if" - that's a rabbit hole

@prerit714 Месяц назад

Really glad I saw this video. I will never make this mistake since I only write rust. Phew!

@anthonygg_ Месяц назад

Thanks for watching. I really appreciate your time.

@zyriab5797 Месяц назад

The mistake is to ONLY write in a given language :D Enjoy, though!

@prashlovessamosa 28 дней назад

Anthony sir I have seen your Twitter post you made a chart application how the hell you build it please teach us.

@amremam4899 Месяц назад

Wow

@peterYOUpanne Месяц назад

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.

@pcostesi Месяц назад

It also helps with testing.

@chepossofare 29 дней назад

That's very useful if you have to test and mock your db. Tests save my ass EVERY TIME. Write your tests, people.

@peterYOUpanne 29 дней назад

@@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.

@runtimeerror3754 29 дней назад

"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?

@peterYOUpanne 29 дней назад

@@runtimeerror3754 Cons against Abstraction are more complexity. You shouldn't build a castle If a house suffice.

@ThalesTheDuck 16 дней назад

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.

@AlgyTRG Месяц назад

that's a general begginer mistake, not related to the language I would say.

@wogvorph Месяц назад

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.

@lulzmachineify Месяц назад

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

@mateushesed Месяц назад

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.

@catfan5618 Месяц назад

Simple and easy are not the same thing.

@polle5555 Месяц назад

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.

@Gornius Месяц назад

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.

@latakantsharma3134 17 дней назад

Sorry to ask but what's the theme😅

@anthonygg_ 17 дней назад

Gruvbox ❤️

@latakantsharma3134 17 дней назад

@@anthonygg_ really thanks to you.. also I really love to know about your vs code setup if you could make a video on this

@tangocukedi1 29 дней назад

Rookie mistake, could happen in many languages

@alexballas361 29 дней назад

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.

@nexovec 29 дней назад

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.

@Symbi0tik 29 дней назад

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?

@nexovec 29 дней назад

@@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.

@demmidemmi Месяц назад

A good reminder regardless of language or skill level, no matter the problem the answer is almost always to use Strategies.

@Grahamaan27 29 дней назад

you lost me at interface

@theLowestPointInMyLife Месяц назад

i use Rust bro, go was actually made as an insult to its users

@szymon9290 Месяц назад

username checks out

@HeavenlySkyFriday Месяц назад

"I use rust bro" btw

@catfan5618 Месяц назад

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.

@zyriab5797 Месяц назад

Two different tools for two completely different use cases. Go write some C if you wanna brag, btw 😛