4 ms·

See also: Concurrency is not Parallelism http://blog.golang.org/concurrency-is-not-parallelism http://blog.golang.org/concurrency-is-not-parallelism You can st

by cmelbye 11y ago

See also: Concurrency is not Parallelism http://blog.golang.org/concurrency-is-not-parallelism http://blog.golang.org/concurrency-is-not-parallelism You can still benefit from the "claims of the language", even if code isn't running in parallel.

rsc 11y ago
While this is technically true, it doesn't seem like that helpful a response to say "well you were getting benefits, just not this one". Until now you've had to know to ask for parallelism; it should have been there by default, and soon (I hope) it will be.
- jlouis 11y ago
  This is, incidentally, also the Erlang default. Interrogate the system and if it is SMP capable, run with SMP enabled.
- cmelbye 11y ago
  Oh, I agree 100%. I was just as confused as he was when I first started using Go, and I'm very excited that this change might finally happen. However, I think calling my response "technically true" is selling Go's concurrency primitives a little short. They enable a really great programming model, which makes it much easier to express certain ideas in code. And I/O-bound programs benefit even if GOMAXPROCS=1. I didn't understand that subtlety when I first started with Go, and it seems like GP commenter (and probably other HN readers) didn't either. "Concurrency is not parallelism" is very helpful in explaining that, which is why I linked to it.
tossawayppp 11y ago
A distinction without meaning is kind of dumb. In popular parlance parallelism and concurrency are approximately the same thing.
- Jtsummers 11y ago
  You aren't wrong, but it does make it difficult to discuss with people. At least within the programming field it's useful to have two terms with distinct meanings to discuss the topic. Consider the terms accuracy and precision [0], where again the popular understanding is that they're (essentially) synonymous. But within the scientific and engineering world that uses the terms the distinction is critical. EDIT: Verification and validation [1] are another pair of terms where the distinction is important for industry, but popular understanding often mixes them up. [0] http://en.wikipedia.org/wiki/Accuracy_and_precision http://en.wikipedia.org/wiki/Accuracy_and_precision [1] http://en.wikipedia.org/wiki/Verification_and_validation http://en.wikipedia.org/wiki/Verification_and_validation
- enneff 11y ago
  When having a technical discussion we should interpret technical terms with their precise meaning. Rob Pike gave a good talk about this: http://blog.golang.org/concurrency-is-not-parallelism http://blog.golang.org/concurrency-is-not-parallelism
- bkeroack 11y ago
  It wasn't very long ago (before the multicore era) that essentially nothing running on personal computers was truly parallel. Yet multithreaded applications (concurrency) worked just fine.
- Igglyboo 11y ago
  It does have meaning. An obvious difference is that you can have concurrency with one processor but not parallelism requires at least two.
  - chrisseaton 11y ago
    > parallelism requires at least two Interestingly there is one example of parallelism without concurrency and with just one processor and just one core - vector instructions. Although it would be a breathtakingly good compiler that could emit vector instructions to schedule two goroutines in parallel
- 11y ago
ubernostrum 11y ago
What I do not want in a programming language is for it to advertise features which are subject to confusion in common parlance, then say "I did what I said, you just weren't smart enough to understand what I said". My reaction is somewhat like this XKCD: https://xkcd.com/169/ https://xkcd.com/169/
- tankenmate 11y ago
  The debate over concurrency vs parallelism hit its peak in the mid 1990s, well before Go came along. I remember having arguments with fellow students (and the occasional professor) at university about how it affects memory allocations (stack vs heap), virtual memory layout (the thread vs coroutine stack being one of the bigger issues; Linux's early introduction of mremap was particularly handy) the OS scheduler, etc. It's not just a Go / language feature thing.

by cmelbye 11y ago

rsc 11y ago

While this is technically true, it doesn't seem like that helpful a response to say "well you were getting benefits, just not this one". Until now you've had to know to ask for parallelism; it should have been there by default, and soon (I hope) it will be.

jlouis 11y ago
This is, incidentally, also the Erlang default. Interrogate the system and if it is SMP capable, run with SMP enabled.
cmelbye 11y ago
Oh, I agree 100%. I was just as confused as he was when I first started using Go, and I'm very excited that this change might finally happen. However, I think calling my response "technically true" is selling Go's concurrency primitives a little short. They enable a really great programming model, which makes it much easier to express certain ideas in code. And I/O-bound programs benefit even if GOMAXPROCS=1. I didn't understand that subtlety when I first started with Go, and it seems like GP commenter (and probably other HN readers) didn't either. "Concurrency is not parallelism" is very helpful in explaining that, which is why I linked to it.

tossawayppp 11y ago

A distinction without meaning is kind of dumb. In popular parlance parallelism and concurrency are approximately the same thing.

Jtsummers 11y ago
You aren't wrong, but it does make it difficult to discuss with people. At least within the programming field it's useful to have two terms with distinct meanings to discuss the topic. Consider the terms accuracy and precision [0], where again the popular understanding is that they're (essentially) synonymous. But within the scientific and engineering world that uses the terms the distinction is critical. EDIT: Verification and validation [1] are another pair of terms where the distinction is important for industry, but popular understanding often mixes them up. [0] http://en.wikipedia.org/wiki/Accuracy_and_precision http://en.wikipedia.org/wiki/Accuracy_and_precision [1] http://en.wikipedia.org/wiki/Verification_and_validation http://en.wikipedia.org/wiki/Verification_and_validation
enneff 11y ago
When having a technical discussion we should interpret technical terms with their precise meaning. Rob Pike gave a good talk about this: http://blog.golang.org/concurrency-is-not-parallelism http://blog.golang.org/concurrency-is-not-parallelism
bkeroack 11y ago
It wasn't very long ago (before the multicore era) that essentially nothing running on personal computers was truly parallel. Yet multithreaded applications (concurrency) worked just fine.
Igglyboo 11y ago
It does have meaning. An obvious difference is that you can have concurrency with one processor but not parallelism requires at least two.
- chrisseaton 11y ago
  > parallelism requires at least two Interestingly there is one example of parallelism without concurrency and with just one processor and just one core - vector instructions. Although it would be a breathtakingly good compiler that could emit vector instructions to schedule two goroutines in parallel
11y ago

ubernostrum 11y ago

What I do not want in a programming language is for it to advertise features which are subject to confusion in common parlance, then say "I did what I said, you just weren't smart enough to understand what I said". My reaction is somewhat like this XKCD: https://xkcd.com/169/ https://xkcd.com/169/

tankenmate 11y ago
The debate over concurrency vs parallelism hit its peak in the mid 1990s, well before Go came along. I remember having arguments with fellow students (and the occasional professor) at university about how it affects memory allocations (stack vs heap), virtual memory layout (the thread vs coroutine stack being one of the bigger issues; Linux's early introduction of mremap was particularly handy) the OS scheduler, etc. It's not just a Go / language feature thing.