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.
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”
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.
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.
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#.
> 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.
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.
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.
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/
“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-an...