Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Parallelism is when you run your program on multiple processors. Semantics of your program does not change whether you run it on single processor or multiple processors.

Concurrency is when you write your program using multiple threads. Your program looks and means vastly different if you use threads.

You use concurrency not for performance gain, but for clarity of your program. You use parallelism for performance gain, to utilize all your processors.



That can't be right. Threads don't improve the clarity of most programs; they're notoriously unclear.


I agree with you, but not in the way you intended. I suspect that most programming language implementations of concurrency are bolt-ons and are a bit broken in terms of their human (programmer) interface design.


On the contrary, I think proper concurrency constructs, including threads, do improve the clarity of programs. Part of the problem in reasoning about threads is a lack of useful primitives. Multithreaded programming in Java? For me, at least, it's tough. In Erlang? Trivial. In Clojure, if you're willing to deal with the slowness of the STM, it can be beautifully simple.


Erlang and Clojure don't have threads in the common meaning of the term (http://en.wikipedia.org/wiki/Thread_(computing)). They are reactions against programming with threads.

You can expand the term "thread" to mean "concurrency in general" but even then it isn't true that the main purpose of writing concurrent code is clarity. When people say "look at this concurrent program I wrote" they rarely [1] say "look at how well the code expresses the problem". What they overwhelmingly say is "look at this benchmark".

[1] Joe Armstrong talks about how Erlang lets you represent processes more like they happen in the real world. But that's a niche view. Most people think about concurrency as a platform issue, where the platform is multicore hardware or distributed systems, and otherwise wouldn't bother with it.


Clojure absolutely has threads, in the common meaning of the term. I use futures all over the place in my code, and it's quite idiomatic.

(future (do (foo 1) (bar 2)) Runs the expression on another thread. Futures intentionally compose well with the built-in clojure concurrency tools.

Clojure has no dislike of threads. It scorns locks, and code that is safe in one thread, but unsafe in multi-threaded situations.


Ah, thanks for the correction and teaching me something.


Erlang and Clojure are multithreaded. Clojure offers full access to Java-style (Thread. (fn [] ...)), j.u.c Executors, and Clojure-specific threadpools for agents and futures, including differentiation between CPU and IO intensive threads. Erlang's scheduler is also threaded, though its threads aren't 1:1 with pthreads. That's fairly common: plenty of libraries and languages map green threads to physical threads for highly concurrent programs.


Also, concurrency provides some performance gains that are not related to parallelism, such as efficient use of the CPU while waiting on I/O.




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: