Part 1: http://graydon2.dreamwidth.org/3186.html (discussion: https://news.ycombinator.com/item?id=8026868)
Part 2: http://graydon2.dreamwidth.org/189377.html (discussion: https://news.ycombinator.com/item?id=8028255)
I suppose there was an intro bit about Rust's lack of advertisement as a functional language (and perhaps that comes off as snooty), but from what I've seen of programmers outside of HN, this is a reasonable precaution. Most others I've talked to are either simultaneously ignorant and apathetic towards FP or actively distrustful. I literally had a friend at a major tech company tell me that he avoids FP because he does "real work", and he shouldn't have to bother with "idiots and their lambdas".
Then again, everyone likes to feel like the downtrodden victim. Dropping the pretense on both sides and trying to elucidate without proselytizing is the most effective strategy.
It's not like immutable variables are some magic bullet...
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.
Well the 'Motivation' section is about how low-level languages are a better (closer) fit to the contemporary machine architectures than functional programming. That could be interpreted to be dripping with attitude about functional programmers being out-of-touch with how machines 'really work'. (Which also seems to miss the point that functional programming languages that care about performance tries to achieve that by transforming idiomatic functional code to efficient imperative code, not trying to leverage some kind of machine model that actually matches the semantics of functional programming languages.)
> And then show examples of all the same "for" loops with mutable variables that you're used to writing in C have direct analogs in Rust.
Iterators seem to be more idiomatic in Rust than the loop alternatives.
You could write just the same kind of article about how Rust will bring out-of-touch theorists into modern software engineering where you actually need a C-level of performance and predictability. And then show examples of all the same "for" loops with mutable variables that you're used to writing in C have direct analogs in Rust.
But both bits of snark would miss the point, which is: Rust is awesome precisely because it merges these two schools of thought into something that preserves the advantages of both.