Live data from Hacker News

Why I love OCaml (2023)

mccd.space

131–140 of 313 posts

Re: Why I love OCaml (2023)

#131
post #96

> why isn’t OCaml more popular I've used OCaml a bit and found various issues with it: * Terrible Windows support. With OCaml 5 it's upgraded to "pretty bad". * The syntax is hard to parse for humans. Often it turns into a word soup, without any helpful punctuation to tell you what things are. It's like reading a book with no paragraphs, capitalisation or punctuation. * The syntax isn't recoverable. Sometimes you can…

+10 for bad windows support, i think this is a key and weirdly underestimated reason just to give an idea how bad, until recently, you could not just go to ocaml.org and download ocaml for windows, you had to either download one for mingw or wsl so for many it was just not installable, i.e. for many we didnt have ocaml for windows, until very very recently

The Windows support is bad because OCaml is a PL designed by people who are deep in Linux life. Windows is not something that keeps them up at night. (Which isn't to say they didn't try, just, you know, not as much as it takes)

One of the things people often neglect to mention in their love letters to the language (except for Anil Madhavapeddy) is that it actually feels UNIXy. It feels like home.

Re: Why I love OCaml (2023)

#132
post #91

Why isn't it more popular if it's so good? Because popularity and merit are not the same thing. People confuse them all the time though. Check out the most popular music today. Like the top ten songs currently. Do you think those are really the best songs out there? Popularity is mostly driven by either trends or momentum.

Music being "good" is subjective. A programming language, however, can objectively be better if it allows a subset of programmers to better solve certain problems.

The reason for why OCaml is not more popular, thus, is that this subset is small. The reason for this may be either (a) habit or (b) it's not that much better than other languages. I'm gravitating to (b). OCaml guys seem to be quite dogmatic for the wrong reasons.

Re: Why I love OCaml (2023)

#133

Earlier quoted context omitted.

The BEAM VM executing bytecode is slower than a compiled binary. Sure, it is great when compared to Python and other interpreted languages. Not so much when you need fast processing and raw CPU performance. It also loses out to the JVM in performance, but wins in memory consumption.

But how many things involve fulfilling basic requests over a network pulling information from a database? Most things just don’t need that kind of performance.

Sure for basic, dead CRUD, the choice of middleware language rarely makes any difference.

But even bog-standard business processes eventually find the need for data-processing, crypto and parsing - the use-cases where people code Elixir NIF's. That is why for example you have projects like html5ever_elixir for parsing HTML/XML. Another use case is crypto - you have NIF's for several crypto libraries. Data processing - there are NIF's for Rust polars.

Re: Why I love OCaml (2023)

#134
post #101
post #51

Elixir is the closest thing to OCaml that has a chance at semi-mainstream usage IMO. It has basically all of the stuff about functional programming that makes it easier to reason about your code & get work done - immutability, pattern matching, actors, etc. But without monads or a complicated type system that would give it a higher barrier to entry. And of course it's built on top of the Erlang BEAM runtime, which ha…

BEAM performance model trades throughput for isolation, which hurts CPU-bound tasks, and ironically, whenever you need speed, you end up using NIFs that break BEAM safety guarantees, and reintroduce the exact fragility Elixir was supposed to avoid. In 2025, Elixir is a beautiful system for a niche that infrastructure has already abstracted away.

> whenever you need speed, you end up using NIFs that break BEAM safety guarantees, and reintroduce the exact fragility Elixir was supposed to avoid.

That's like complaining that unsafe{} breaks Rust's safety guarantees. It's true in some sense, but the breakage is in a smaller and more easily tested place.

Re: Why I love OCaml (2023)

#135

Earlier quoted context omitted.

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…

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.

Re: Why I love OCaml (2023)

#136

I've dabbled in F# (and aside from the rough setup with little coherent information at the time) had a pretty good time. Actor-based concurrency was easy to grok. The one gotcha was whenever those mutable Arrays entered the picture. I'd like to hear some practical reasons for preferring OCaml over F#. [Hoping I don't get a lot about MS & .NET which are valid concerns but not what I'm curious about.] I want to know mo…

We’ve used f# professionally for the computations-intensive parts of our product for a couple of years. Here’s what comes to mind:

1. Interop with C# is great, but interop for C# clients using an F# library is terrible. C# wants more explicit types, which can be quite hard for the F# authors to write, and downright impossible for C# programmers to figure out. You end up maintaining a C#-shell for your F# program, and sooner or later you find yourself doing “just a tiny feature” in the C# shell to avoid the hassle. Now you have a weird hybrid code base.

2. Dotnet ecosystem is comprehensive, you’ve got state-of-the web app frameworks, ORMs, what have you. But is all OOP, state abounds, referential equality is the norm. If you want to write Ocaml/F#, you don’t want to think like that. (And once you’ve used discriminated unions, C# error-handling seems like it belongs in the 1980’ies.)

3. The Microsoft toolchain is cool and smooth when it works, very hard to wrangle when it doesn’t. Seemingly simple things, like copying static files to output folders, require semi-archaic invocations in XML file. It’s about mindset: if development is clicking things in a GUI for you, Visual Studio is great (until it stubbornly refuses to do something) ; if you want more Unix/CLI approach, it can be done, and vscode, will sort of help you, but it’s awkward.

4. Compile-times used to be great, but are deteriorating for us. (This is both F# and C#.)

5. Perf was never a problem.

6. Light syntax (indentation defines block structure) is very nice until it isn’t; then you spend 45 minutes how to indent record updates. (Incidentally, “nice-until-it-isn’t” is a good headline for the whole dotnet ecosystem.

7. Testing is quite doable with dotnet frameworks, but awkward. Moreover. you’ll want something like quickcheck and maybe fuzzing; they exist, but again, awkward.

We’ve been looking at ocaml recently, and I don’t buy the framework/ecosystem argument. On the contrary, all the important stuff is there, and seems sometimes easier to use. Having written some experimental code in Ocaml, I think language ergonomics are better. It sort of makes sense: the Ocaml guys have had 35 years or so to make the language /nice/. I think they succeeded, at least writing feels, somehow, much more natural and much less inhibited than writing F#.

Re: Why I love OCaml (2023)

#137
post #111

Earlier quoted context omitted.

TBH I think it's rather a post-hoc rationalization of why the language is not popular. > there's multiple standard libraries Scala has a far more fragmented ecosystem with Cats, Scalaz, Zio and Akka. C++ and Java have a bunch of stdlib extensions like boost, Guava, Apache Commons etc. > many documents are barely more than type signatures Can be said of most of Java, Kotlin, Scala, Erlang etc etc. Just compiled javado…

Maybe it's post-hoc? I wanted to use OCaml since 2002, since it was a GC'd language with good performance, achieving a lot with relatively few lines of code. Being a language nerd, I was (am?) positively inclined to the language. Yet there was always something that made it notably less pleasant to solve my current problem in than in than some other language. If it had trouble getting traction with me , that's bad new…

Off-topic: What language would you say is the closest thing to "Rust with a GC"?

(Rust has refcounting, but it's slow, and needing to handle cycles manually limits its usefulness.)

Re: Why I love OCaml (2023)

#138
I absolutely love the idea and methods behind OCaml, but the syntax..... I also love Haskell and already feel that its syntax is not easy to grok on larger projects, but OCaml basically went "hold my beer" and went to town on that.

Re: Why I love OCaml (2023)

#139
post #7

To this day, whenever I see Machine Learning abbreviated, my heart skips a beat, then I become crestfallen as I realize I'm not about to read something about Meta Language.

I'd rather have that issue than seeing "AI" plastered all over the place. I'm of the opinion AI should be reserved for artificial general intelligence. These things aren't intelligent yet. They're just em-bloat-ified traditional machine learning techniques. Not that they're useless. I just hate the terminology. If people start using the term AI, we better be living in I, Robot. Not whatever the hell this is. Tangenti…

I believe that current publicly available Ais are more intelligent than a non trivial fraction of adults.

Re: Why I love OCaml (2023)

#140

Earlier quoted context omitted.

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.

Post reply on HN