Wadler's Blog

As long as the underlying hardware has mutable storage locations data races in programs will still be possible. Using a functional language moves that possibility from the program itself to the language implementation. (Not that I'm saying that this doesn't make a big difference.)
 

Sorry, but I call bunk on this. First, the logic is circular. Second, all functional languages compile down to an imperative instruction stream, which the hardware executes. Thus, at some level, and with enough cleverness, one absolutely can create a data race in a purely functional program too.

The question of imperative vs functional programming boils down, therefore, to one of convenience and how easily one can shoot themselves in the foot. Imperative programming is easier to set up race conditions, but it's equally possible to program without them. Functional programming is the opposite -- easier to prevent race conditions (like good-quality static typing, it can do so to high degrees of confidence), but it's equally possible to create programs which have them (just as it's always possible to circumvent the type system somehow).
 

Sorry, Sam, your argument is incorrect, although there is a closely related argument which is correct.

Even though the implementation is in terms of mutable store, a well-designed compiler can ensure there are no low-level memory races.

However, almost any interesting distributed program will involve designs that can (deliberately or accidentally) include races at a higher level. Using a functional language does not eliminate the possibility of all races, it only eliminates the myriad opportunities for low-level races present in imperative approaches. Developers can focus on the races inherent in the design, rather than potential races everywhere.
 

Your links are empty. I guess you meant this.
 

Thanks, links now fixed.