C# gets a thumbs down for concurrency, while F# gets an "ok"? I'm a bit confused here. These both run on the CLR, which is cited in F#'s concurrency section. Or

C# gets a thumbs down for concurrency, while F# gets an "ok"? I'm a bit confused here. These both run on the CLR, which is cited in F#'s concurrency section. Or are we talking about language constructs? In that case, I'd make the argument that C# has one of the better with async/await implementations and have done a great job with concurrency. Other than that, this article is very clearly a FP vs non-FP article. Listen, I think FP is great too and I love a lot of concepts that come from it, but there are some drawbacks when it comes to readability and maintainability, at least for an average Joe like me and most of your peers. I've had to write quite a bit of SML for class this past semester, and will be writing quite a bit more next semester. I've never written more concise code in my life, but those 17 lines for that function take a lot more thought to write for something that isn't naturally recursive. Again, I'm just your average full time imperative programmer, so I may be missing the light. I just think that most of the best concepts from FP have been making their way into imperative languages, and I think it'll be like that for a long time. Rust's sum types are killer, LINQ and modern iterator systems, and first class functions are all things I find essential in any modern language I'm going to work in, and I have FP to thank. I just don't think that raw FP is the golden ticket for the average programmer.