4 ms·
The more play around about Erlang, the more it makes absolute sense. This is a concurrency done right. And I say this having done concurrent programming in Java
by mustpax 17y ago
The more play around about Erlang, the more it makes absolute sense. This is a concurrency done right. And I say this having done concurrent programming in Java and C (both pthreads and LAM/MPI).
The share-nothing, message passing paradigm beats the pants off Java concurrency. Threadpools and monitor based locking is fine if only 10% of your codebase is going to be concurrent, but it gets old fast.
MPI is pretty cool. LAM is a decent implementation. But as with any C API, there is a lot of low-level cruft to doing it right. pthreads is both cumbersome and fragile. Also kernel level threads, while they have scheduling benefits, tend to be more expensive to spawn/kill.
Erlang really abstracts away all this messiness and provides non-blocking send and selective receive with message buffers. If only it had better string literals. (Implementing infinite loops with infinite recursion also gives me chills. But then I guess you couldn't implement a while loop with single value variables.)
- mustpax 17y agoThe edit expired, but I feel embarrassed about those first two sentences so let me correct them: The more I play around with Erlang, the more it makes absolute sense. This is concurrency done right. This is the problem with posting to HN early in the morning. :)
- silentbicycle 17y agoBreaking a program into lots of autonomous pieces that communicate via message passing is a great way to help isolate complexity. Even if it didn't have any benefit for performance on a multi-core system or cluster, it would probably still be worth doing to keep everything from turning into a big ball of mud. Of course, that's Unix pipes all over again. Unix pipes and pattern matching from Prolog. :) A lot of Erlang stuff makes more sense if you've used Prolog, by the way. (Though Erlang is almost certainly a more practical language...)