[abetusk]

Concurrency is a programming abstraction that conceptually allows multiple independent processes to run at the same time using scheduling. For example, running ten programs at once with only a single CPU. Concurrency is effectively CPU scheduling with maybe some other concepts of communication between processes for coordination.

Parallelism is running processes at the same time.

The driving motivation behind concurrency, as far as I can tell, is that it's a concept that can help reason about complex tasks with the added benefit of being able to take advantage of parallelism.

My problem with Pike's advocacy for concurrency, and Golang in particular, is that it's an abstraction that imposes a world view on what's a good programming paradigm and, more practically, how to take advantage of parallelism, both of which have limited utility compared with considering parallelism directly.

My opinion rather than some abstraction that imposes a world view on how to take advantage of parallelism, it's better to use how people actually take advantage of parallelism as a basis for abstraction.

I think Golang is a fine language but we now have 14+ years of hindsight to see how well it's fared and how much it's influenced the compute landscape. In my opinion, the "concurrency not parallelism" misses the simple issue that we want things to go fast. Which has had more influence, Golang's idea of concurrency or taking advantage of GPU parallelism? I think the answer is clearly taking advantage of GPU parallelism.

[zamalek]

> For example, running ten programs at once with only a single CPU. Concurrency is effectively CPU scheduling with maybe some other concepts of communication between processes for coordination.

This is called preemptive multitasking. This is like declaring that "sorting a list is quicksort." This can realize concurrency.

The reason that this is important is that cooperative multitasking (async/cps/fibers/safe points) is also concurrency. And I'm sure there are other exotic forms of concurrency that I'm not aware of beyond multitasking.

Concurrency is a property of a program/system, not a mechanism.

[neerajdotname2]

Concurrency is like "con man". That's how I remember it. https://www.bigbinary.com/blog/gvl-in-ruby-and-its-impact-in...

[CyberDildonics]

Parallelism is like data structures. There are many different ways to do it and people should not be trying to do it themselves in a bespoke way on every program.

Having one way built into the language is like a language using a hash map for everything. It might be convenient when it works, but the idea that there is one best way is only a little better than people fumbling their way through it from scratch.

[abetusk]

I agree with a lot of this sentiment but it assumes a level of stability so that standardization can be effective. Standardization before stabilization has the potential to cripple efficiency with inefficient abstractions.

One benefit of a programming paradigm is that it can allow for an increase in speed of software development at a marginal cost of run-time efficiency, but if the paradigm is so out of step with the underlying hardware, the run-time efficiencies can be orders of magnitude slower than a bespoke way.

Standardization and abstraction are most effective when there is data about which bespoke ways work the best. Choosing standardization and abstraction before experimenting on the solution space rarely works well.

[CyberDildonics]

I'm not sure what you mean about standardization, just like data structures parallelism techniques can be done through libraries, they don't need to be integrated into a language if the core tools are there.

[nwhnwh]

What languages do you like?