Someone who worked on F# once told me that one reason F#'s uptake was limited was because C# was so good at stealing its best features.
Let's agree on "replicating some of its great features". If you look at what C# makes of them, more often than not, it's a hack. Maybe one that's better than what C# had beforehand, but a hack nonetheless.
Example:
`async` in F# is not only amazing because of async IO, but its integration is really elegant, too: `async` is basically just a computation expression (if you used haskell: read "do notation"). C# OTOH built in a whole new class of functions that's hardcoded into the language (the same techniques also differentiate C#'s iterator blocks vs. F#'s `seq`).
Another example:
F# has pattern matching, which is tremendously useful because it is exhaustive (there are squigglies if you forget a case). C# 8 introduces switch expressions that aren't, but will throw an exception at runtime instead (i.e.: the detection code is there anyway[1], it's just used the wrong way).
[1]: AFAIK, the autogenerated `default:` IL code is omitted if the compiler can prove that it will never be called. Someone mentions that in the latest "What's new in C#8" videos.
However, since in C#, async functions also seem to boil down to monadic continuations, I see no obvious reason the F# way couldn't be optimized to the same degree (given enough determination and resources).
If there's anyone here with insight into the `async` implementation that knows otherwise, I'd really appreciate a comment on this :)
Edit: Andrei Alexandrescu had a nice latin phrase on this in a talk at DConf 2018[1]: «Quod licet iovi non licet bovi». There, he's basically arguing the same thing: It is very often more desirable to give the language user a tool they can use themselves instead of reserving it only for the language implementers.
[1]: https://dconf.org/2018/talks/alexandrescu.pdf Page 4
Since it's launch C# has reversed itself on fundamental language decisions and requirements to go ever closer towards F#s capabilities.
Unfortunately, thanks to F#s functional heritage and compiler, there are huge swaths of capabilities that can't be completely realized by C#. That leads to "almost but not quite" convenience features in C#, without any of the reductions of cognitive load or any of the systematic guarantees you get with a functional language.
C# is easily one of the best languages out there, but it's also accumulating a lot of ways to skin various cats.