4 ms·

On this subject, a question. Has anybody done this with F#? To have F# compile to WASM instead of .NET. Thus have a F# program able to execute on WASM without

On this subject, a question. Has anybody done this with F#? To have F# compile to WASM instead of .NET. Thus have a F# program able to execute on WASM without needing .NET.

auggierose 3y ago
Isn't Blazor supposed to do that?
- zogrodea 3y ago
  That's right, and there's Bolero too. From my understanding, Blazor is by Microsoft and aimed at C# primarily while Bolero is from the wider community and aimed at F#. https://fsbolero.io/ https://fsbolero.io/
  - FrustratedMonky 3y ago
    Thank You. I had not heard of Bolero.
  - greggyb 3y ago
    Bolero is built on top of Blazor.[0] https://fsbolero.io/docs/ https://fsbolero.io/docs/
stetrain 3y ago
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.
        3y ago
phosphorco 3y ago
We've explored this. Not everyone will have this problem, but with Blazor, you have to export almost everything about F#/.NET to WASM. The Fable compiler team seems to have made steady progress towards a Rust compilation target which would solve this, but I'm not clear on where that works or how.
pbiggar 3y ago
Yes. Darklang was originally in OCaml using js_of_ocaml, and we ported it to F# using Blazor (https://github.com/darklang/dark/tree/main/backend/src/Wasm https://github.com/darklang/dark/tree/main/backend/src/Wasm). It works. We found that in dotnet 6, the code was much slower, with long startup times and a much bigger download, than in js_of_ocaml. It also had a lot of issues in running in a Webworker, which wasn't the case for js_of_ocaml. In dotnet 7, the webworker issues are better and AOT is easier, so startup is faster. Download sizes are still bad, and it's still slower than js_of_ocaml. However, dotnet allows almost any code to run in WASM, which js_of_ocaml had large limitations. This meant a decent chunk of functionality had to be worked around to make separate js vs native targets, which also was a massive pain and took a long time. Dune's virtual targets wasn't ready at the time - I think we were one of the test cases for it.

On this subject, a question. Has anybody done this with F#? To have F# compile to WASM instead of .NET. Thus have a F# program able to execute on WASM without needing .NET.

auggierose 3y ago

Isn't Blazor supposed to do that?

zogrodea 3y ago
That's right, and there's Bolero too. From my understanding, Blazor is by Microsoft and aimed at C# primarily while Bolero is from the wider community and aimed at F#. https://fsbolero.io/ https://fsbolero.io/
- FrustratedMonky 3y ago
  Thank You. I had not heard of Bolero.
- greggyb 3y ago
  Bolero is built on top of Blazor.[0] https://fsbolero.io/docs/ https://fsbolero.io/docs/

stetrain 3y ago

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.
      - 3y ago

phosphorco 3y ago

We've explored this. Not everyone will have this problem, but with Blazor, you have to export almost everything about F#/.NET to WASM. The Fable compiler team seems to have made steady progress towards a Rust compilation target which would solve this, but I'm not clear on where that works or how.

pbiggar 3y ago

Yes. Darklang was originally in OCaml using js_of_ocaml, and we ported it to F# using Blazor (https://github.com/darklang/dark/tree/main/backend/src/Wasm https://github.com/darklang/dark/tree/main/backend/src/Wasm). It works. We found that in dotnet 6, the code was much slower, with long startup times and a much bigger download, than in js_of_ocaml. It also had a lot of issues in running in a Webworker, which wasn't the case for js_of_ocaml. In dotnet 7, the webworker issues are better and AOT is easier, so startup is faster. Download sizes are still bad, and it's still slower than js_of_ocaml. However, dotnet allows almost any code to run in WASM, which js_of_ocaml had large limitations. This meant a decent chunk of functionality had to be worked around to make separate js vs native targets, which also was a massive pain and took a long time. Dune's virtual targets wasn't ready at the time - I think we were one of the test cases for it.