I don't think "fighting spam" is really what the GP was talking about.

A common "best practice" with cryptographic material is to hold it as short a time as possible (um, but garbage collection makes that hard), and zero it before releasing it (but immutability gets in the way). That means that, in a language like Haskell, you're going to leak crypto material into the free memory pool unless you break the language paradigm to prevent it. Worse, you have to remember to break the language paradigm everywhere you need to.

In C++, you'd just wipe it with zeroes in the destructor, and use RAII to make sure it's freed when you don't need it any more. In Java, you have to explicitly overwrite it on your way out of the block (maybe with a "finally" clause). But in Haskell, you can't overwrite it (yeah, you actually can, but still...)

In non RT java this is nearly impossible. The best way is to use a specific allocated off memory byte buffer and zero it once done. But GC/deallocation and JIT compilation will fight your zeroing attempts, and it can easily break existing code :(

This is just wrong. You can totally use managed mutable buffers that you overwrite once you're done. It's probably easier than in Java.