Comments on: Why functional languages rock with multi-core

By: Ran Tavory

Ran Tavory — Tue, 24 May 2011 04:32:44 +0000

@david, I think we’re not disagreeing and indeed message passing has its own set of problems (and so does STM).
My main theme was (and that was almost 2y ago) that if in the past imperative languages were attractive b/c of their low latency and close to the metal efficiency then today and in the future these kind of optimizations would seem less and less appealing to many types of apps that want to scale horizontally b/c the abstraction of shared memory is harder to scale than the abstraction of message passing (as an example). And functional languages encourage message passing more than they do shared memory.
BTW, it’s great to have this discussion over comment, usually the breadth of comments on blogs is, well… of different kind

By: david karapetyan

david karapetyan — Mon, 23 May 2011 16:55:45 +0000

@ran I am not disagreeing with better and higher level concurrency constructs but I don’t understand what you mean “they don’t share state”. Erlang and AKKA (Scala/Java) still allow sharing state but they do it with message passing instead of shared variables. In most cases this works out better than using locks and shared variables but it’s got its own problems, e.g. messages get dropped or pile up, implicit ordering assumptions about message arrivals don’t hold, etc. If you’d like a general overview on such things I recommend http://skillsmatter.com/podcast/scala/talk-by-haskell-expert-simon-peyton-jones/js-1434. It’s a talk by Simon Peyton Jones about various approaches to concurrency and parallelism. He mostly focuses on STM but it’s still a pretty good talk.

By: Ran Tavory

Ran Tavory — Mon, 23 May 2011 07:13:44 +0000

@david you make good points but I would add that functional languages not only make you think in higher levels but since they don’t share state, they also make you think of programming that doesn’t require state and sharing it (or require to less extent). I don’t agree that they are the most trivial tasks necessarily. If you look at how those problems are solved with Erlang, AKKA (Scala/Java Actors) and other languages then you’d agree that the problems are real.
It’s not always “pure” functional, what that I can agree but they are much more functional than they are imperative.
The symptom I see with many imperative language programmers such as Java is that they although they could use higher level abstractions that don’t require explicite sync and state management, they tend to use lower level ones just b/c they can and in most cases, that’s what they were taught. Functional languages suffer less from that.

By: david karapetyan

david karapetyan — Sun, 22 May 2011 23:56:19 +0000

Functional languages usually do a better job when it comes to obviously parallel computations like a + b where a and b don’t depend on shared state but I haven’t seen much evidence of benefits when it comes to not so obvious parallel algorithms. Synchronization and state management are facts of life and if you don’t need synchronization and explicit state management then the imperative paradigm is just as good as the functional one, just spin up a thread for each independent unit of computation and you’re good to go. You can design the most beautiful parallel algorithm using your favorite functional language and it will all come to a grinding halt when the different parts of your algorithm start requesting non-parallel resources like files.

Now if you’d said we need more declarative languages because such languages let us focus on the big picture instead of the low level details and functional languages are a good example of the declarative paradigm then I’d agree with you but I don’t think that’s what you were going for and you just sound like another functional programming zealot championing the one true way for the future of computing.

By: Dominate functional languages and rule the Cloud « Life under the cross

Dominate functional languages and rule the Cloud « Life under the cross — Tue, 22 Mar 2011 00:07:54 +0000

[...] Tavory got there first with his blog on “Why functional languages rock with multi-core” but didn’t go deep into the reasons why, for those of us with a background in software [...]

By: Dave Bechtel

Dave Bechtel — Thu, 25 Feb 2010 22:52:47 +0000

Forth lives on!

By: Gary Mawdsley

Gary Mawdsley — Mon, 16 Nov 2009 17:56:16 +0000

very interesting…just reading about clojure myself….it is tough trying to shift thinking into a functional programming world…but interesting..will take a bit of practice

clearly its not practical for nothing ever to be shared between processes, however I can appreciate that mutable data has to be mitigated….the idea of software transaction memory seems to fit the bill quite nicely

By: Ori Lahav

Ori Lahav — Mon, 03 Aug 2009 09:47:37 +0000

Good post Ran.
one might say that the answer of the imperative languages to the “multi-core world” is multi-threaded programs.
WRONG!!!!
1. multi-threaded programming in language that “share stuff” basically requires threads synchronization which makes things run slowly.
2. the more threads you have, the more context switches the CPU does – this is eventually not a simple task.

what functional programming is offering – run max 1 process per CPU core and share nothing between your processes.

simple to say but requires change in the way of “thinking about your software”.