The concurrency and threading in Go just feels like magic compared to every other language. I'm a goroutine addict and I refuse to be rehabilitated.
Just from observations over the years, I don't think there's any other language quite like this, in terms of how things can end up happening in any thread.
show comments
voidfunc
Ive been writing Go for over a decade and I still feel like I never quite "got" channels. Every time I use them I need to go consult the manual, and none of the patterns feel obvious which is weird considering the rest of the language feels very obvious.
Too many years of Java and managing Threads and Runnables probably rotted my brain.
show comments
kccqzy
For many people, besides learning what you should do, it is more helpful to read anti-patterns and things you should not do in Go, and none is better than this article about data race patterns in Go: https://www.uber.com/us/en/blog/data-race-patterns-in-go/
dzogchen
Ahh you got me. Finished the first chaper of the 'free online' Gist of Go book, then in the second chapter it turns out the first chapter was a freebie.
awfm9
I used to do this, and do it well. Nowadays, I avoid it like the plague. Not just because of the advent of AI agents, but also. I usually try to condense the core business logic of the application into a tight sequencer, and then every type of slower workload has a manager for it, with queue, dispatching. All logic remains linear, easy to review and follow. Concurrency is basically just handled at the level of kicking off some work, and then funneling the result back into the sequencer. Easier to test, highly scalable concurrency.
jeffrallen
This is fine, but it's too bad it did not mention the cardinal rule of goroutines on prod, which is "before starting a goroutine make damn sure you know how it will stop".
Goroutine leaks in prod are no laughing matter. They are difficult to debug without killing the process, and that's only useful if you are sure you're going to get stderr to get the full traces of all goroutines.
Jeeetendra
honestly the hard part of go concurrency was never starting goroutines, it's making cancellation and shutdown behave. nice to see context, races and diagnostics in one runnable place.
show comments
Segv77
Go concurrency seems simple on the surface, but mastering select and proper error handling takes practice. Good to see this topic distilled.
fizlebit
One thing I always found more work than I would expect is when you have a graph of operations, think a Makefile, but a bit dynamic. For this model completable futures and executors seem to work well (provided the graphs is smallish), but golang is (or perhaps before generics) just was difficult.
show comments
rienbdj
Is a Go channel equivalent to a Haskell tvar ?
show comments
phplovesong
Go has a really good concurrency story. Its one of the best ones out there. Some langs have async/await (usually sucks) and some nothing att all (like php)
The concurrency and threading in Go just feels like magic compared to every other language. I'm a goroutine addict and I refuse to be rehabilitated.
Just from observations over the years, I don't think there's any other language quite like this, in terms of how things can end up happening in any thread.
Ive been writing Go for over a decade and I still feel like I never quite "got" channels. Every time I use them I need to go consult the manual, and none of the patterns feel obvious which is weird considering the rest of the language feels very obvious.
Too many years of Java and managing Threads and Runnables probably rotted my brain.
For many people, besides learning what you should do, it is more helpful to read anti-patterns and things you should not do in Go, and none is better than this article about data race patterns in Go: https://www.uber.com/us/en/blog/data-race-patterns-in-go/
Ahh you got me. Finished the first chaper of the 'free online' Gist of Go book, then in the second chapter it turns out the first chapter was a freebie.
I used to do this, and do it well. Nowadays, I avoid it like the plague. Not just because of the advent of AI agents, but also. I usually try to condense the core business logic of the application into a tight sequencer, and then every type of slower workload has a manager for it, with queue, dispatching. All logic remains linear, easy to review and follow. Concurrency is basically just handled at the level of kicking off some work, and then funneling the result back into the sequencer. Easier to test, highly scalable concurrency.
This is fine, but it's too bad it did not mention the cardinal rule of goroutines on prod, which is "before starting a goroutine make damn sure you know how it will stop".
Goroutine leaks in prod are no laughing matter. They are difficult to debug without killing the process, and that's only useful if you are sure you're going to get stderr to get the full traces of all goroutines.
honestly the hard part of go concurrency was never starting goroutines, it's making cancellation and shutdown behave. nice to see context, races and diagnostics in one runnable place.
Go concurrency seems simple on the surface, but mastering select and proper error handling takes practice. Good to see this topic distilled.
One thing I always found more work than I would expect is when you have a graph of operations, think a Makefile, but a bit dynamic. For this model completable futures and executors seem to work well (provided the graphs is smallish), but golang is (or perhaps before generics) just was difficult.
Is a Go channel equivalent to a Haskell tvar ?
Go has a really good concurrency story. Its one of the best ones out there. Some langs have async/await (usually sucks) and some nothing att all (like php)