3 ms·

I’m not sure on the level of F# support, but Blazor supports full ahead-of-time compilation of .NET code to WASM: “Blazor WebAssembly supports ahead-of-time (A

I’m not sure on the level of F# support, but Blazor supports full ahead-of-time compilation of .NET code to WASM: “Blazor WebAssembly supports ahead-of-time (AOT) compilation, where you can compile your .NET code directly into WebAssembly. AOT compilation results in runtime performance improvements at the expense of a larger app size. Without enabling AOT compilation, Blazor WebAssembly apps run on the browser using a .NET Intermediate Language (IL) interpreter implemented in WebAssembly” https://learn.microsoft.com/en-us/aspnet/core/blazor/host-and-deploy/webassembly?view=aspnetcore-7.0 https://learn.microsoft.com/en-us/aspnet/core/blazor/host-an...

greggyb 3y ago
If something works based on .NET IL, then it works equally well for F# as C#. Both are first class languages in .NET. Anything written in one can be used from the other (though it is often very un-idiomatic without a wrapper). Both compilers generate the same IL.
- pjmlp 3y ago
  Not really, as there are restrictions, and for example .NET Native didn't handle some of the IL pattern required by F#. This was never fixed, even though there are some kind of workarounds. F# also has some issues with some IL constructs generated by C#, with features not exposed in F#, like protected, which can be consumed, but not authored.
  - greggyb 3y ago
    I wasn't aware of the issues with .NET Native. Your second point is exactly what I said, though. F# can consume things written in C#. Whether the F# language team wants to include some specific feature is a different question. C# libraries that use the protected attribute can be used transparently in F#. They are different languages with a shared runtime. You can't write a computation expression in C#, but an F# library function that is implemented with CEs can still be called from C#.
    - pjmlp 3y ago
      > C# libraries that use the protected attribute can be used transparently in F#. Only if you don't need to write data types that need to be consumed by said libraries, as to express those types you need C# features. Another two key examples are the recent trends from .NET team to depend on Roslyn and code generators, both not supported by F#, so the language can't be fully used in such workloads without a little bit of C# glue. Really, F# might be from Microsoft, but the .NET team handles it as if it was a 3rd party guest language.
      - FrustratedMonky 3y ago
        Yes. Think this is the frustrating part. MS kind of broadcast like it is equal, full language. But .NET doesn't support everything. I think this is why .NET core doesn't have typeproviders?

greggyb 3y ago

If something works based on .NET IL, then it works equally well for F# as C#. Both are first class languages in .NET. Anything written in one can be used from the other (though it is often very un-idiomatic without a wrapper). Both compilers generate the same IL.

pjmlp 3y ago
Not really, as there are restrictions, and for example .NET Native didn't handle some of the IL pattern required by F#. This was never fixed, even though there are some kind of workarounds. F# also has some issues with some IL constructs generated by C#, with features not exposed in F#, like protected, which can be consumed, but not authored.
- greggyb 3y ago
  I wasn't aware of the issues with .NET Native. Your second point is exactly what I said, though. F# can consume things written in C#. Whether the F# language team wants to include some specific feature is a different question. C# libraries that use the protected attribute can be used transparently in F#. They are different languages with a shared runtime. You can't write a computation expression in C#, but an F# library function that is implemented with CEs can still be called from C#.
  - pjmlp 3y ago
    > C# libraries that use the protected attribute can be used transparently in F#. Only if you don't need to write data types that need to be consumed by said libraries, as to express those types you need C# features. Another two key examples are the recent trends from .NET team to depend on Roslyn and code generators, both not supported by F#, so the language can't be fully used in such workloads without a little bit of C# glue. Really, F# might be from Microsoft, but the .NET team handles it as if it was a 3rd party guest language.
    - FrustratedMonky 3y ago
      Yes. Think this is the frustrating part. MS kind of broadcast like it is equal, full language. But .NET doesn't support everything. I think this is why .NET core doesn't have typeproviders?