I am confused as to what this has to do with the author's point. He isn't saying purity is hard to use, he is saying the features of Rust make a truly pure function hard to define.
The author seemed to imply that pure if easily used would be a great feature, he just doesn't think that the language that Rust defines is a good match due to the ease of tainting a function.
I agree that that's his point. I just wanted to put in a plug for Haskell being appropriate for many, many application development use cases, because there's a misconception that it's only useful in mathy or academic scenarios.
Again, this guy didn't argue as much; he basically just said it's reasonable for someone developing systems code, code with I/O on every line or something, to conclude she isn't going to be able to reap the benefits of writing pure code in Haskell.
But I think a lot of folks read anything of the form "Haskell isn't appropriate for use case X" as "Haskell's generally impractical". So I wanted to share a different perspective.
All the Haskell hate I have heard isn't on the language but on developers, not trusting everybody to properly implement the paradigm shift and all that.
The author seemed to imply that pure if easily used would be a great feature, he just doesn't think that the language that Rust defines is a good match due to the ease of tainting a function.