5 ms·
Thanks for the explanation. Forgive my lack of knowledge, but can it not be solved by using parallelism instead of concurrency/threads? I thought Go has first c
by westoque 7y ago
Thanks for the explanation. Forgive my lack of knowledge, but can it not be solved by using parallelism instead of concurrency/threads? I thought Go has first class primitives to be able to do this?
- therealdrag0 7y ago> parallelism instead of concurrency/threads. What do you mean? These seem synonymous to me. > I thought Go has first class primitives to be able to do this? TBH I'm only 1 week into learning Go myself (coming from Java/Scala/JS/etc). But it looks like the article used what Go offers. They used the atomic package which says, "provides low-level atomic memory primitives useful for implementing synchronization algorithms." https://golang.org/pkg/sync/atomic/ https://golang.org/pkg/sync/atomic/
- westoque 7y ago> What do you mean? These seem synonymous to me. What I meant was similar to this talk: https://blog.golang.org/concurrency-is-not-parallelism https://blog.golang.org/concurrency-is-not-parallelism where there is also a load balancer example around 20:20 and using go channels (the primitive I’m pertaining to)
- biggestdecision 7y agoChannels aren't a way to avoid mutexes/locking, they are just meant to be simpler to write & reason about. Channels are implemented using mutexes under the hood.