"Under more conservative (realistic) assumptions, multicore scaling provides a total performance gain of 3.7× (14% per year) over ten years."

so in 10 years haskell maybe as fast a C/C++ program without parallelism, not exactly my definition of future proof.

But what if single core performance increases stop completely? In that case, parallelism wins out in the end as you keep adding more and more cores, given a problem amenable to parallelism.

I believe the problem is at the chip level, not the software level

Well, software requirements and abilities drive chip design, and vice-versa. Many-core designs don't have power density constraints that are quite so restrictive, but they're hard to utilize to their fullest. Haskell can help with that.

I think the other side of the problem though is that if you can still get 100X performance from what we have today, but it costs 100X in power, you will still have a problem where few can really use it. Consider phones as one data point. Even quadrupling the power draw will make the chips unsuitable for use.

What does this have to do with anything?

Well if you read the article to the end (which, granted, is not an easy task) the author finally after a lot meandering reaches the conclusion that you may solve the problem of dark silicon by stopping the increase in clock-speeds while using the increase in transistors to build multiple cores. He then says that this will not result in proportionally higher performance because our software does not run well on multiple cores.

This is where Haskell comes in. Haskell allows you to program in a way that makes parallelization relatively easy.

Well for that matter so does Clojure, and both have had a while to pick up traction. Do you think it'll be easier to solve the primarily-social problem of getting traction for languages like that (and I say this as someone who adores Clojure and has some affection for Haskell) or to solve the primarily-technical problem of figuring out chip technologies where one can metaphorically jack up current software and slide the new chip technology in underneath?

+95% of the article is about physical/hardware constraints: energy efficiency, architectural efficiency, etc. Haskell isn't going to solve these problems. Let me quote you: "I have the solution!"

It seems like you want to advertise a tool, instead of actually considering the issues.

He's not saying software doesn't run well on multiple cores and we need to learn how to program applications that can utilize multiple cores efficiently. That's a software problem. This is a hardware problem.

His argument is that scaling silicon to multiple cores is facing physical barriers. You're no longer getting more cycles, improved transistor density, and decreased power consumption simultaneously. Exponential scaling of cores will not result in exponential scaling of computational throughput because we're facing energy-related tradeoffs.

Thing the answer ids Erlang, which makes parallelization easy. No relative qualification required.

There are two important points the comments are somewhat missing:

On a chip there is now lots of redundancy to ensure chip functions correctly. This gets worse as variation at smaller geometries increases. So over margining because no one wants another floating point bug.

Design effort and cost is a huge issue too. Margins at chip companies are shrinking - design automation license costs, large runtimes and much more difficult verification process from design to fab to test.

A new programming paradigm where there is a certain probability of error can be tolerated should go a long way in making the underlying hardware much more efficient.