4 ms·
How does Erlang compare to a theoretical functional programming language that comes with parallel primitives? e.g. fold (+) 0 myArray -- return sum of ele
by meric 15y ago
How does Erlang compare to a theoretical functional programming language that comes with parallel primitives?
e.g.
fold (+) 0 myArray -- return sum of elements in myArray, in parallel
map (*2) myArray -- return a new array with each element in myArray doubled,
-- in parallel.
You can see that `fold` and `map` abstractions that hides underlying parallel execution. Parallelism is transparent to the programmer.
My current belief with regards to the future of concurrent programming: concurrency will be hidden behind abstractions from the programmer to the point that the programmer won't (need) be aware of it; Just as when you are programming ruby & python you are not aware of the underlying assembly instructions that are being executed.[1]
Is this what Erlang is like, or, do you still have to deal with race conditions?
[1] Haskell Accelerate is an experiment in this direction: https://github.com/mchakravarty/accelerate/blob/master/accelerate-examples/tests/simple/DotP.hs https://github.com/mchakravarty/accelerate/blob/master/accel...
- mononcqc 15y agoErlang isn't exactly about parallelism as much as concurrency. There is a different to both; concurrency is about running independent units of code (at the same time or not) while parallelism has the explicit requirement of things running at the same time. Erlang can be concurrent on a single core, but things can hardly be truly parallel that way. Erlang's parallelism will thus be coming from being able to parallelize concurrent units, something that usually takes place at a higher level than function application for lists and whatnot (although you can use rpc:pmap for your map example). They're not exactly the same. Erlang's concurrency is organisational and explicit; the objective is to delimit subcomponents of a system in well established and isolated units, which can then communicate through message passing. The main objective is not to get things to run faster, but to help manage complexity in large systems.
- meric 15y agoThanks for the explanation! I understand the difference now.
- gtani 15y agoSince it's been a while since I've written any erlang, I'll direct you to pages 112-114 of the (excellent) O'Reilly erlang text by Cesarini and Thompson, which discusses how to deal with race conditions and deadlocks and goes on to say they're extremely rare if you follow standard practices, including mnesia/ETS and OTP behaviors. You have to worry more about mailboxes filling up, and sending large messages between actors, stuff like that.