[justin_vanw]

A distinction isn't necessarily useful.

[jjtheblunt]

no kidding...it's become some convention in the last 15 or so years, but in the early 1990s working on supercomputers i had never heard of it.

[RobertoG]

In Python 3 there is the ayncio module that is concurrent (logical execution is not sequential) but not parallel (only one thread). I found the distinction very useful when I started to look into it.

[dboreham]

I seem to remember it coming from Golang people.

[dagw]

I seem to remember it coming from Golang people.

The discussion existed around languages like Python, long before Golang showed up on the scene.

[Thaxll]

That's what people using CPython think.

[justin_vanw]

I think most CPython folks are quite annoyed by the lack of concurrent execution! The GIL sucks.

If you ever ask Racket-lang folks about threads they will lecture you about concurrency vs parallelism endlessly, it's like a mantra they repeat to avoid realizing there is a problem.

[chrisseaton]

The GIL prevents parallelism but not concurrency - that’s the whole point of this discussion.

[justin_vanw]

I said concurrent execution. When being pedantic it is important to read carefully.

Being super careful about 'parallel' and 'concurrent' is super, super pedantic and pointless. They are synonyms. If two things are running concurrently, they are running in parallel. If two things are running in parallel, they are running concurrently. These are terrible words to overload with very careful definitions.

When people talk about 'concurrency' using the super careful pedantic definition, they just mean that it's possible to execute code while at the same time blocking on system calls. This isn't some kind of great feat and any language that can't do it is a toy. There is absolutely no reason to act like 'concurrency' using this definition is in any way special or worth even mentioning.

But that's not the point, is it? People get defensive about their favorite languages, so when faced with valid criticisms like "the GIL prevents you from running Python code in parallel" (which is a completely valid and actually pretty huge defect when modern computers have many cores on average) instead of just admitting the deficiency a person can be defensive and respond with stupid lectures about 'concurrency' and 'parallelism'.

[axaxs]

I always used to read that, but in practice, threading and multiprocessing modules work just fine for concurrency and parallelism, respectively. What's the issue?

[Nursie]

The threading module is restricted by the "Global Interpreter Lock" and cannot run truly concurrently.

My first run-in with this was when I wrote a toy brute-force birthday attack as part of a course I was doing, and realised it was only utilising one core.

The multiprocessing module works as expected, sure.