Nobody can agree on them so let's just assume they mean the same thing and move to more interesting discussions, shall we?
I don't think it is that complicated.
Concurrency is a property of the algorithm or problem space. Things can happen independent of each other. Two or more client requests can read a file. Logically they don't have to wait for each other. There is no sequential dependence. These could be represented in code as two threads, two futures, promises, Goroutines, Tasks, callback chains, actors etc <insert favorite concurrency primitive>.
Parallelism is a property of the execution environment. "Can the concurrent parts of the program execute at the same time?" The machine happens to have 2 CPU cores and two requests arriving at the same time can execute at the some time. Or it has only one CPU and even though they can execute at the same time, they don't. One might be blocked waiting for another or they might be preempted by the scheduler every milliseconds, execute a bit, then switch to another.
EDIT: Here is Joe Armstrong's interpretation. Which is similar to this and includes a cute diagram with coffee machines:
http://joearms.github.io/2013/04/05/concurrent-and-parallel-...
He knows what he is talking about, he is the father of Erlang.
They don't mean the same thing, and that is a poisonous attitude to have. Parallelism is about performance. Concurrency is about synchronization. The difference might not matter to you, but for certain things (programming language design, library design, system architecture) it is paramount.
One thing nearly everyone agrees on: a single-core processor cannot do parallelism, but it's perfectly capable of concurrency. How do you reconcile that with your view that they are the same?
The difference matters very much to me, what is silly is that nobody agrees on which one is concurrency and which one is parallelism. In this thread alone, I found two people with a different definition from yours.
Concurrency in Go is based on Communicating Sequential Processes (CSP) by Hoare; this was originally published in 1978. Reading CSP you see all the ideas are abstractly formalized in math terms: there really is no notion of multiple streams of execution occurring at the same time (i.e., multiple hardware threads). So, a distinction is made between things cooperating (concurrency in their parlance) and things running at the same time (parallelism).
To continue this idea, parallelism, again using their terms, really is an implementation of the more abstract concept of concurrency. That is, given a description of concurrent processes communicating you can run them in parallel (and reason about their correctness).
If you do not make the distinction, regardless of the terms you use, you remove the layers of abstraction necessary to reason about complex systems (separation of high level concepts and their implementation).
Concurrency and parallelism need different abstractions; try using actors for parallelism or MPI for concurrency! If they mean the same thing, how do we distinguish between them as is absolutely necessary?
Erlang
> or MPI for concurrency
Go uses channels as a message passing interface for the "composition of independently executing processes"
Saying concurrency and parallelism are equivalent basically invalidates all design decisions made by these systems.
They make full use of all CPU cores since they implemented SMP support: http://erlang.2086793.n4.nabble.com/Some-facts-about-Erlang-...
> ditto for Go Channels
Go has a user-space M:N scheduler that distributes its "goroutines" among multiple OS threads and therefore multiple cores.
Erlang is about both.
Those are not either or. Concurrency sits at a higher level of abstraction -- at the problem domain. "I'll create an actor for this request, another actor for that, maybe another one for monitoring". These are concurrent units.
Parallelism happens if my machine has more than one CPU and these concurrency units will actaully execute at the same time. Or maybe I have a single CPU only. I'll have not parallelism. They'll be sequenced and scheduled in and out of the single CPU in some small or larger time slices. But they'll not execute in parallel.
So maybe I am running my machine in 1989 (Erlang was doing work back then too) with only a single CPU. I still want to create many concurrent units of work. Or maybe I am running in 2015 and I have 64 core machine and I specifically choose Erlang because I expect to get lots of parallelism for cheap as my concurrent units are largely independent of each other.
Concurrency is necessary property of the work as defined, parallelism is an opportunistic property. Confusing the two concepts can lead to people trying to do HPC work with Erlang.
If you are working on an HPC workload, you wouldn't choose Erlang, but you might get a happy speed up for a standard distributed application. Parallelism is strictly about performance, concurrency is about correctness. When you go off and do a HPC or big data program, you might play with MPI, CUDA, MapReduce, or maybe just roll something yourself. No one goes...we should do that in Erlang! Likewise, when you go off and do a concurrent distributed system, Actors make a lot of sense given the concurrency requirements involved (who would think of using CUDA for that?).
Perhaps the problem is not about concurrency and parallelism, but different kinds of computations.
Erlang uses parallelism for fault-tolerance purposes, because you need several physical machines running in parallel on different sites to achieve outstanding fault-tolerance. MPI/CUDA/MapReduce uses parallelism for performance reasons.
I do not know if it is true as I couldn't find the source, but I remember reading that aircrafts run all computations in parallel on three different architectures (Power and two others), using three different algorithms, to ensure that the results are not compromised either by a faulty algorithm, or a CPU bug. In that case parallelism is used for safety.
From wiki [1]:
> Parallel computing is a form of computation in which many calculations are carried out simultaneously, operating on the principle that large problems can often be divided into smaller ones, which are then solved concurrently ("in parallel").
...
Parallel computer programs are more difficult to write than sequential ones,[5] because concurrency introduces several new classes of potential software bugs, of which race conditions are the most common.
And the article for concurrency [2]:
> In computer science, concurrency is a property of systems in which several computations are executing simultaneously, and potentially interacting with each other. The computations may be executing on multiple cores in the same chip, preemptively time-shared threads on the same processor, or executed on physically separated processors.
[1] http://en.wikipedia.org/wiki/Parallel_computing
[2] http://en.wikipedia.org/wiki/Concurrency_(computer_science)
Concurrency is a problem (doing things at the same time leads to resource contention), while parallelism is a performance technique. Fault tolerance is something else altogether, and can apply to concurrency problems as well as parallel speedups. Doing things in parallel as a form of redundancy isn't really parallelism...in general, the word parallelism != "in parallel" while concurrency != "concurrently," though they are definitely related.
Phew.
You're right that Erlang is not the best choice for HPC, but you're wrong about the motive. There's nothing inherently inefficient about the actor model. Erlang's low performance comes from unrelated technical choices (bytecode running on a VM, shitty string handling, etc.).
Look, you can implement the actor model using MPI for inter-actor communication: https://github.com/poconbhui/mpi-actor
And hard-core HPC people are talking about the actor model in Cray's Chapel language: http://chapel.cray.com/education/cs380p-actors.pdf
Shared memory is also quite nice when you can afford it in non-distributed settings (never use MPI on just one machine!). If your problem can fit in GPU memory, CUDA will do wonders.
Is chapel still around? I thought the Darpa money ran out.
1. http://en.wikipedia.org/wiki/Concurrent_computing#Introducti...
2. http://docs.oracle.com/cd/E19455-01/806-5257/6je9h032b/index...
I never said that, just that a lot of people have different definitions for these words, all contradicting each other. So in effect, these words have become meaningless.