I'm not sure if you're joking, but when you have immutable variables they're pretty much like the mathematical variables that we've learned in school, and the benefits from that can be extremely huge (to the point that concurrency becomes easy). Whether that's considered a magic bullet is up to opinion, I guess.

>I'm not sure if you're joking, but when you have immutable variables they're pretty much like the mathematical variables that we've learned in school, and the benefits from that can be extremely huge

Yeah, I've read all the relevant stuff and seen my share of Hickeys presentations, Haskell folklore etc.

Still, I don't think it's some magic bullet. Maybe because IMHO, concurrency is just the latest fad IMHO. It's like: "OMG, we have so many cores and no more Moore's law, we HAVE to use them".

E.g on mobile apps. If concurrency (for speed) was important, people wouldn't use frameworks based on non-native scripting engines, adding 10 tons of overhead to their users resource constrained mobile phones.

While concurrency makes sense for server infrastructure and DSP stuff, for most of the problems programmers solve everyday (in web applications, in desktop applications, in enterprise applications, etc), it's really not that important. Not just because there are also processes, rpc, Node like async and similar strategies one can use (including APIs like Apple's GCD), but because it's not really about getting top speed, or most of the apps doesn't even come close to saturate 20% of a single core.

And there's always the graphic card for DSP and parallelism -- where it doesn't matter that much if your language has immutable variables or not, because you'll use CUDA etc for that.

I agree with you. I do not think immutability is good just because of concurrency; in fact that is never my motivation for taking advantage of immutability. I do it because then I have fewer bugs than if I used mutable memory cells.