rspeele
commented
6 years ago This builder is more convenient to use because it supports arbitrary awaitables including Task, Task<'a>, YieldAwaitable, ValueTask, etc. without requiring wrapper functions. This builder's license is also extremely permissive which makes it easy to drop into a project as if you'd written it yourself. I also believe it to be well tested, particularly around exception handling (which can be a little tricky). However, the main reason to use this builder is that it produces state-machine based tasks which are more like what you get from C#. The FSharpx builder is based on Task.ContinueWith which causes problems with long-running loops. See this issue I opened in June, which has not yet been addressed.
I think the FSharpx builder exists as a "nice-to-have" feature in the FSharpx toolbox, and works adequately for writing some glue code here and there for Tasks. I do not think it is suitable for heavy use, where a huge portion of your code is in task blocks because your system is asynchronous from the bottom-up and you have chosen Task<> as your canonical representation of async work (instead of F#'s Async<> type).
See also this issue from last year. To be fair, it was fixed quickly after being reported, but it appears to have existed for years before being caught. Trivial use binding scenarios exhibited this problem (e.g. open a stream and call ReadAsync on it).
My point here is not to denigrate the FSharpx project. It's simply that the task builder in that project is a tiny part of the whole thing, and doesn't seem to have gotten much real world exercise. By contrast, the entire point of this project is its task builder and so it really tries to get that one little thing right. My TaskBuilder is not very well known, so I can't claim that it has yet been "battle tested" either, although I do use it in my work and in my other open source projects Rezoom and Rezoom.SQL. It is also in use in Giraffe.
xperiandri
https://github.com/fsprojects/FSharpx.Extras/