Earlier quoted context omitted.
What is this alleged friction? Because plenty of people have been shipping great projects in Ocaml since it was released so it doesn’t seem to be much of an issue to many. I doubt Ocaml will be surpassed soon. They just added an effect system to the multicore rewrite so all things being considered, they seem to be pulling even more ahead.
> Because plenty of people have been shipping great projects in Ocaml What applications are written in OCaml? All I can think of (which says more about me than it does about OCaml) is the original Rust compiler. Even Haskell has Pandoc and Xmonad.
Why I love OCaml (2023)
171–180 of 313 posts
Re: Why I love OCaml (2023)
#172Earlier quoted context omitted.
It's a matter of trends: F# is losing compatibility with the overall CLR ecosystem due to the churn in C# features with poor F# interop, but F# has already mingled its design with the CLR's, too much to live on its own as a native language. Plus its compiler is slow and the tooling is getting increasingly unstable. Meanwhile, OCaml got rid of its global lock, got a really fast-compiling native toolchain with stable a…
> has an edge on some domains due to having unboxed types If a language makes "unboxed types" a feature, a specific distinction, and has to sell "removing global lock" as something that is a massive breakthrough and not table stakes from 1.0, it can't possibly be compared to F# in favourable light.
Let's not dismiss that their solution to remove the global lock has been both simpler than Python's (better funded?) ongoing work and backwards compatible; and the multicore support came with both a memory model with strong guarantees around data races, and effect handlers which generalize lightweight threads.
I agree that lack of unboxed types is a fatal flaw for several domains (Worse, domains I care about! I usually consider Rust/Go/.NET for those.) But when the comparison with OCaml is favourable to F#, the gap isn't much wider than just unboxed types. F# has an identity crisis between the ML parts and the CLR parts, its C# interop is decaying as the ecosystem evolves, and newer .NET APIs aren't even compatible with F# idioms (here's a .NET 6+ example [1]).
[1]: https://sharplab.io/#v2:DYLgZgzgNAJiDUAfA9gBwKYDsAEBlAnhAC7o...
Re: Why I love OCaml (2023)
#173Earlier quoted context omitted.
I don't think you would be flagged. Rust definitely has flaws: * Compile time is only ok. On par with C++. * Async has a surprisingly number of footguns and ergonomic issues. * There's no good solution to self-borrowing or partial borrows. * While using macros is fine, writing them is pretty awful. Fortunately you rarely need to do that. Relatedly it is missing introspection support. * Sometimes the types and lifetim…
You missed one: * Crates.io is an unmoderated wasteland of infinite transitive dependency chaos But my "favourite": * It's 2025 and allocator-api (or its competitors) is still in nightly only and no sign of stabilizing I work almost exclusively in Rust, and I like the language but in many respects a) Rust is the language that tokio ate, and b) it has been deluged with people coming from the NodeJS/NPM ecosystem doing…
Well, I'm not sure I agree with that. If by "unmoderated" you mean anyone can upload a crate without going through bureaucratic approvals processes then that seems like a good thing to me!
But you did remind me of one other majorly annoying thing about the crate system: the global namespace. It doesn't have the same security issues as Python's global package namespace, but it is really really annoying because you pretty much have to break large projects down into multiple crates for compile time reasons, and then good luck publishing those on crates.io. Plus you end up with a load of crate names like `myproject-foo`, `myproject-bar`, which is very verbose.
Oh and yeah, the Tokio situation is a bit sad.
Also the proliferation of some types of crates like error handling. This should really be in the standard library by now (or at least fairly soon). Any large project ends up with like 5 different error handling libraries just because dependencies made different choices about which to use. It's not a major issue but it is silly.
Overall though, still my favourite language by far.
Re: Why I love OCaml (2023)
#174Why 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…
Also it didn’t employ a marketing team to work on outreached and write fancy comments here and some people who have used it for 10 minutes are apparently offended by the Pascal-like syntax and can’t stop discussing it on every Ocaml discussion making every actual users tired.
Re: Why I love OCaml (2023)
#175Earlier quoted context omitted.
> Our hope is that these extensions can over time be contributed to upstream OCaml. Yeah, its more just extensions to support their use cases at scale. Think of it more as bleeding edge ocmal, once they work out kinks/concerns they'll get merged back into the language OR if it remains ultra specific it'll stay in oxcaml. Not a complete own version lol
Yes but the context of the thread is OCaml being "almost there". Having to build this stuff in-house is pretty good evidence.
Re: Why I love OCaml (2023)
#176Earlier quoted context omitted.
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.)
https://www.ponylang.io/ https://github.com/ponylang/ponyc
The Pony community is here:
https://ponylang.zulipchat.com/
Pony's garbage collection and runtime can yield performance faster than C/C++/Rust because the compiler eliminates data races at compile time, and thus no locks are needed.
It features implementations of Dmitri Vyukov (www.1024cores.net) algorithms for work stealing and Multi-producer single consumer queues that use only a single atomic instruction to read. The designer, Sylvan Clebsch, is an ex-game-developer and ex-high-frequency-trading-infrastructure engineering lead; he knew what he was doing when he designed the language for high performance on multicore systems.
On the other hand, you do have to re-wire your thinking to think in terms of Actors and their state, and this is kind of hard to wrap one's head around if you are used to Go's CSP or the popular async/await approaches -- it is a somewhat different paradigm.
Re: Why I love OCaml (2023)
#177> It just genuinely felt like the Go language designers didn’t want to engage with any of the ideas coming from functional programming. You'd be right. "The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we…
Re: Why I love OCaml (2023)
#178I loved Ocaml but now I love TypeScript more. It's got about the same amount of type safety, the ergonomics are better to me, and the packaging and ecosystem tooling are leaps and bounds above anything else.
What?
Re: Why I love OCaml (2023)
#179Earlier quoted context omitted.
> I could be an OCaml expert and have no chance of making it through an interview without equal talent in high performance fintech and relevant mathematics. Unless their hiring process has changed in the past few years, if you're a dev they're not hiring you for your financial skills, just general problem solving and software development ability. It is (was?) the usual Google-style algorithms/data structures rigamaro…
Do those devs actively use OCaml? I thought most of the folks writing OCaml were writing the actual trade algorithms as opposed to infrastructure folks. My post was made off what I recall their lead technologist saying.
Everybody in the company is expected to be able to sling numbers in text on a computer super efficiently.
Re: Why I love OCaml (2023)
#180Earlier quoted context omitted.
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.
It's not isolation which hampers throughput. That's a red herring. In fact, isolation increases throughput, because it reduces synchronization. A group of isolated tasks are embarrassingly parallel by definition. The throughput loss stems from a design which require excessive communication. But such a design will always be slow, no matter your execution model. Modern CPUs simply don't cope well if cores need to send…