3 ms·

Interesting point! I haven't used F# so I assumed it was pretty "native" to the .NET runtime Still- I have to wonder about things like concurrency, which is pe

Interesting point! I haven't used F# so I assumed it was pretty "native" to the .NET runtime Still- I have to wonder about things like concurrency, which is perhaps the most obvious limitation of targeting the JS runtime

kevinmgranger 5y ago
There are some caveats they outline for the usual async stuff[1], but at a cursory glance, it's not that bad. Thanks to F#'s computation expressions, .NET async code and Fable.Promise code look almost identical.[2] 1: https://fable.io/docs/dotnet/compatibility.html#Caveats-II https://fable.io/docs/dotnet/compatibility.html#Caveats-II 2: https://stackoverflow.com/a/54451205/4099287 https://stackoverflow.com/a/54451205/4099287
- pharmakom 5y ago
  My suggestion is to use async in F# code by default. Use task for certain heavy server code on .NET and promise for JS interaction, where required. Async mostly works everywhere.
  - kevinmgranger 5y ago
    Is there some sort of (for lack of a better term) Monad Transformer that lets you mix `async` and `promise` in the same computation expression?
    - pharmakom 5y ago
      Computation Expressions are implemented using a class under the hood so you could probably build one with appropriate overloads. There’s a function that Fable provides to turn a promise into an async, so mix and match isn’t a huge challenge anyway.
      - kevinmgranger 5y ago
        Yeah, I'm just trying to avoid having to throw the adapters on each line. Just like fable supports any thenable, it'd be cool if async/task could be treated as a thenable.
phillipcarter 5y ago
F# is certainly a .NET language depending on the lens with which you view it. The object system and lots of its semantics are the way they are because that's how .NET works. However, a surprisingly large amount of this stuff is translatable and makes sense with a JS runtime instead. The fable authors have managed to thread the needle just right so that it more or less "feels right".

kevinmgranger 5y ago

There are some caveats they outline for the usual async stuff[1], but at a cursory glance, it's not that bad. Thanks to F#'s computation expressions, .NET async code and Fable.Promise code look almost identical.[2] 1: https://fable.io/docs/dotnet/compatibility.html#Caveats-II https://fable.io/docs/dotnet/compatibility.html#Caveats-II 2: https://stackoverflow.com/a/54451205/4099287 https://stackoverflow.com/a/54451205/4099287

pharmakom 5y ago
My suggestion is to use async in F# code by default. Use task for certain heavy server code on .NET and promise for JS interaction, where required. Async mostly works everywhere.
- kevinmgranger 5y ago
  Is there some sort of (for lack of a better term) Monad Transformer that lets you mix `async` and `promise` in the same computation expression?
  - pharmakom 5y ago
    Computation Expressions are implemented using a class under the hood so you could probably build one with appropriate overloads. There’s a function that Fable provides to turn a promise into an async, so mix and match isn’t a huge challenge anyway.
    - kevinmgranger 5y ago
      Yeah, I'm just trying to avoid having to throw the adapters on each line. Just like fable supports any thenable, it'd be cool if async/task could be treated as a thenable.

phillipcarter 5y ago

F# is certainly a .NET language depending on the lens with which you view it. The object system and lots of its semantics are the way they are because that's how .NET works. However, a surprisingly large amount of this stuff is translatable and makes sense with a JS runtime instead. The fable authors have managed to thread the needle just right so that it more or less "feels right".