Why understanding concurrency in Go is so important

[@clayton.schneider]

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.

[@twitchizle]

Pass by pointer if its object, pass by value if its primitive.

[@keshavakumar9828]

@@twitchizle pass by pointer if its concurrent, be it primitive or object

[@romarioputra3775]

yep, immutable data is thread safe

[@DonDikaio]

"Now that I'm a professional Go Developer" how can you not love the attitude.

[@lifewithyousof]

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-3961]

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.

[@vladlazar94]

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.

[@Fullflexno]

Thank you for this! Super cool!

[@k98killer]

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.

[@zendr0]

Good one Cody! Look forward for more

[@Frostbytedigital]

Cody getting lots of love from prime lately. Wonder if this one will get picked up too.

[@C4CH3S]

Yes, this is why you should avoid side effects as much as possible in golang.

[@erikslorenz]

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.

[@lemurza5236]

I'm not sure i consider the a Go footgun?

[@spencerwilson-softwaredeve6384]

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

[@hamm8934]

This is more so learning pains when going a little lower level

[@WebDevCody]

Got em

[@Frostbytedigital]

@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-ai]

this is just a skill issue not a footgun by any means its designed perfectly

[@tmanley1985]

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.

[@abhishekmehandiratta4241]

If you're sharing primitives across goroutines, you can use the atomic package which I've heard is more performant.

[@khazixfangirl6087]

For this little example, I think the incrementing will work if you make it atomic

[@Simbysolo]

Thanks for pointing this out

[@arturfil]

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.

[@SeibertSwirl]

Ugh finally lol love ya babe! Great job as usual ❤

[@WebDevCody]

You’re the best!

[@Yesquiteindeed321321]

Must be nice to be a babe to someone :,) Ya’ll are goals

[@koustavmondal2458]

Can you please make a video on how did u setup tailwind+daisyui in ur go project !!??

[@dejanduh2645]

For such example, you could show atomic values as a replacement for mutex

[@EduarteBDO]

that is pretty interesting

[@kyngcytro]

Had the same experience with Python. Or at least it was close.

[@oumardicko5593]

if you wrote test cases and run them concurrently and if your code is not concurrent safe, the compiler will throw an error

[@Jesse-x8p]

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

[@anatolio7975]

Could also use an atomic integer

[@random-Automation-23242]

is there a way to import node modules in k6?

[@neociber24]

Multithreading is always a footgun except in Rust.

[@notusperson4667]

Elaborate more please

[@filipg4]

Yes, because in Rust it's a footcrab instead.

[@baxiry.]

On the contrary. Rust apps are full of data race. Go apps are cleaner.

[@OnFireByte]

yeah you have to choose between footgun or arc

[@Astrelune]

Rust cultist is everywhere

[@heheboy9863]

What name your Vs code theme?

[@meharjeetsingh5256]

Does go have any atomics to make things faster?

[@BarakaAndrew]

Yap, there's atomic package built in.

[@hamm8934]

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.

[@WebDevCody]

it's a footgun, a powerful tool of the language you could easily screw yourself over with if not careful

[@hamm8934]

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

[@WebDevCody]

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

[@hamm8934]

@@WebDevCody fair :) great video none the less Hope you keep liking go and dont give up just yet on htmx and templ! Cheers

[@WebDevCody]

@@hamm8934 I’m trying to hang on but I’m missing nextjs already 😆

[@damluar]

What IDE is that?

[@Heshamelfakharani]

are you using an ORM?

[@WebDevCody]

Nah just SQL directly

[@BarakaAndrew]

You are getting there, next up interfaces then always passing interfaces to structs, Go is done.

[@ktappdev]

All respect to you sir, but I wouldn't call this a foot gun.

[@WebDevCody]

what would you call it?

[@banafish]

you've switched to maybe the ugliest vscode theme on all of youtube, but I'm still watching :)

[@EverydayElk]

for one thing, don't use globals in Go

[@muhammadzikri900]

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

[@meni181818]

atomic

[@meni181818]

btw you are the best

[@DanielBergholz]

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

[@SeibertSwirl]

FIRRRSTTTT

[@WebDevCody]

Love you!

[@salman0ansari]

channels are better approach to do this

[@niklavskarklins9663]

The theme has to go..