A big mindset shift for me was passing by pointer or by copy. Sometimes it’s simpler to just pass a copy of data and know that no other go routine can access that data.
@twitchizle2 ай бұрын
Pass by pointer if its object, pass by value if its primitive.
@keshavakumar98282 ай бұрын
@@twitchizle pass by pointer if its concurrent, be it primitive or object
@romarioputra37752 ай бұрын
yep, immutable data is thread safe
@DonDikaio2 ай бұрын
"Now that I'm a professional Go Developer" how can you not love the attitude.
@lifewithyousof2 ай бұрын
Welcome to Multithreading. Mutexes are the worst and slowest way to do it but it's the easiest. You have scoped variables, semaphores, and atomic operations. It's a big world.
@massy-39612 ай бұрын
Shared mutable data is a foot gun of a developer rather than the language, except rust I guess. It’s more of your duty to make sure you don’t have multiple write access to the same variable. Only reason JavaScript doesn’t have this issue is that it’s single threaded and will never have concurrent access. Also if you really want, there is a built in atomic package that has an atomic int that allows you to have shared access safely. Another option that you can do is just use channels as they thrive in concurrency. Make a channel that has a go routine that just listens and increments the real counter on receive, then all handlers can just read the count and use the channel to increment. Would be nice to wrap all of that in a struct.
@vladlazar942 ай бұрын
Exactly my thoughts, thanks for writing this. An important additional benefit of using channels is that they can buffer messages. A mutex blocks all coroutines waiting on it, whereas a buffered channel can be written to even when the select at its other end is not ready to process the message. So instead of waiting on the mutex, a coroutine pushes a message into the buffered channel and carries on with its work. This is called handling backpressure.
@Fullflexno12 күн бұрын
Thank you for this! Super cool!
@k98killer2 ай бұрын
Goroutines run concurrently and/or in parallel. I wrote and parallelized a genetic algorithm library in Go last year (and then optimized memory use with object pools). It basically takes a batch of tasks and divides them up into the number of goroutines passed as an argument, using channels more or less as task queues and locks on every re-used object. It runs with 100% CPU utilization on all 8 cores as long as I specify 8 or more goroutines. Concurrency is tricky.
@zendr02 ай бұрын
Good one Cody! Look forward for more
@Frostbytedigital2 ай бұрын
Cody getting lots of love from prime lately. Wonder if this one will get picked up too.
@C4CH3S2 ай бұрын
Yes, this is why you should avoid side effects as much as possible in golang.
@erikslorenz2 ай бұрын
The number one one I always forget is in regular handlers doing the naked return after an early response. Then again I always forgot that in node too.
@lemurza52362 ай бұрын
I'm not sure i consider the a Go footgun?
@spencerwilson-softwaredeve63842 ай бұрын
Basic concurrency handling, shared mutable state requires a mutex if multiple threads want to access it at once, I guess javascript/python just hides all of this away
@hamm89342 ай бұрын
This is more so learning pains when going a little lower level
@WebDevCody2 ай бұрын
Got em
@Frostbytedigital2 ай бұрын
@lemurza5236 I think you can consider it a foot gun since go compiler doesn't flag variables accessed within go routines that aren't locked.
@perc-ai2 ай бұрын
this is just a skill issue not a footgun by any means its designed perfectly
@tmanley19852 ай бұрын
This is also known as the Lost Updates problem in concurrency. You can use locks, but you can also use channels to ensure serialized access to some variable like a counter.
@abhishekmehandiratta42412 ай бұрын
If you're sharing primitives across goroutines, you can use the atomic package which I've heard is more performant.
@khazixfangirl60872 ай бұрын
For this little example, I think the incrementing will work if you make it atomic
@Simbysolo2 ай бұрын
Thanks for pointing this out
@arturfil2 ай бұрын
Yeah this happens because the variable is trying to be updated by multiple threads at the same time and each thread doesn't have recount of the previous. A mutex (or a semaphor) only allows one thread to update the variable at a time and solves this problem. Channels is like a nicer semaphor version where the variable is also locked if the channel has no buffer or has 1 "unit" of buffer. Pretty cool stuff imo.
@SeibertSwirl2 ай бұрын
Ugh finally lol love ya babe! Great job as usual ❤
@WebDevCody2 ай бұрын
You’re the best!
@Yesquiteindeed3213212 ай бұрын
Must be nice to be a babe to someone :,) Ya’ll are goals
@koustavmondal24582 ай бұрын
Can you please make a video on how did u setup tailwind+daisyui in ur go project !!??
@dejanduh26452 ай бұрын
For such example, you could show atomic values as a replacement for mutex
@EduarteBDO2 ай бұрын
that is pretty interesting
@kyngcytro2 ай бұрын
Had the same experience with Python. Or at least it was close.
@oumardicko55932 ай бұрын
if you wrote test cases and run them concurrently and if your code is not concurrent safe, the compiler will throw an error
@Jesse-x8p2 ай бұрын
"...share memory by communicating " is something of a mantra among go devs. You should use channels when dealing with these kinds of situations as channels also synchronise(only unbuffered channels). It doesn't hurt performance as much as mutexes and they are concurrency safe(no race conditions or data races). Also, you should always tests ;)
@anatolio79752 ай бұрын
Could also use an atomic integer
@random-Automation-232422 ай бұрын
is there a way to import node modules in k6?
@neociber242 ай бұрын
Multithreading is always a footgun except in Rust.
@notusperson46672 ай бұрын
Elaborate more please
@filipg42 ай бұрын
Yes, because in Rust it's a footcrab instead.
@baxiry.2 ай бұрын
On the contrary. Rust apps are full of data race. Go apps are cleaner.
@OnFireByte2 ай бұрын
yeah you have to choose between footgun or arc
@Astrelune2 ай бұрын
Rust cultist is everywhere
@heheboy98632 ай бұрын
What name your Vs code theme?
@meharjeetsingh52562 ай бұрын
Does go have any atomics to make things faster?
@BarakaAndrew2 ай бұрын
Yap, there's atomic package built in.
@hamm89342 ай бұрын
I wouldnt say this is the “biggest” footgun. This is just a learning pain of going with a little lower level of a language. Struct properties being optional is probably a bigger footgun. It basically forces you to either check for nils on all props every time, or create contractors for all structs with arguments for all required properties. Everyone was asking for generics back in the day, but i still stand by this being the biggest weak point of Go. I find the constructor convention isnt too bad and gets the job done, it just seems like such an easy win for them to add a compiler config for never nil properties or to add an optional syntax of some kind.
@WebDevCody2 ай бұрын
it's a footgun, a powerful tool of the language you could easily screw yourself over with if not careful
@hamm89342 ай бұрын
@@WebDevCody im not one for splitting hairs over definition pedantics, and i dont disagree with the havoc this could cause. However, i just dont think this is the “biggest” (as the original video title stated) weakness of Go. Sure, you might face this problem starting out if you’re new to concurrency or channels at a lower level, but once you learn them, these issues dont really come up frequently in practice. As you write more Go, whenever you see a go routine you just kinda build up a mental note to check for referencing something outside of the channel scope or check for needing a mutex. However, nil pointers and seg faults in Go come up quite often, especially when communicating with an external API or poorly crafted Go bindings. There’s a reason folks call null a “billion dollar mistake.” Having non-required struct properties is a far bigger footgun in Go in my perspective, having used Go as my primary backend language for coming up on 4 years. Nil pointers are just in your face constantly in Go, while incorrectly passing data between channels and the main thread or using a mutex isnt as frequent of a problem.
@WebDevCody2 ай бұрын
@@hamm8934 I went ahead and updated the title anyway 🤣 too many people didn’t like the word foot gun and I never said the word once in the video anyway. I haven’t used go long enough to know the true footguns, so I’ll just avoid the word
@hamm89342 ай бұрын
@@WebDevCody fair :) great video none the less Hope you keep liking go and dont give up just yet on htmx and templ! Cheers
@WebDevCody2 ай бұрын
@@hamm8934 I’m trying to hang on but I’m missing nextjs already 😆
@damluar15 күн бұрын
What IDE is that?
@Heshamelfakharani2 ай бұрын
are you using an ORM?
@WebDevCody2 ай бұрын
Nah just SQL directly
@BarakaAndrew2 ай бұрын
You are getting there, next up interfaces then always passing interfaces to structs, Go is done.
@ktappdev2 ай бұрын
All respect to you sir, but I wouldn't call this a foot gun.
@WebDevCody2 ай бұрын
what would you call it?
@banafish2 ай бұрын
you've switched to maybe the ugliest vscode theme on all of youtube, but I'm still watching :)
@EverydayElk2 ай бұрын
for one thing, don't use globals in Go
@muhammadzikri9002 ай бұрын
theme vscode use ?
@tanko.reactions176Ай бұрын
this is not a go issue, this is a skill issue. most javascript developers never encounter this class of problem because js is single threaded. this is one of the plethora of reasons why js devs are not real devs. you dont even know what you dont know.
@WebDevCodyАй бұрын
That’s cute
@meni1818182 ай бұрын
atomic
@meni1818182 ай бұрын
btw you are the best
@DanielBergholz2 ай бұрын
Have you heard about our lord and savior Elixir? There is no race conditions there due to each process being 100% isolated from each other. That’s the power of a truly functional programming language