4 ms·

I'm only passingly familiar myself, so I might be off here-- but F# already has that sort of feel and experience, where it has some of its own ways of doing thi

I'm only passingly familiar myself, so I might be off here-- but F# already has that sort of feel and experience, where it has some of its own ways of doing things despite integrating into the .NET runtime. In other words, the language designers and users are already used to understanding corner cases and integrations into ecosystems that are different.

brundolf 5y ago
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".

brundolf 5y ago

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".