Here's a thread of reddit about it: https://www.reddit.com/r/ocaml/comments/6es88t/what_does_the...
type 'a option = None | Some of 'a
It has been used as a translation of the French de since the 11th century and I think it gets some senses (eg derivation) from that. With a verb meaning create, this ocaml construction is fine in modern English (eg ‘make a string of an int’) and dates back a long way (OED offers a source from 893; this is sense I. [VII.] 20. a. in the second edition). So I think partly the question is whether omitting make in make_string_of_int (or String.make_of_int) is an acceptable abbreviation in programming.
`js_from_ocaml`, `string_from_int`, etc would have been clearer in english.
If i didn't speak Spanish it would bother me a lot more.
i = int_of_string s
i = string_to_int s
From the other comments sounds like its local style for OCaml maybe because of some French lineage, but that "int_of_string" is a function that converts a string into an int was definitely not something that I would have assumed (as opposed to 'int_from_string' or something).
f = glork_to_floob (crumb_to_glork c)
f = floob_of_glork (glork_of_crumb c)
> The notation g ∘ f is read as "g of f "...
* "used as a function word to indicate origin or derivation, eg. a man of noble birth" (js code comes from ocaml code)
* "used as a function word to indicate the component material, parts, or elements or the contents, eg. throne of gold / cup of water" (js application made of ocaml code)
"of" usually implies a state of being while "from" implies a transformation.
"JS of Ocaml" implies that the JS is Ocaml, but that's not true as it is transformed. "JS from Ocaml" would be more accurate.
Rope (advanced string): corde
Thread: fil
So string from object would like ficelle d'objet which is yeah, string from object. But the "of" thing in Ocaml is well documented. I vaguely remember them when I had an Ocaml project in my coursework.
But "standard library" never was a strong point of OCaml anyway so I guess meh shrugs
“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...
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.
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.