> GHC [...] idiomatic code competitive performance with other languages I thought this only was on micro-benchmarks? > GHC can easily produce garbage of 1GB/s

> GHC [...] idiomatic code competitive performance with other languages I thought this only was on micro-benchmarks? > GHC can easily produce garbage of 1GB/s [1], which it can handle far easier than most languages because everything is immutable. How can you possibly not totally trash caches and destroy performance with that kind of churn? From your link "New data are allocated in 512kb 'nursery'. Once it's exhausted, 'minor GC' occurs". I don't know but that sounds like kissing your entire L1 data cache goodbye, and then some. (stuff about GHC stack) - Most curious! Got a link? (cactus stack is it?) > This transformation only works with pure functions. for sure, FP transformations tend to require that but it reminds me that scala doesn't have a this-function-is-pure declaration, which I'd really like. Along with deep-constantness. > It seems to inherit a lot of restrictions from Java that limit its ability to do the type of optimizations that are necessary for performant FP. Not so sure. Scala seems to do a very literal translation - there was a library that showed this, I can't find it, was on github, where straightforward but messy desugaring was replaced with simple stuff. OK, let me try this instead... invented syntax, can't remember how to do it in scala, sum of squares: SumSq lst = reduce (\x, y: x + y) map (\z: z * z) lst I'm pretty sure scala would compile that literally a few years ago and I wonder if it does any better now. I'd expect that, over a thousand item list, to call the square lambda a thousand times to construct an intermediate, then call the add function a thousand times to reduce it. The above should be compilable to: SumSq lst = var rslt = 0; for(i in lst) { rslt += i * i }; rslt; They're not quite equivalent as the first will fail on an empty list but you see what I mean. Point is, there's nothing in the JVM that prevents this level of optimisation. The second does mem reads only and can operate in a couple of registers, and can be unrolled and seems maximally efficient in every way I can think. If FP doesn't use the very optimisations that it enables, it's going to pay for that in lack of takeup. Inefficiency is not just a technical issue, I'd say it's even a moral one - wasting resources is immoral.