Go hits the concurrency nail on the head
eli.thegreenplace.net
Go hits the concurrency nail on the head
1–10 of 318 posts
Re: Go hits the concurrency nail on the head
#2> Programming with threads is hard - it's hard to synchronize access to data structures without causing deadlocks; it's hard to reason about multiple threads accessing the same data, it's hard to choose the right locking granularity, etc.
It's almost as if we need a language that has a focus on data races, concurrency and fearless threading.
Re: Go hits the concurrency nail on the head
#3According to the author Go make concurrent programming "the best experience, by far, compared to other popular programming languages today."
I beg to differ. I fail to see why I should choose Go over Elixir/Erlang for concurrency. Elixir's cuncurrency mechanisms are at least as good — and I would argue better — than Go's, and Elixir as a language has an expressiveness that Go lacks.
Re: Go hits the concurrency nail on the head
#4According to the author Go make concurrent programming "the best experience, by far, compared to other popular programming languages today." I beg to differ. I fail to see why I should choose Go over Elixir/Erlang for concurrency. Elixir's cuncurrency mechanisms are at least as good — and I would argue better — than Go's, and Elixir as a language has an expressiveness that Go lacks.
I think the main argument is that Elixir isn't as mainstream which is a fair point.
That said I agree with everything, Erlang pioneered in this space and has shown to scale very well[1] in a proven way over the last few decades.
[1] https://phoenixframework.org/blog/the-road-to-2-million-webs...
Re: Go hits the concurrency nail on the head
#5According to the author Go make concurrent programming "the best experience, by far, compared to other popular programming languages today." I beg to differ. I fail to see why I should choose Go over Elixir/Erlang for concurrency. Elixir's cuncurrency mechanisms are at least as good — and I would argue better — than Go's, and Elixir as a language has an expressiveness that Go lacks.
I think most reasonable people wouldn't have trouble defending a position that Elixir isn't a particularly "popular" language - at least compared to Go.
Re: Go hits the concurrency nail on the head
#6> Programming with threads is hard - it's hard to synchronize access to data structures without causing deadlocks; it's hard to reason about multiple threads accessing the same data, it's hard to choose the right locking granularity, etc. It's almost as if we need a language that has a focus on data races, concurrency and fearless threading.
Rust evangelism strike force strikes again :)
I thought of Erlang initially, and so did others in the thread.
Re: Go hits the concurrency nail on the head
#7> Programming with threads is hard - it's hard to synchronize access to data structures without causing deadlocks; it's hard to reason about multiple threads accessing the same data, it's hard to choose the right locking granularity, etc. It's almost as if we need a language that has a focus on data races, concurrency and fearless threading.
Actually it's very easy to avoid data-structure related deadlocks:
- avoid holding two locks simultaneously: that guarantees no deadlocks.
- if you have to hold several locks, always acquire them in the same order in all scenarios.
The "avoid holding multiple locks" rule also harmonizes very well with "minimize the durations/sizes of critical regions". That is, hold a lock over the minimum number of machine instructions necessary. That reduces lock contention, promoting better concurrency.
Of course, we don't get anything free and easy. Not holding multiple locks means that you can't lock in some consistent condition across multiple structures to do an atomic update. Any time you let go of a lock to go do something elsewhere and re-acquire the lock, the "world has changed". If the code hangs on to any previous assumptions about the state (e.g. cached info in local variables), there will be a bug.
Re: Go hits the concurrency nail on the head
#8> Programming with threads is hard - it's hard to synchronize access to data structures without causing deadlocks; it's hard to reason about multiple threads accessing the same data, it's hard to choose the right locking granularity, etc. It's almost as if we need a language that has a focus on data races, concurrency and fearless threading.
Hah! Good one. To anyone else not in on the joke, parent is referring to the language that is often discussed on HN and known for having a sometimes overly enthusiastic community, Pony: https://www.ponylang.io/
Re: Go hits the concurrency nail on the head
#9> Programming with threads is hard - it's hard to synchronize access to data structures without causing deadlocks; it's hard to reason about multiple threads accessing the same data, it's hard to choose the right locking granularity, etc. It's almost as if we need a language that has a focus on data races, concurrency and fearless threading.
Is this a RUST reference?
Re: Go hits the concurrency nail on the head
#10According to the author Go make concurrent programming "the best experience, by far, compared to other popular programming languages today." I beg to differ. I fail to see why I should choose Go over Elixir/Erlang for concurrency. Elixir's cuncurrency mechanisms are at least as good — and I would argue better — than Go's, and Elixir as a language has an expressiveness that Go lacks.
I think most reasonable people wouldn't have trouble defending a position that Elixir isn't a particularly "popular" language - at least compared to Go.
I agree Go is more popular than Elixir — but is it actually a popular language? At least I wouldn't consider it mainstream in the sense Java, C# and Python are.