6 ms·

Wasm_of_OCaml

118 points by eriangazag 3y ago

eriangazag 3y ago
Wasm_of_ocaml is a fork of Js_of_ocaml which compiles OCaml bytecode to WebAssembly. The generated code works with Chrome beta and node V8 canary.
FrustratedMonky 3y ago
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.
Athas 3y ago
Sorry in advance for bikeshedding. This is a cool project and the name is clearly derived from js_of_ocaml, but does anyone know why js_of_ocaml ended up with such an awkward name in the first place? I am vaguely familiar with the "x_of_y" naming scheme in OCaml (which I also find awkward, but perhaps it sounds better in French) - is that the only reason? I can't find any discussion online, so maybe I'm really the only one who finds the name awkward.
- frou_dh 3y ago
  It's just a dodgy French to English translation which then became a convention. Instead of e.g. to_string's buddy being called from_string, it was called of_string. Here's a thread of reddit about it: https://www.reddit.com/r/ocaml/comments/6es88t/what_does_the_of_mean_in_js_of_ocaml/ https://www.reddit.com/r/ocaml/comments/6es88t/what_does_the...
  - nequo 3y ago
    I assume it also has a connection to how algebraic data types are written in OCaml. For example, the equivalent of Haskell's `Maybe` and Rust's `Option` is type 'a option = None | Some of 'a So calling this project "WASM of OCaml" is one way of saying that it "wraps" OCaml code in WASM.
    - giraffe_lady 3y ago
      Right but why do they use "of" in that way for type declarations? Ends up being the same answer: it's a reasonable translation from french for a non-native english speaker.
      - wk_end 3y ago
        ...except that the original ML uses the same syntax, and it's Scottish.
        giraffe_lady 3y ago
cosmos64 3y ago
Grain?

118 points by eriangazag 3y ago

Wasm_of_ocaml is a fork of Js_of_ocaml which compiles OCaml bytecode to WebAssembly. The generated code works with Chrome beta and node V8 canary.

FrustratedMonky 3y ago

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.

Athas 3y ago

Sorry in advance for bikeshedding. This is a cool project and the name is clearly derived from js_of_ocaml, but does anyone know why js_of_ocaml ended up with such an awkward name in the first place? I am vaguely familiar with the "x_of_y" naming scheme in OCaml (which I also find awkward, but perhaps it sounds better in French) - is that the only reason? I can't find any discussion online, so maybe I'm really the only one who finds the name awkward.

frou_dh 3y ago
It's just a dodgy French to English translation which then became a convention. Instead of e.g. to_string's buddy being called from_string, it was called of_string. Here's a thread of reddit about it: https://www.reddit.com/r/ocaml/comments/6es88t/what_does_the_of_mean_in_js_of_ocaml/ https://www.reddit.com/r/ocaml/comments/6es88t/what_does_the...
- nequo 3y ago
  I assume it also has a connection to how algebraic data types are written in OCaml. For example, the equivalent of Haskell's `Maybe` and Rust's `Option` is type 'a option = None | Some of 'a So calling this project "WASM of OCaml" is one way of saying that it "wraps" OCaml code in WASM.
  - giraffe_lady 3y ago
    Right but why do they use "of" in that way for type declarations? Ends up being the same answer: it's a reasonable translation from french for a non-native english speaker.
    - wk_end 3y ago
      ...except that the original ML uses the same syntax, and it's Scottish.
      - giraffe_lady 3y ago

cosmos64 3y ago

Grain?