Hacker News Reader

Comment by lukev | Hacker News Reader

While true, this is somewhat disingenuous. When people speak of concurrency in functional languages, they don't mean that each function executes in its own thread (even if it can, according to the semantics of the language). As this quote points out, the overhead of that is absurd, though maybe we'll get there someday with specialized hardware.

What functional programming does mean right now is that it's much easier to chop your program up into reasonable-sized chunks: big enough that it's worth the overhead, small enough that you can distribute as widely as possible.

In other words, if you think of a functional program as a tree and then expect to run each leaf in its own thread, the overhead will vastly outweigh the benefits. But the functional semantics also allow you to run each of the dozen main branches in separate threads with little effort.

I do this in Clojure all the time.

View on HN

Sure but this is also what you generally do in an imperative threaded app. Break the work up into discrete jobs and use a producer/consumer model to parallelize it. This has to be done carefully and usually requires an intimate understanding of the flow of the computation. It might be easier to do this in a functional language but their advantages tend to be mostly at the micro level and the hard stuff tends to be at the macro level.

I honestly think that the advantages of FP for concurrency will turn out to be relatively minor and that FP is more interesting as a means of improving code reuse and reducing bug counts. I'm not convinced that the current crop of FP languages are a win in those respects either though, taken as a whole.

Well, yeah. There's no silver bullet. But it's much easier to start lopping off branches from the tree if there are no unmanaged side effects.

Programming languages of the future need to enforce thread safety and mutation semantics as well as they do type safety. Functional programming is a step in that direction.

Nobody's necessarily claiming that a concurrent Clojure/Erlang/Haskell app is faster than concurrent C++/Java one, but they're definitely safer and easier to write.

I wonder if the kind of concurrency people have been focused on in these kinds of conversations is really going to turn out to be that important. It seems to me like a lot of the really cpu-intensive problems people are trying to solve are way beyond the scale of a single machine - the kinds of problems you need a big hadoop-style farm to tackle. How many apps are there left that really need maximum throughput in a shared memory architecture?

"When people speak of concurrency in functional languages, they don't mean that each function executes in its own thread"

Erlang does do that, more or less, although Erlang processes are much lighter weight than what we usually think of as a "process" or "thread".

As an added note, I'm not aware of anyone doing this yet, but it would be really cool to have a VM that did JIT-like analysis of purely functional code as it runs to determine optimal points for thread segregation.

Really? Can you post some profiling data?

Reply on news.ycombinator.com