7 ms·

I would suggest that people interested in using OCaml on Windows (or indeed, OCaml at all) try F# instead. It is still an ML-family language. Incidentally, by t

I would suggest that people interested in using OCaml on Windows (or indeed, OCaml at all) try F# instead. It is still an ML-family language. Incidentally, by targeting the CLR, F# is considerably more deployable (both to users and to developers) than OCaml is. Plus, any old NuGet library written in C# or VB.NET can be used almost trivially in F#. This also solves the problem OP listed about a tiny ecosystem, because the C#/.NET ecosystem is massive. I couldn't agree more with the parent commenter about OCaml documentation. Functional programmers appear to love terseness to an almost extreme degree. Things like `first` are abbreviated to `fst`, which is just odd. Especially now that good IntelliSense means there is no real functional (heh) difference between typing `.fi` and pressing Tab, and typing `.fs` and pressing Tab. The F# documentation is comparatively very spiffy and detailed, with plenty of examples[1][2][3]. [1]: https://learn.microsoft.com/en-gb/dotnet/fsharp/language-reference/ https://learn.microsoft.com/en-gb/dotnet/fsharp/language-ref... [2]: https://fsharp.github.io/fsharp-core-docs/ https://fsharp.github.io/fsharp-core-docs/ [3]: https://fsprojects.github.io/fsharp-cheatsheet/fsharp-cheatsheet.pdf https://fsprojects.github.io/fsharp-cheatsheet/fsharp-cheats...

mbac32768 1y ago
I find F# nowhere near as good as OCaml and think this comparison is ugly, but if I was forced to use a .NET platform I would almost certainly use F#
- neonsunset 1y ago
  [dead]
- delta_p_delta_x 1y ago
  > nowhere near as good as OCaml I'd really like to hear more about this. From what I've used of F# and OCaml, both languages are around 95% the same.
  - mbac32768 1y ago
    I'll give you my top 3. F# is worse because the type inferencing isn't as good. You need to type annotate in more places. It's a drag, because it feels like a missed opportunity to let the machine do work for you. Additionally, one of the most pleasant and unique features of OCaml, strong named arguments, doesn't exist in F# (except in methods or whatever). Most programming languages don't have this (or it's hamfisted like in more dynamic languages) so it doesn't seem like a loss, unless you are very cozy with them in OCaml. (I'm bitter about this one because named arguments give safety and convenience. But when you combine them with currying it's like 4 or 5 design patterns that are elegantly provided for you. You just do it implicitly, without ever having to study a book about using them.) Finally, F# brings back the NULL problem that OCaml worked so hard to eradicate.
    - tempodox 1y ago
      And you cannot have default arguments for function parameters in F#. They are only allowed with methods.
    - codesnik 1y ago
      interesting. how named arguments work with currying?
      - octachron 1y ago
        Nearly the same as with positional argument: Partially applying a function to a named argument creates a closure with this argument filled in, and you can apply the argument in whichever order you want: let f a ~x ~y b = a + x + y + b let g = f ~y:1 (* g is closure with the argument named ~y filled in *) let h = g 2 (* another closure with the first positional argument filled in *) let int_15 = h 8 ~x:4 (* = g 2 8 ~y:4 = f ~y:1 2 8 ~x:4 *) The more complex interaction is rather with type inference and currying, or the interaction between currying and optional arguments.
  - nukifw 1y ago
    If you are interested, I think I adress this here https://xvw.lol/en/articles/why-ocaml.html#ocaml-and-f https://xvw.lol/en/articles/why-ocaml.html#ocaml-and-f
int_19h 1y ago
F# is indeed an ML-family language, but at this point it doesn't have all that much in common with OCaml specifically: it doesn't have the latter's structurally typed object model with inferred row-polymorphic types, nor its extremely powerful module system, not even many convenience features like open variants.
- bmitc 1y ago
  F# has plenty of features that OCaml doesn't have like proper cross-platform support, proper deployment, active patterns, units of measure, computation expressions, type providers, interfaces on unions and records, etc. F# is probably faster as well and definitely has a larger ecosystem through .NET.
Syzygies 1y ago
To decide on a language for a math research project, I implemented a toy problem in many languages: What is the distribution of cycle counts for signed permutations on n letters? Use all cores in parallel. C++ 100 19.57s Rust 96 20.40s F# 95 20.52s Nim 75 26.04s Julia 64 30.40s Ocaml 48 41.07s Haskell 41 47.64s Chez 39 49.53s Swift 33 58.46s Lean 7 278.88s Tarjan, n = 10 Nyx - Apple M4 Max - 12 performance and 4 efficiency cores n! * 2^n = 3,715,891,200 signed permutations score = gops normalized so best language averages 100 time = running time in seconds This had me briefly smitten with F#, till I realized the extent that rusty .NET bed springs were poking through. Same as the JVM and Clojure, or Erlang and Elixir. The F# JIT compiler is nevertheless pretty amazing. I nearly settled on OCaml. After AI warning me that proper work-stealing parallelism is a massive, sophisticated project to code properly, the 40 lines of OCaml code I wrote that beat available libraries is my favorite code file in years. Nevertheless, once one understands lazy evaluation in Haskell, it's hard to use any other language. The log slowdown for conventional use of a functional data structure becomes a linear speedup once one exploits persistence.
- fud101 1y ago
  Interesting, would be a good blog post to read.
- delta_p_delta_x 1y ago
  I would really like to read more about this!
- fithisux 1y ago
  No Fortran?
- jibal 1y ago
  What about D? Can you post any of the 10 source codes?
- davidwritesbugs 1y ago
  F# would be awesome but for the dogs*t .Net backend that made the tiniest error insoluble
7thaccount 1y ago
F# pretty much assumes you already know C#. I found that it made it hard to get up to speed on it. I really do enjoy the the syntax though.

mbac32768 1y ago

I find F# nowhere near as good as OCaml and think this comparison is ugly, but if I was forced to use a .NET platform I would almost certainly use F#

neonsunset 1y ago
[dead]
delta_p_delta_x 1y ago
> nowhere near as good as OCaml I'd really like to hear more about this. From what I've used of F# and OCaml, both languages are around 95% the same.
- mbac32768 1y ago
  I'll give you my top 3. F# is worse because the type inferencing isn't as good. You need to type annotate in more places. It's a drag, because it feels like a missed opportunity to let the machine do work for you. Additionally, one of the most pleasant and unique features of OCaml, strong named arguments, doesn't exist in F# (except in methods or whatever). Most programming languages don't have this (or it's hamfisted like in more dynamic languages) so it doesn't seem like a loss, unless you are very cozy with them in OCaml. (I'm bitter about this one because named arguments give safety and convenience. But when you combine them with currying it's like 4 or 5 design patterns that are elegantly provided for you. You just do it implicitly, without ever having to study a book about using them.) Finally, F# brings back the NULL problem that OCaml worked so hard to eradicate.
  - tempodox 1y ago
    And you cannot have default arguments for function parameters in F#. They are only allowed with methods.
  - codesnik 1y ago
    interesting. how named arguments work with currying?
    - octachron 1y ago
      Nearly the same as with positional argument: Partially applying a function to a named argument creates a closure with this argument filled in, and you can apply the argument in whichever order you want: let f a ~x ~y b = a + x + y + b let g = f ~y:1 (* g is closure with the argument named ~y filled in *) let h = g 2 (* another closure with the first positional argument filled in *) let int_15 = h 8 ~x:4 (* = g 2 8 ~y:4 = f ~y:1 2 8 ~x:4 *) The more complex interaction is rather with type inference and currying, or the interaction between currying and optional arguments.
- nukifw 1y ago
  If you are interested, I think I adress this here https://xvw.lol/en/articles/why-ocaml.html#ocaml-and-f https://xvw.lol/en/articles/why-ocaml.html#ocaml-and-f

int_19h 1y ago

F# is indeed an ML-family language, but at this point it doesn't have all that much in common with OCaml specifically: it doesn't have the latter's structurally typed object model with inferred row-polymorphic types, nor its extremely powerful module system, not even many convenience features like open variants.

bmitc 1y ago
F# has plenty of features that OCaml doesn't have like proper cross-platform support, proper deployment, active patterns, units of measure, computation expressions, type providers, interfaces on unions and records, etc. F# is probably faster as well and definitely has a larger ecosystem through .NET.

Syzygies 1y ago

To decide on a language for a math research project, I implemented a toy problem in many languages: What is the distribution of cycle counts for signed permutations on n letters? Use all cores in parallel. C++ 100 19.57s Rust 96 20.40s F# 95 20.52s Nim 75 26.04s Julia 64 30.40s Ocaml 48 41.07s Haskell 41 47.64s Chez 39 49.53s Swift 33 58.46s Lean 7 278.88s Tarjan, n = 10 Nyx - Apple M4 Max - 12 performance and 4 efficiency cores n! * 2^n = 3,715,891,200 signed permutations score = gops normalized so best language averages 100 time = running time in seconds This had me briefly smitten with F#, till I realized the extent that rusty .NET bed springs were poking through. Same as the JVM and Clojure, or Erlang and Elixir. The F# JIT compiler is nevertheless pretty amazing. I nearly settled on OCaml. After AI warning me that proper work-stealing parallelism is a massive, sophisticated project to code properly, the 40 lines of OCaml code I wrote that beat available libraries is my favorite code file in years. Nevertheless, once one understands lazy evaluation in Haskell, it's hard to use any other language. The log slowdown for conventional use of a functional data structure becomes a linear speedup once one exploits persistence.

fud101 1y ago
Interesting, would be a good blog post to read.
delta_p_delta_x 1y ago
I would really like to read more about this!
fithisux 1y ago
No Fortran?
jibal 1y ago
What about D? Can you post any of the 10 source codes?
davidwritesbugs 1y ago
F# would be awesome but for the dogs*t .Net backend that made the tiniest error insoluble

7thaccount 1y ago

F# pretty much assumes you already know C#. I found that it made it hard to get up to speed on it. I really do enjoy the the syntax though.