Comment by delta_p_delta_x | Hacker News Reader

Comment by delta_p_delta_x | Hacker News Reader

Parent Full thread

delta_p_delta_x

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-ref...

[2]: https://fsharp.github.io/fsharp-core-docs/

[3]: https://fsprojects.github.io/fsharp-cheatsheet/fsharp-cheats...

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.

Interesting, would be a good blog post to read.

I would really like to read more about this!

No Fortran?

What about D? Can you post any of the 10 source codes?

F# would be awesome but for the dogs*t .Net backend that made the tiniest error insoluble

F# is a nice language, but it depends on .NET, so a direct comparison to OCaml is not possible. The .NET runtime dependency often makes things unnecessarily complex and fragile. There must be a reason why Golang (no VM runtime) is successful despite entering the market very late after Java and C# had already established clear dominance.

Easier deployment helped, but nowadays it’s common to put a single Go executable in a container anyway. .net core doesn’t have much if any disadvantage there.

Go was made by Google flawed, but with clarity of purpose and consistently usable libraries.

.NET spent years forked into framework and core and unclear open source future.

Java struggled to scale down and Oracle caused similar distrust as Microsoft.

While I agree with most points, .NET or JRE introduce additional complexity that may not be welcome in every setting. I've worked for several companies where upgrading to a newer version of .NET was always a major pain point, especially for applications that weren't very actively developed. There is limited security support for each major .NET version, so at some point, you and your customers need to upgrade. Such problems are non-existent if you don't have a separate VM runtime dependency.

I don’t think that has anything to do with VMs, the same happens with C++ runtime libraries.

The difference is Go really focused on continuity and compatibility, while .NET didn’t.

> ...the same happens with C++ runtime libraries

I don't think so. Upgrading to a newer major version of the C++ runtime essentially involves recompiling, unless you're dealing with an application that's 15 years or older. You can even instruct the compiler to use an older C++ standard if your code won't compile with the newer one. There is also an option to compile the runtime statically, though it is obviously not recommended.

.NET is a different story [1]

[1]: https://learn.microsoft.com/en-us/dotnet/core/compatibility/...

> I've worked for several companies where upgrading to a newer version of .NET was always a major pain point,

This was so difficult for the teams I work with that the person who became the team specialist in MSBuild, dotnet, and C# basically punched his ticket and received a couple of promotions. The work is so miserable and challenging that basically no one else Will take it.

I've struggled to understand why .net upgrades are so painful and laborious despite the maturity of the languages and ecosystems. I had assumed that, as with Powershell, C# and .net behind the scenes are undergoing enormous changes as Microsoft attempts to improve or add support for historically neglected platforms and hardware, and so I had assumed also that these were temporary problems, just badly managed growing pains on a path to major improvement, but I gather from your comment that the problem has a long history and is systemic. Awful.

MSBuild has been a huge source of the suffering I've experienced while working on these projects. The documentation is, in my experience, a nightmare: exhaustingly verbose, full of jargon, and uncanny in its ability to talk around an issue, concept, or functionality without clarifying anything conceptually or practically. I find this throughout Microsoft docs.

Upgrading a modern .NET (Core) version often means changing just versions in the project file. Upgrading from the old .NET Framework is bit more challenging, but we have also successfully upgraded a couple of Framework projects to modern .NET without too many issues.

Huh, maybe I misunderstood the nature of the .net work the guy I mentioned was doing. All I know directly is the pain of MSBuild itself. Thanks for the correction.

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.

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.

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#

> 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.

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.

And you cannot have default arguments for function parameters in F#. They are only allowed with methods.

interesting. how named arguments work with currying?

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.

If you are interested, I think I adress this here https://xvw.lol/en/articles/why-ocaml.html#ocaml-and-f

Thanks, this is a very nice article.

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.

Reply on news.ycombinator.com