4 ms·
As I understand it, F#'s async funktionality was there first, and C# TPL was modeled after it, but I might be mistaken... Anyhow I am with you that this is one
by verinus 8y ago
As I understand it, F#'s async funktionality was there first, and C# TPL was modeled after it, but I might be mistaken...
Anyhow I am with you that this is one of the problems I have with F#. Interop from F# to C# is generally pretty bad.
- buybackoff 8y agoYes, F# was the first with async. Interop with C# is native, all code is compiled to IL and JIT-ed together. Problem with TPL is that it is supported by Roslyn at the language level. The C# compiler rewrites async/await into very efficient state machine. F# cannot natively integrate into that state machine and a long async call chain is always broken on C#/F# boundary, while in C# async-only code could be compiled in a big state machine and with ValueTask (and even better IValueTaskSource that is used in Streams and Sockets in dotnet core 2.1+) a long running while(true) {await... } loop could be allications-free. Add to this upcoming in C# 8 AsyncStreams and importance of this increases. F# allocates a lot on every boundary and basically cannot be a part of a high preformance async data processing pipeline where GC latency pauses are important. Throughput is also lower. There is a way to hook into the state machine manually, but it's still less efficient, cumbersome and unmaintainable. Been there - done that.
- verinus 8y agoOfc everythink is IL but working with Options in C# is not fun at all... same with F# async and C#...not belding well into each other- some things I meant when saying that interop is not good imho. I am with you in thinking, that there should be only one mechanism and that C#s async is superior...
- pjmlp 8y agoTPL also got feedback from the Midori experience with System C#. http://joeduffyblog.com/2015/11/19/asynchronous-everything/ http://joeduffyblog.com/2015/11/19/asynchronous-everything/