4 ms·
> …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 of
by btschaegg 8y ago
> …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.
- kod 8y agoIsn't async in f# considerably less efficient than in c#?
- btschaegg 8y agoI think so, yes. However, I'd attribute that to F# having the first implementation and not enough clout to influence the central .NET implementation, like C# did. AFAIK, there's another computation expression builder using Task<T> in FSharpx that performs better. 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 https://dconf.org/2018/talks/alexandrescu.pdf Page 4
- dgudkov 8y agoThey have different design goals. Async in F# works better for F# applications. Tomas Petricek wrote a couple good articles [1][2] comparing both approaches to async computations. [1] http://tomasp.net/blog/csharp-fsharp-async-intro.aspx/ http://tomasp.net/blog/csharp-fsharp-async-intro.aspx/ [2] http://tomasp.net/blog/csharp-async-gotchas.aspx/ http://tomasp.net/blog/csharp-async-gotchas.aspx/