I find it interesting that 80% of the Ocaml discussions here are similar to what I encounter during the change management phase on every complex project I work on: "But it’s different from what I’m used and must therefore be bad. Look, the syntax, it doesn’t look like usual. Scary."
15% are people trying to sell their own language of choice sometimes with the argument that "it’s less scary, look".
I would be shocked if a mere 5% is actual engagement with the topic at hand sometimes while pointing flaws which are very real.
From there, I gather two things, the main one being: maybe Meta was right actually. People are that limited and the syntax should have been changed just to be done with the topic.
No offense but the only time I have encountered objects in Ocaml was while using LablGTK a long time ago and the object syntax was pretty clean and not far from the module one. They are also structurally typed which is very handy.
Considering it only impacts a fairly small subset of the language, could you explain how it supposedly ruins everything?
I posit (c) it’s from France and written mostly by French people and American naturally gravitates towards languages which generate hype in English and preferably from the USA.
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.
Rust is very different from Ocaml. Rust is a low level language with a borrow checkers, traits, no first class module system, no GADT, no effects.
The similarities are fairly superficial actually. It’s just that Rust is less behind the PL forefront that people are used to and has old features which look impressive when you discover them like variants.
There is little overlap between what you would sanely use Rust for and what you would use Ocaml for. It’s just that weirdly people use Rust for things it’s not really suited for.
The main user has been writing extensions to the compiler that they test before pushing for integration like they have done for the past twenty years or so. They publish these versions since last year.
Hardly a failure and certainly not something mandatory to keep things from failing over. Your initial comment is extremely disingenuous.
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.
Beginners face the following problems: there's multiple standard libraries, many documents are barely more than type signatures, and data structures aren't printable by default. Experts also face the problem of a very tiny library ecosystem, and tooling that's often a decade behind more mainstream languages (proper gdb support when?). OCaml added multicore support recently, but now there is the whole Eio/Lwt/Async thing.
I used to be a language nerd long ago. Many a fine hour spent on LtU. But ultimately, the ecosystem's size dwarfs the importance of the language itself. I'm sympathetic, since I'm a Common Lisp man, but I don't kid myself either: Common Lisp isn't (e.g.) Rust. I like hacking with a relic of the past, and that's okay too.
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 javadocs, sometimes with a couple of unhelpful lines.
> data structures aren't printable by default
Neither they are in C++
I think the real reason it's not popular is that there are languages which solve more or less the same problems of system programming but look far more familiar to an avg. programmer who was raised on C++ and Java.
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 news.
Meanwhile the mainstream has progressed a lot since 2000. GC is the standard, closures are normal, pattern matching and destructuring are increasingly so. While HM-style type inference is not mainstream, local type inference is (and I'm no longer convinced that global type inference is the way). Algebraic data types aren't unusual anymore.
A few years back I just threw in the towel and went with Rust; this happened after I volunteered to improve OCaml's gdb support (including DWARF hell), which went nowhere. I wish Rust compiled faster, and a GC'd language is usually more productive for my problems, but in every other regard it stole what should have been OCaml's thunder. And when popular successor languages eventually appear, they'll do it even better.
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.
You probably know it, but Common Lisp May be a bit dated but it’s extremely modern in terms of features since you can add almost any feature to the language in libraries! I use it exactly because it’s old and battle tested and I don’t need to wait years for a language designer to give me a feature , I can just add it myself, though these days it has everything done already!
There is only one standard library and it shipped with the compiler.
> data structures aren't printable by default
So? That’s the case with most languages. Ocaml has a deriver to make types printable and a REPL which automatically prints for testing.
> tooling that's often a decade behind more mainstream languages
Opam is a fully featured package manager, dune works fine, bucks2 supports Ocaml.
> proper gdb support when?
Ocaml has had a rewindable debugger since approximately forever.
> OCaml added multicore support recently, but now there is the whole Eio/Lwt/Async thing.
Lwt was the default and everyone agrees eio is the future now that effects are there. Async is a Janestreet thing with pretty much no impact on the language outside of Janestreet.
Honestly, I maintained my initial point. Ocaml alleged frictions were always widely overstated.
When I was writing Ocaml professionally 15 years ago, there was no dune and no opam and it was already fairly easy to use the language.
Rocq is an excellent example of something OCaml was designed for. FFTW3 is another great example. Unison too.
Generally, you want stuff where you have to build a fairly large core from scratch. Most programs out there doesn't really fit that too well nowadays. We tend to glue things more than write from nothing.
Rocq, Pfff and Flow, Vpnkit in Docker for Mac and Windows, the web version of Facebook Messenger at a point, Tezos, Unison, the Xen cloud platform, the Mirage unikernel.
10.0.0.0/8 is entirely reserved for private use. I don’t see any home users needing more ip than that and even then you could just switch to v6 and be done with the worry.
Bandwidth and interference will likely be an issue far before ip scarcity.
> OCaml in particular could do well with terminators after e.g. match blocks to improve both ambiguity and error reporting
You can use either begin/end or parentheses as terminators around any blocks of Ocaml for exactly that purpose.
> To me, the main downside of ML is the explicitly instantiated module systems not tied to the filesystem hierarchy.
That's one of the greatest strenght of ML actually and especially Ocaml where parametrised modules are everywhere and a required building block of generic code. A significant part of why the article complains about type for exemple is because the author doesn't know how to use the module system.
> Once you get used to traits and parameterised trait instances
I like modules a lot more. It makes the code a lot clearer than traits.
> The standard library situation is also somewhat not great. Maybe I just never got used to it, but I sense that there are people think Jane Street Base is a must
The standard library is a lot more complete nowadays that it was some years ago and Base is used by pretty much nobody outside of JaneStreet.
I stopped fighting this battle a long time ago. I think Ocaml just doesn't spoon feed people enough. They would have to actually read the documentation to understand and that's simply too hard nowadays so you end up which this kind of articles about "pain points" which are basically "I don't know what I'm doing and making a lot of mistakes, let me blame my tool".
Basically, when someone complaining starts by "I don't like the Algol-like syntax", obviously without saying it's Algol-like because that would require they actually know what Algol is, the rest is probably going to be extremely poor at best.
And here, it doesn't disappoint. Point 2, "I don't like type inference, it's too clever". Or you could just put type annotations at every declarations like every pieces of documentation ever produced on the language invite you to.
The type paragraph and the mentions of shadowing actually shows the author doesn't know how to use the Ocaml module system. For the neophytes here, it's the main standout feature of Ocaml. It's a bit like talking about C without knowing how to use pointers. I have seen people do that actually so I probably shouldn't be too surprised.
Menhir and ocamllex syntaxes are just slight twists on the actual syntaxes of yacc and lex. Nothing surprising for someone who knows both tools but I guess it's becoming a rarity nowadays. To be honest, the Ocaml compiler works exactly how you would expect a C compiler and linker to work. That makes it really simple and predictable for people who used to be C programmers but apparently completely inscrutable for young developers.
For printing, they quote "#[derive(Debug)]" in Rust but apparently they never reached ppx_deriving in Ocaml. It's a shame because it does exactly the same thing.
The whole conclusion with the weird segway about academics for a language which was purposefully designed to write provers and not as a research language doesn't even deserve to be commented upon.
Anyway, just go use Rust, bask in the hype, fight the borrow checker for things which don't require manual memory management, and leave us be. I think a significant part of why Ocaml is nice is that it is not appealing to many developers.
As soon as I saw the author uses OCaml for a class, I immediately knew the analysis will be somewhat superficial. No wonder, remembering my limited understanding when I was studying.
Thank you for your comment because I've been meaning to give OCaml a serious chance for a vary long time.
> They would have to actually read the documentation to understand and that's simply too hard nowadays so you end up which this kind of articles about "pain points" which are basically "I don't know what I'm doing and making a lot of mistakes, let me blame my tool".
Way to deflect any possible criticism x) I've used Ocaml for many years, and the syntax is undeniably a drag. There are inconsistencies, poor choices, none of which are a dealbreaker on their own but which together impose an ever-present friction. Death by a thousand cuts if you will. One of them explicitly mentioned in the article: the match statement.
> For printing, they quote "#[derive(Debug)]" in Rust but apparently they never reached ppx_deriving in Ocaml. It's a shame because it does exactly the same thing.
How do you print a list in OCaml? There's your answer as to why it's not the same thing.
There is no blame to defect. What’s supposed to be so weird about Ocaml syntax?
> How do you print a list in OCaml? There's your answer as to why it's not the same thing.
Don’t get your point.
You can ppx_derive on a list type. There is a feature specifically designed for this common use case. That gives you a pretty printer for a list. Alternatively you can tier the type pretty printer.
Is there supposed to be something special with lists?
What are the actual places you'd like to see improvement as an experienced user? A sibling post siggested concurrency, but from the outside those choices mostly seem to make sense. I've read complaints about opam/dune, but for simple stuff it seems to work fine.
The tooling remains so so. Opam is okay but it's not cargo. Dune is weird. Dune is actually very weird. I don't like Dune. It does work fine however.
Onboarding can be complicated. I'm complaining about new comers not reading the documentation before writting articles but objectively some concepts are so foreign, it's a bit difficult to see what you are missing. Module level programming for exemple is key to writing good Ocaml and it's quite a step if you are entirely new to functional programming. Effects are great but conceptually it's quite hard to get your head around them. Some fairly common libraries use Haskell influenced monadic interface. Yet another hurdle.
Traits have their flaws but I have to agree that having to be explicit all the time can be annoying. Modular implicit would be nice.
Concurrency is soon to be a lot better now that the effect system is mostly there and eio is landing.
The standard library is in the best shape it has ever been. I would still like more.
I do think maybe it should have stayed single threaded, or only allowed parallel iteration/loopsbfor fine grained parallelism. It was a completely safe language before 5 as long as you didn't pass -unsafe wasn't it?
It seems like you need to either be purely functional or have a borrowchecker if you want to have "fearless concurrency".
Is there a niche that OCaml fits really well with few packages needed? For example: Go has a great stdlib for networking (servers, etc); Rust is pretty good for CLI tools.
I've used OCaml for writing small compilers and it was really clean but that's a toy thing that will not see much real world usage.
Compilers, provers and static analysers. It's awesome for that. That's what the language was built for initialy: developing the Rocq prover.
It's surprisingly nice for web development also when you compile to JS. The ecosystem around Mirage and microkernel is quite impressive and if you want to build low level things and I for one like it significantly more than Rust for CLI tools.
It's a very versatile language honestly. It's opinionated enough that you have a clear idea of what would be the community choice but not so much that you can't just go to town with a different solution if it suits how you want to approach the problem more even it is an imperative implementation or even something object oriented.
I personally view Ocaml as basically a better Python with more features, better performance but without the huge success.
I don't particularly use OCaml anymore (though might in the future I guess), but one thing I remember is that sometimes when you had different parts of type system interact the compiler would just complain that you can't do that (mixing variants and GADTs was one such case I think?) without any real indication that this would be a problem before you try it. I get why this happens and I don't know how many people would run into it, but some kind visible notice or documentation for these cases would be nice.
> I stopped fighting this battle a long time ago. I think Ocaml just doesn't spoon feed people enough. They would have to actually read the documentation to understand and that's simply too hard nowadays so you end up which this kind of articles about "pain points" which are basically "I don't know what I'm doing and making a lot of mistakes, let me blame my tool".
The learning process for me has been as follows:
1. Make an error somewhere, maybe due to a misunderstanding
2. Error message makes no sense, or I don't know enough OCaml
3. Re-read the relevant portion of the documentation and examples
4. Hope that I can find the right way to do this somewhere
Compare this to Rust, which treats us quite nicely with descriptive errors that complement a vast and comprehensive reference manual. I do RTFM but a programming language is too big to learn all at once by reading a book before starting programming.
> Basically, when someone complaining starts by "I don't like the Algol-like syntax", obviously without saying it's Algol-like because that would require they actually know what Algol is, the rest is probably going to be extremely poor at best.
I am vaguely familiar with ALGOL but have never used it before. Do I need to put down OCaml and learn ALGOL first in order for my syntax complaints to be well-justified?
> And here, it doesn't disappoint. Point 2, "I don't like type inference, it's too clever". Or you could just put type annotations at every declarations like every pieces of documentation ever produced on the language invite you to.
I am doing this now, as I stated in the article. Compare against Rust's strictness, where bad ideas like not annotating function signatures are not allowed.
> The type paragraph and the mentions of shadowing actually shows the author doesn't know how to use the Ocaml module system. For the neophytes here, it's the main standout feature of Ocaml. It's a bit like talking about C without knowing how to use pointers. I have seen people do that actually so I probably shouldn't be too surprised.
I said in the article that:
> Enumerated types also dump all of their variants into the module scope
Is it wrong to say that they dump their types into the module scope? You have to put enum types in separate modules otherwise they will step on each other. (Is this understanding incorrect?) Maybe I will come to appreciate this as I learn more OCaml, but right now it seems like an unnecessary footgun.
> Menhir and ocamllex syntaxes are just slight twists on the actual syntaxes of yacc and lex. Nothing surprising for someone who knows both tools but I guess it's becoming a rarity nowadays.
Yes, I know this. The part that I don't understand is why OCaml wants to be like C with these tools in the first place. These tools exist in C because C doesn't have match statements, but OCaml does. What gives?
> For printing, they quote "#[derive(Debug)]" in Rust but apparently they never reached ppx_deriving in Ocaml. It's a shame because it does exactly the same thing.
ppx_show is an external library. Imagine having such a cucked stdlib that you have to call to an external library to print
> I think a significant part of why Ocaml is nice is that it is not appealing to many developers.
Clearly, that’s why people made a better syntax frontend for OCaml
You don't need an external library to print in OCaml. You just need it if you want to automate deriving a conversion function. OCaml erases types at compile time so the runtime doesn't know anything about types or how to print them. It's just how it works.
Re: better syntax frontend for OCaml. People really tried to, for many years. But it didn't work, there was never much adoption. And the funny thing was that as soon as people got comfortable with it they switched to the standard OCaml syntax because they understood it better and started preferring it. Ironic!
> I am vaguely familiar with ALGOL but have never used it before. Do I need to put down OCaml and learn ALGOL first in order for my syntax complaints to be well-justified?
Your syntax complaints will never be well-justified. It’s just a syntax family you are unfamiliar with, not an actual downside. You can either put up with it or change language. The syntax is however in no way inferior to C style syntax because that’s what you are used to.
> I am doing this now, as I stated in the article. Compare against Rust's strictness, where bad ideas like not annotating function signatures are not allowed.
There is no point in forcing you. The language doesn’t need to be strict. You can do whatever you want with your type annotation. It works just fine when you do annotate but no one is putting a gun to your head to do so if you just need a quick script. Best of both worlds.
> You have to put enum types in separate modules otherwise they will step on each other.
You do but it’s entirely normal and expected to define a new module inside your file in Ocaml and "let open" or assigning module is a common construct. It’s expected that you will not dump everything directly in scope.
> The part that I don't understand is why OCaml wants to be like C with these tools in the first place. These tools exist in C because C doesn't have match statements, but OCaml does. What gives?
They exist because generating parsers and lexers are nice and no one wants to learn a new language when they already know yacc and lex.
> ppx_show is an external library. Imagine having such a cucked stdlib that you have to call to an external library to print
No need to be vulgar. Ocaml has a lean standard library. That’s how the language is. You want macro and derivations you import them. They exist. Everybody uses them. The comment is a bit rich coming from someone who likes Rust.
> Your syntax complaints will never be well-justified. It’s just a syntax family you are unfamiliar with, not an actual downside. You can either put up with it or change language. The syntax is however in no way inferior to C style syntax because that’s what you are used to.
I think match statements should have an explicit `end` terminator or something so that you can nest them naturally. I think errors from accidental partial function application could be clearer. I think those two are pretty objective.
In terms of my subjective opinion the punctuation of C-style makes code hierarchy more clear, but at the cost of making it read less fluidly. I also think that `let...in` is weird and that Rust straddles a nice middle ground here by not having it but still having everything be an expression.
I like strict languages, and I like Rust for its strictness and robustness. I don’t like its standard library though, I wish it was more batteries included.
> I think match statements should have an explicit `end` terminator or something so that you can nest them naturally.
It’s unneeded.
You can explicitly delimit any expression in Ocaml by using begin … end or parentheses. It works for everything including match statements which are expressions. So you are already free to use an explicit end statement if you are so inclined.
I strongly condemn the October terrorist attack but I don’t see how someone can defend the morality of the IDF after the Gaza campaign.
We are talking of an army arbitrarily establishing no go zone in the middle of streets, not publishing them and then having snipers shoot down civilians crossing these imaginary lines including the ones coming to get back the corpses of their murdered family members. An army so blood thirsty they shot their own defenceless hostage who came in front of them with hands raised.
It’s pretty clear at that point that the IDF has absolutely no moral. This doesn’t in any way mean I support Hamas.
> have not just been subject to disinformation ,but actively spread it.
Just to be clear because this comment is ambiguous. Both of my statements come from internationally reputable sources including Israeli one. There is an interview with IDF snipers where they openly state what I wrote - video is available on sky news - and multiple accounts in Haaretz. The hostages killing by the IDF was a scandal inside Israel and completely true.
Both statements are beyond doubts. Could you be so kind as to point the disinformation I’m allegedly spreading?
15% are people trying to sell their own language of choice sometimes with the argument that "it’s less scary, look".
I would be shocked if a mere 5% is actual engagement with the topic at hand sometimes while pointing flaws which are very real.
From there, I gather two things, the main one being: maybe Meta was right actually. People are that limited and the syntax should have been changed just to be done with the topic.
reply