18 ms·

Why I love OCaml (2023)

391 points by art-w 10mo ago

dmpk2k 10mo ago
OCaml has been one of those "almost there" languages since at least 2002. Most of the worthwhile ideas in OCaml will be absorbed into more popular languages by the time existing friction is sorted out. :/
- jddj 10mo ago
  Almost there, but in the meantime supporting a casual squillion dollars of trades at JS
  - zdragnar 10mo ago
    Unless you're building another JS, it'd be nice if there were other companies so heavily invested in it. There's a lot out there beyond compiler prototypes and high speed financial trades, but there's not enough talk of people using ocaml for those things.
    - disgruntledphd2 10mo ago
      Ocaml was (historically, at least) used by Facebook for basically all of their linter/compiler/type checker work. The hack checker was in Ocaml, as was the JS thing (flow, maybe?). So that does seem to be a good use-case for the language.
      - zdragnar 10mo ago
        That was why I mentioned compilers along with HFT. Rust was originally an ocaml based compiler too. I don't build HFTs and my compilers are just for fun. None of my day jobs have ever been a situation where the smaller ecosystem and community of ocaml was offset by anything ocaml did better than the selected options like .net, Java, go, rails, C or anything else I've touched. Heck, I've written more zig for an employer than ocaml, and that was for a toy DSL engine that we never ended up using.
  - ng12 10mo ago
    Yes and they had to basically build their own version of the compiler to keep everything from falling over (https://oxcaml.org/ https://oxcaml.org/).
    - byefruit 10mo ago
      This is the wrong interpretation of the oxcaml project. If you look at the features and work on it, it's primarily performance or parallelism safety features. The latter going much further than most mainstream languages.
    - wrenky 10mo ago
      > 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
      - ng12 10mo ago
        Yes but the context of the thread is OCaml being "almost there". Having to build this stuff in-house is pretty good evidence.
        StopDisinfo910 10mo ago
        Evidence of what? 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.
        throw-qqqqq 10mo ago
        I don’t know about that. Python gets forked in other investment banks as well. I wouldn’t say that is evidence of any deficiencies, rather they just want to deal with their own idiosyncrasies. See https://calpaterson.com/bank-python.html https://calpaterson.com/bank-python.html
  - procaryote 10mo ago
    Yeah, but when these things happen I ask myself, is Jane Street successful because of ocaml, or did they just happen to pick ocaml and then make it work? There might be some power in attracting all the people who happen to love ocaml, if there are enough of competent people to staff your company, but that's more a case of cornering a small niche than picking on technical merits
    - warkdarrior 10mo ago
      Clearly Jane Street wouldn't be where it is, a top proprietary trading firm in US, without static type checking.
    - deleted 10mo ago
      [deleted]
    - 7thaccount 10mo ago
      They've spoken about this before and might not have picked OCaml if they had to make the decision again today. I think at the time it made the most sense.They can also make it work in any language as they claim to only recruit the best and brightest in the world (this may be the truth). My opinion is they could have chosen many languages and had similar results while balancing different trade-offs. Regarding attracting talent, they've said they don't care about existing knowledge of OCaml as the language part is something they train staff on anyway. Their interviews are brutal from what I recall. 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.
      - wk_end 10mo ago
        > 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 rigamarole, but somewhat more challenging.
- StopDisinfo910 10mo ago
  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.
  - dmpk2k 10mo ago
    Alleged? Come now. 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.
    - ernst_klim 10mo ago
      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.
      - deleted 10mo ago
        [deleted]
      - 10mo ago
- hardwaregeek 10mo ago
  Perhaps OCaml is the Velvet Underground of languages. Only a few thousand people learned OCaml but every one made a programming language[1] [1]: https://quoteinvestigator.com/2016/03/01/velvet/ https://quoteinvestigator.com/2016/03/01/velvet/
  - greener_grass 10mo ago
    That would be Elm :)
    - giovannibonetti 10mo ago
      Roc says hi!
    - 1-more 10mo ago
      I've been saying for ages! Gleam, Roc, Derw, Gren, Cara, Zokka, and the error messages in Rust. https://news.ycombinator.com/item?id=45646520#45752905 https://news.ycombinator.com/item?id=45646520#45752905
  - specialgoodness 10mo ago
    Xavier Leroy as Lou Reed... :-) Don't forget the amazing theorem provers too, like Imandra ( https://www.imandra.ai/core https://www.imandra.ai/core ), HOL-Light ( https://hol-light.github.io/ https://hol-light.github.io/ ) and Rocq ( https://rocq-prover.org/ https://rocq-prover.org/ ), ... !
- deleted 10mo ago
  [deleted]
pohl 10mo ago
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.
- PaulHoule 10mo ago
  ML blew my mind back in the late 1980s when I got to use it on a 80286 machine for the first time!
- kjmh 10mo ago
  ML refers to Meta Language and LLM refers to Languages and Logic Montreal [0], a PL theory group. [0] https://llm.uqam.ca https://llm.uqam.ca
  - embedding-shape 10mo ago
    > PL theory group I know there are great many Polish people in the world, but why it matters so much in this case? They could have been any nationality, even French!
    - pluralmonad 10mo ago
      I believe many people use PL to mean programming language. I'm wondering if your joke just wooshed me.
      - embedding-shape 10mo ago
        You believe I'd purposefully misread an abbreviation in a comment about misreading abbreviations, and also coincidentally tried to make fun of two other nationalities (maybe even three, depending on political views), all at the same time? I would never.
      - crdrost 10mo ago
        I mean pohl's joke above whooshed kjmh so it's all fine. The important thing for threads like this one is for us to name drop all of the weird programming languages that we have used, publicly avow the greatness of ones that we have not, and make a New Year's resolution that we will never follow, to actually pick up those great languages and write something in them...
wslh 10mo ago
Offtopic HTML issue to the author: there is a trailing </head> tag at the end of your generated HTML after the </body> (instead of </html>).
- yawaramin 10mo ago
  I don't see it...the end of the document is: </div> </body> </html>
  - mccd 10mo ago
    I updated it just now :).
- mccd 10mo ago
  Fixed it, thanks for pointing it out :)
fmbb 10mo ago
> It is an old language, and there are a few features that could probably be left out like the OOP-related features, and some libraries in the ecosystem over-complicate things like in Haskell. If one can stand a language that is just a little bit older, there is always Standard ML. It is like OCaml, but perfect!
- assbuttbuttass 10mo ago
  I love standard ml (I'm currently writing a compiler for it), but it's far from perfect. There are weird special cases in the language definition like the ad-hoc overloading between int and real, or the annoying value restriction. Records also feel half-baked, with no support for updating fields or for partially-specified records where the full set of fields is not known
  - mkehrt 10mo ago
    I've written a fair amount of SML (though years ago) and I can't remember the value restriction ever being an issue. I certainly agree that SML isn't really a production language, though.
  - retrac 10mo ago
    > with no support for updating fields While it's not yet standard nearly all Standard ML implementations support what has become known as "Successor ML" [0]. A large subset of Successor ML is common to SML/NJ, MLton, Poly/ML, MLKit and other implementations. That includes record update syntax, binary literals, and more expressive patterns among other deficiencies in Standard ML. For me the two big remaining issues are: 1) There's only limited Unicode support in both the core language and the standard library. This is a big issue for many real-world programs including these days the compilers for which SML is otherwise a wonderful language. 2) The module system is a "shadow language" [0] which mirrors parts of SML but which has less expressiveness where modules cannot be treated as first-class values in the program. Also if you define infix operators in a module their fixity isn't exported along with the function type. (Little annoyance that gets me every time I am inclined to write Haskell-style code with lots of operators. Though maybe that's just another hint from the universe that I shouldn't write code like that.) Of course, the fix to that would be a fundamentally different language; not a revised SML. [0] http://mlton.org/SuccessorML http://mlton.org/SuccessorML [1] https://gbracha.blogspot.com/2014/09/a-domain-of-shadows.html https://gbracha.blogspot.com/2014/09/a-domain-of-shadows.htm...
DeathArrow 10mo ago
For something a bit more modern but still related to OCaml, one can try F#.
- greener_grass 10mo ago
  F# is a practical choice but the language features are quite far behind OCaml now. {Ecosystem, Functors} - choose 1
  - runevault 10mo ago
    From an outsider's perspective, it feels like Ocaml has more active development of features, between the new effects system they added in 5 and all the work Janestreet is doing to let Ocaml developers have more control over performance. F# is not stagnant thankfully, it gets updates with each new version of dotnet (though I haven't checked what is coming with dotnet 10), but I don't recall anything on the level of the above Ocaml changes in years.
    - greener_grass 10mo ago
      Applicative Computation Expressions are a big deal (added in F# 5). Recent changes have been smaller in scope. Unfortunately lots of the more advanced stuff seems to be blocked on C# team making a decision. They want a smooth interop story. But F# remains a solid choice for general purpose programming. It's fast, stable and .NET is mainstream.
      - runevault 10mo ago
        Oh yeah I love f#, I need to find more excuses to use it. I just wish it felt like MS was willing to invest more into it. But at least they have not abandoned it and continue to put some resources into its ongoing growth.
  - phplovesong 10mo ago
    F# also has a real slow compiler. Last time hello world took a few secs on brand new mac.
sanufar 10mo ago
OCaml’s REPL is lovely, but I found myself having some friction with initial startup. The build/package system was pretty convoluted, and I ended up choosing JS’s Core stdlib for my needs (a simple compiler). With the new multicore release it’d be cool to see OCaml in some more practical projects!
- paulsmith 10mo ago
  As an OCaml-curious, is this the community recommendation, to choose the Jane Street stdlib if you’re just getting started?
  - tlavoie 10mo ago
    It's probably the path of least resistance if following the Real World OCaml book (https://dev.realworldocaml.org/ https://dev.realworldocaml.org/), which is quite excellent.
  - debugnik 10mo ago
    Many learning materials will push you that way, but the vast majority of FOSS packages don't use it. There's nothing inherently wrong with using Jane Street's stdlibs if you miss the goodies they provide, but be aware the API suffers breaking changes from time to time and they support less targets than regular OCaml. I personally stopped using them, and use a few libraries from dbunzli and c-cube instead to fill the gaps.
pkilgore 10mo ago
There's some other stuff, but I personally believe if the tooling was closer to Rust/Go than C, it would be a lot, lot more popular. Nobody wants to effectively learn a lisp to configure a build system.
- phplovesong 10mo ago
  Dune is quite good these days. The lisp part is really just sexps (not a full languge). But i kind of get your point.
_gmkt 10mo ago
Yes, in every ML/OCaml tutorial, sooner or later the words object, class, and type inference appear and that’s when a once–minimalist language turns into an academic Frankenstein.
- rwmj 10mo ago
  I don't think objects and classes are used much by OCaml programmers (not by me anyway). Type inference is a rather fundamental feature, and fairly easy to understand.
- giovannibonetti 10mo ago
  Why does type inference contribute to that issue?
- Barrin92 10mo ago
  It's not a minimalist language, you know what the "O" in Ocaml stands for right? It's a multi-paradigm language that explicitly accommodates more styles of programming than Caml, it's why it exists.
pulkas 10mo ago
darklang team loved ocaml too. in the end they ended up using f#.
karmakaze 10mo ago
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 more about day to day usage pros/cons.
- ernst_klim 10mo ago
  > I'd like to hear some practical reasons for preferring OCaml over F# Bigger native ecosystem. C#/.net integration is a double edged sword: a lot of libraries, but the libraries are not written in canonical F#. A lot of language features F# misses, like effect handlers, modules, GADTs etc.
  - karmakaze 10mo ago
    I did get some sense of that where F# sort of (actually is) 2nd class to C# which is slowly gaining some F# features, but F# itself isn't well promoted/supported. As for missing language features, they can also be a double-edged sword. I slid down that slippery slope in an earlier venture with Scala. (IIRC mostly implicits and compile times).
  - Nelkins 10mo ago
    There are libraries that simulate a lot of these things (e.g. https://github.com/G-Research/TypeEquality https://github.com/G-Research/TypeEquality for GADTs). You're absolutely right that it's not as first class as in OCaml, but the tools are there if you want them.
    - debugnik 10mo ago
      I've written type-equality witnesses in F#, they can kinda recover type equalities (with cast methods) but not refute them, so you still need to raise exceptions for those cases.
- 10mo ago
p0nce 10mo ago
Well I need both float and double, so cannot even start using it.
ModernMech 10mo ago
>why isn’t OCaml more popular? OCaml did become popular, but via Rust, which took the best parts of OCaml and made the language more imperative feeling. That's what OCaml was missing!
- StopDisinfo910 10mo ago
  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.
  - deleted 10mo ago
    [deleted]
- reddit_clone 10mo ago
  Ocaml can be as imperative as you need it to be. Or as functional. It has no dogmatic inclination towards functional. It has a very pragmatic approach to mutation.
  - talideon 10mo ago
    True, but writing imperative code in OCaml feels quite right. Maybe it's just me, but it always feels significantly clunkier than the functional equivalent. I've had things I've been implementing and though "this works be easier to express imperatively", and almost invariably I've gone and rewritten the code to be functional because of how ungainly the imperative implementation ended up being. It feels a bit too much like somebody embedded a subset of Rexx or Pascal awkwardly into an otherwise perfectly reasonable functional language
- abathologist 10mo ago
  As someone who has worked professionally in both, programming in rust does not feel much like programming in OCaml. Working with traits in an imperative manual memory managed language is really different than working with proper modules in a mixed paradigm language with an awesome GC.
pasxizeis 10mo ago
As a Rust newbie and seasoned Go dev, I'm pretty interested to knownwhere would people experienced in both OCaml and Haskell, would put it in the spectrum.
- hollerith 10mo ago
  What does "it" refer to? Ocaml?
- 7thaccount 10mo ago
  What spectrum? Language practicality? Popularity? OCaml has some high profile use at Jane Street which is a major fintech firm. Haskell is more research oriented. Both are cool, but wouldn't be my choice for most uses.
- bojo 10mo ago
  My team still has 8 year old Haskell systems in production. We pivoted away from the language a few years ago, which I discuss here a bit: https://news.ycombinator.com/item?id=37746386 https://news.ycombinator.com/item?id=37746386 I personally love ML languages and would be happy to keep developing in them, but the ecosystem support can be a bit of a hassle if you aren't willing to invest in writing and maintaining libraries yourself.
- deleted 10mo ago
  [deleted]
- jlouis 10mo ago
  I don't think it's a spectrum. Languages have features/constructs. It's better to look at what those are. And far more importantly: how they interact. Take something like subtyping for instance. What makes this hard to implement is that it interacts with everything else in your language: polymorphism, GADTs, ... Or take something like Garbage Collection. It's presence/absence has a large say in everything done in said language. Rust is uniquely not GC'ed, but Go, OCaml and Haskell all are. That by itself creates some interesting behavior. If we hand something to a process and get something back, we don't care if the thing we handed got changed or not if we have a GC. But in Rust, we do. We can avoid allocations and keep references if the process didn't change the thing after all. This permeates all of the language.
efficax 10mo ago
OCaml is fantastic, but I avoided it and went with Rust for many projects because it had no multicore story and no green threads for a very long time. But it has that now, and I wish I could go back and start everything over in OCaml.
- darksaints 10mo ago
  I've also felt very similar, and adopted Rust for those reasons. Even though I'd still love to have a garbage collected, AOT compiled ML-variant, using OCaml still feels like a step backwards now. OCaml's module system and generics feel clumsy and unintuitive now that I've used Rust's Trait system.
fer 10mo ago
One of the best P2P clients ever created is written in OCaml: https://github.com/ygrek/mldonkey https://github.com/ygrek/mldonkey I'm still surprised it can do so many things so well, so fast.
japhib 10mo ago
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 has a great track record as a foundation for backend systems. It doesn't have static typing, although the type system is a lot stronger than most other dynamic languages like JS or Python, and the language devs are currently adding gradual type checking into the compiler.
- timeon 10mo ago
  I do not think that monads/type system are issue, but yes BEAM runtime is killer feature.
- vvpan 10mo ago
  If it's functional (recursion vs imperative loops) most people/organizations will not use it. At this point that is just the reality.
  - zaphar 10mo ago
    Having loops is not the defining feature that separates functional from imperative. Where did this idea come from? I'm suddenly seeing it in a lot of places.
    - gmadsen 10mo ago
      its a simplification of immutability and its consequences
    - vvpan 10mo ago
      It is not the defining feature but loss of the loop is one of the most obvious differences for people who look at a functional language Rust has immutability, pattern matching, etc, but it remains an imperative language with "some functional features". Or this is my subjective analysis.
a-dub 10mo ago
fun fact: the secret sauce that makes fftw fast is a code generator written in ocaml: https://github.com/FFTW/fftw3/tree/master/genfft https://github.com/FFTW/fftw3/tree/master/genfft
yujzgzc 10mo ago
I 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.
- phplovesong 10mo ago
  You would not really build the same software tho.
- abathologist 10mo ago
  > It's got about the same amount of type safety What?
  - yujzgzc 10mo ago
    Both languages have robust and expressive type systems. My experience is that TypeScript's is also more flexible. In Ocaml everything is cool as long as you stick with the functional programming style. But every "interesting" program also has imperative, non-functional-programming parts, and TypeScript has really good automatic "type narrowing" features that make that part much safer in my experience. In Ocaml however, type narrowing isn't automatic at all.
    - abathologist 10mo ago
      TypeScript certainly has a more complicated and flexible type systems in many respects, but it is not the same w/r/t safety. It is quite common to run across `any`s all over the place in TypeScript code, and there is no such thing in OCaml. TypeScript's systems is explicitly unsound (i.e., not fully type safe) by design: https://www.typescriptlang.org/docs/handbook/type-compatibility.html#a-note-on-soundness https://www.typescriptlang.org/docs/handbook/type-compatibil...
      - yujzgzc 10mo ago
        Ocaml has exactly the same kinds of escape hatches, like Obj.magic or unsafe accessors. The way I see it. it's a matter of community practice more than language capabilities. Typescript in practice has has the safety net of being interpreted rather than compiled, so I guess people tend to abuse its type flexibility more. But if you write without the escape hatches in both languages, in my experience the safety is exactly the same and the cost of that safety is lower in TypeScript. A very common example I've encountered is values in a const array which you want to iterate on and have guarantees about. TypeScript has a great idiom for this: ``` const arr = ['a', 'b'] as const; type arrType = typeof arr[number]; for (const x of arr) { if (x === 'a') { ... } else { // Type checker knows x === 'b' } } ``` I haven't experienced the same with Ocaml
phplovesong 10mo ago
I kind of wish (like the OP mentioned) there was a ML (ocaml) like language that compiled to Go source. You would get the best of both worlds and access to a huge ecosystem.
- nathcd 10mo ago
  There's Borgo: https://github.com/borgo-lang/borgo https://github.com/borgo-lang/borgo I've never used it so can't speak from any experience, and unfortunately it doesn't seem particularly active (and doesn't mention a current status anywhere), and doesn't have a license, so shrug. When it's been posted here (https://news.ycombinator.com/item?id=40211891 https://news.ycombinator.com/item?id=40211891), people seemed pretty excited about it.
  - phplovesong 10mo ago
    Borgo looks like some guys phd thesis. It looks like it was a fun experiment. I feel a new simple ocaml like language that just compiled to Go would be really popular, really fast. And it would not even need to build a ecosystem, as Go already have all the things you need. Something like what Gleam is for Erlang.
fermigier 10mo ago
Little known fact: OCaml was at one point called "Zinc" ("Zinc is not Caml").
- Qem 10mo ago
  Perhaps the language would be more lucky with the original name. Zinc is used to galvanize steel and prevent Rust formation[1]. [1] https://en.wikipedia.org/wiki/Galvanization https://en.wikipedia.org/wiki/Galvanization
ilaksh 10mo ago
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.
- MeetingsBrowser 10mo ago
  I think popularity and regarded favorably are probably inversely correlated. Many of the most popular languages are also the most hated. Many of the more niche languages are viewed the most favorably. It is easy to dislike something yo are familiar with, and easy to be overoptimistic about something you don't know as well. "the grass is always greener ... "
- levzettelin 10mo ago
  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.
  - StopDisinfo910 10mo ago
    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.
  - 999900000999 10mo ago
    The popularity of a language usually translates into better support, tooling and learning materials.
ArnavAgrawal03 10mo ago
Came here to say I love Ocaml too
timhh 10mo ago
> 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 add a single character and the error message is essentially "syntax error in these 1000 lines". * Ocamlfmt is pretty bad. It thinks it is writing prose. It will even put complex `match`es on one line if they fit. Really hurts readability. * The documentation is super terse. Very few examples. * OPAM. In theory... I feel like it should be great. But in practice I find it to be incomprehensible, full of surprising behaviours, and also surprisingly buggy. I still can't believe the bug where it can't find `curl` if you're in more than 32 Unix groups. * Optional type annotation for function signatures throws away a significant benefit of static typing - documentation/understanding and nice error messages. * Tiny ecosystem. Rust gets flak for its small standard library, but OCaml doesn't even have a built in function to copy files. * Like all FP languages it has a weird obsession with singly linked lists, which are actually a pretty awful data structure. It's not all bad though, and I'd definitely take it over C and Python. Definitely wouldn't pick it over Rust though, unless I was really worried about compile times.
- tempodox 10mo ago
  > The syntax is hard to parse for humans. Funny how tastes differ. I'm glad it has a syntax that eschews all the noise that the blub languages add.
- systems 10mo ago
  +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
  - thaumasiotes 10mo ago
agentultra 10mo ago
Why isn't it more popular? I think Richard Feldman [0] proposed some of the most reasonable theories as to why functional programming isn't the norm. Your language needs to be the platform-exclusive language for a widely used platform, have a killer application for a highly desired application domain, or be backed by a monster war-chest of marketing money to sway opinions. Since Feldman's talk, Python has grown much faster in popularity in the sense of wide use in the market place... but mostly because it's the scripting language of choice for PyTorch and AI-adjacent libraries/tooling/frameworks which is... a killer application. I like OCaml. I started evaluating functional programming in it by taking the INRIA course online. I spent the last four and half years working in Haskell. I've built some side projects in Zig. I was a CL stan for many years. I asked this question a lot. We often say, "use the best tool for the job." Often that means, "use the tool that's available." I think languages like OCaml, Rust, Haskell etc can be "popular," but in the sense that people like to talk about them and want to learn them and be able to use them (at least, as trends come and go). It's different from "popular" as in, "widely adopted." [0] https://www.youtube.com/watch?v=QyJZzq0v7Z4 https://www.youtube.com/watch?v=QyJZzq0v7Z4
- m3at 10mo ago
  > mostly because it's the scripting language of choice for PyTorch and AI-adjacent libraries/tooling/frameworks I would politely disagree. Torch started in Lua, and switched to Python because of its already soaring popularity. Whatever drove Python's growth predates modern AI frameworks
  - spooky_deep 10mo ago
    Google blessed Python at a time when Java didn’t even have lambdas.
  - int_19h 10mo ago
    Python was already big for scientists back in 2010. I remember working on Python tooling at the time, and DS/ML was one of our single largest user groups. It was already popular enough to have an IDE specifically for scientific Python use: https://en.wikipedia.org/wiki/Spyder_(software) https://en.wikipedia.org/wiki/Spyder_(software). As far as I could tell, it had to do with two things. First, Python is notoriously dynamic and extensible, making it possible to implement "sloppy" syntax like advanced slicing or dataframes. But also, those guys had lots of pre-existing C and Fortran code, and Python had one of the easiest extensibility APIs to wrap it as high-level packages. And with IPython, you had a nice REPL with graphing to use all that from, and then of course notebooks happened.
rootnod3 10mo ago
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.
- deleted 10mo ago
  [deleted]
mikaeluman 10mo ago
I like the ML languages, and as many others I spent a lot of time with F#. I would love to spend more time but even though Microsoft gives it plenty of support (nowhere near as much as C#), the community is just too small (and seems to have gotten smaller). Looking at https://www.tiobe.com/tiobe-index/ https://www.tiobe.com/tiobe-index/ numbers fall off pretty quickly from the top 5-7. Guessing this is the same for OCaml, even if the language as such is nice.
- throwa567543 10mo ago
  Anecdotally we are using F# more than ever before, and it works for us for a large sized organisation. Fast code, it is keeping up with the .NET features that matter for that (e.g. spans), and tbh has still been getting better over the years. In fact I find some of the new features like Span, SIMD/intrinsics somewhat synergise with existing F# features (e.g. inline). C# IMO still hasn't quite caught up but is getting there. Comparing to Go/Java/etc I can usually get faster code out of the .NET runtime as well especially in our domain which requires large scale computation. If I was to move to something else for our domain it would be C++ or Rust. F# piggy backing of the .NET platform in general, has a decent ecosystem and easy onboarding cross platform and gets a lot "for free" (e.g. CLI, GC improvements). Community is an interesting thing, and for some people I guess it is important. For me language is just a tool having coded for quite some time and seen communities come and go; don't care about being known or showing an example per se. If the tool on the balance allows me to write faster code, with less errors quicker and can be given to generic teams (e.g. ex Python, JS devs) with some in house training its a win. For me personally I just keep building large scale interesting systems with F#; its a tool and once you get a hang of its quirks (it does have some small ones) quite a good one that hits that sweet spot IMO. My feeling however is with AI/LLM's communities and syntax in general is in decline and less important especially for niche languages. Language matters less than the platform, ecosystem, etc. Its easier to learn a language then ever before for example, and get help from it. Any zero cost abstraction can be emulated with more code generation as well as much as I would hate reviewing it. More important is can you read the review the code easily, and does the platform offer you the things you need to deliver software to your requirements or not and can people pick it up.
tasuki 10mo ago
> Fast compile times > Fewer abstractions, and an easy to understand runtime > Strong static guarantees > Functional programming constructs. Especially pattern matching and sum types. > Good performance > Good documentation I feel this is also Elm!
- creata 10mo ago
  Elm is pure-functional, unlike OCaml, which has easy escape hatches (refs) when you need mutability.
  - tasuki 10mo ago
    I feel as a frontend language Elm has somewhat less need for mutability. At least I haven't missed it.
pshirshov 10mo ago
> why isn’t OCaml more popular? Hashtbl.add table key value Precedence, nominal inheritance, HKTs, incoherent typeclasses make Scala much less aesthetically pleasant but much more productive.
- rixed 10mo ago
  Hashtbl.add table key value What's your point with that?
seabrookmx 10mo ago
Lots of complaints about the OCaml syntax here.. is ReasonML dead?
- davesnx 10mo ago
  is very alive, released with OCaml 5.4 support and improving bit by bit
olivia-banks 10mo ago
> 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 want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt. – Rob Pike 1" "It must be familiar, roughly C-like. Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical. – Rob Pike 2" Talking as someone who wrote OCaml at work for a while, the benefits of functional programming and the type guarantees that it's ilk provides cannot be understated; you only start to reach them, however, once most developers have shifted their way of thinking rather extremely, which is a time cost that that designers of Go did not want new Googlers to pay.
- VirusNewbie 10mo ago
  You would be surprised how many Googlers think the Go team is making bad decision after bad decision.
  - olivia-banks 10mo ago
    How so? I’m not that familiar with Go anymore.
    - hyperhopper 10mo ago
      Search any Go codebase for err != nil, for starters.
      - olivia-banks 10mo ago
        Well, sure, but this is a problem nearly as old as Go itself. I thought they were referring to larger more recent things, like how generics work, or something to that effect.
olivia-banks 10mo ago
> OCaml is weird in that it’s a garbage collected language for systems, similar to Go. I don't understand why this isn't more popular. For most areas, I'd gladly take a garbage collector over manual memory management or explicit borrow checking. I think the GC in D was one of it's best features, but it's downfall nonetheless as everyone got spooked by those two letters.
DeathArrow 10mo ago
The problem I see for the adoption is that the landscape is very fragmented. ML is a family of languages and we have StandardML with different implementations, OCaml with official path and JS path, F# and whatnot. This is the problem for Lisp, too as there are many Lisps.
StopDisinfo910 10mo ago
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.
fithisux 10mo ago
"but the more I use it the more I feel like this old language had it all figured out," sounds superficially similar to Common Lisp

391 points by art-w 10mo ago

dmpk2k 10mo ago

OCaml has been one of those "almost there" languages since at least 2002. Most of the worthwhile ideas in OCaml will be absorbed into more popular languages by the time existing friction is sorted out. :/

jddj 10mo ago
Almost there, but in the meantime supporting a casual squillion dollars of trades at JS
- zdragnar 10mo ago
  Unless you're building another JS, it'd be nice if there were other companies so heavily invested in it. There's a lot out there beyond compiler prototypes and high speed financial trades, but there's not enough talk of people using ocaml for those things.
  - disgruntledphd2 10mo ago
    Ocaml was (historically, at least) used by Facebook for basically all of their linter/compiler/type checker work. The hack checker was in Ocaml, as was the JS thing (flow, maybe?). So that does seem to be a good use-case for the language.
    - zdragnar 10mo ago
      That was why I mentioned compilers along with HFT. Rust was originally an ocaml based compiler too. I don't build HFTs and my compilers are just for fun. None of my day jobs have ever been a situation where the smaller ecosystem and community of ocaml was offset by anything ocaml did better than the selected options like .net, Java, go, rails, C or anything else I've touched. Heck, I've written more zig for an employer than ocaml, and that was for a toy DSL engine that we never ended up using.
- ng12 10mo ago
  Yes and they had to basically build their own version of the compiler to keep everything from falling over (https://oxcaml.org/ https://oxcaml.org/).
  - byefruit 10mo ago
    This is the wrong interpretation of the oxcaml project. If you look at the features and work on it, it's primarily performance or parallelism safety features. The latter going much further than most mainstream languages.
  - wrenky 10mo ago
    > 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
    - ng12 10mo ago
      Yes but the context of the thread is OCaml being "almost there". Having to build this stuff in-house is pretty good evidence.
      - StopDisinfo910 10mo ago
        Evidence of what? 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.
      - throw-qqqqq 10mo ago
        I don’t know about that. Python gets forked in other investment banks as well. I wouldn’t say that is evidence of any deficiencies, rather they just want to deal with their own idiosyncrasies. See https://calpaterson.com/bank-python.html https://calpaterson.com/bank-python.html
- procaryote 10mo ago
  Yeah, but when these things happen I ask myself, is Jane Street successful because of ocaml, or did they just happen to pick ocaml and then make it work? There might be some power in attracting all the people who happen to love ocaml, if there are enough of competent people to staff your company, but that's more a case of cornering a small niche than picking on technical merits
  - warkdarrior 10mo ago
    Clearly Jane Street wouldn't be where it is, a top proprietary trading firm in US, without static type checking.
  - deleted 10mo ago
    [deleted]
  - 7thaccount 10mo ago
    They've spoken about this before and might not have picked OCaml if they had to make the decision again today. I think at the time it made the most sense.They can also make it work in any language as they claim to only recruit the best and brightest in the world (this may be the truth). My opinion is they could have chosen many languages and had similar results while balancing different trade-offs. Regarding attracting talent, they've said they don't care about existing knowledge of OCaml as the language part is something they train staff on anyway. Their interviews are brutal from what I recall. 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.
    - wk_end 10mo ago
      > 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 rigamarole, but somewhat more challenging.
StopDisinfo910 10mo ago
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.
- dmpk2k 10mo ago
  Alleged? Come now. 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.
  - ernst_klim 10mo ago
    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.
    - deleted 10mo ago
      [deleted]
    - 10mo ago
hardwaregeek 10mo ago
Perhaps OCaml is the Velvet Underground of languages. Only a few thousand people learned OCaml but every one made a programming language[1] [1]: https://quoteinvestigator.com/2016/03/01/velvet/ https://quoteinvestigator.com/2016/03/01/velvet/
- greener_grass 10mo ago
  That would be Elm :)
  - giovannibonetti 10mo ago
    Roc says hi!
  - 1-more 10mo ago
    I've been saying for ages! Gleam, Roc, Derw, Gren, Cara, Zokka, and the error messages in Rust. https://news.ycombinator.com/item?id=45646520#45752905 https://news.ycombinator.com/item?id=45646520#45752905
- specialgoodness 10mo ago
  Xavier Leroy as Lou Reed... :-) Don't forget the amazing theorem provers too, like Imandra ( https://www.imandra.ai/core https://www.imandra.ai/core ), HOL-Light ( https://hol-light.github.io/ https://hol-light.github.io/ ) and Rocq ( https://rocq-prover.org/ https://rocq-prover.org/ ), ... !
deleted 10mo ago
[deleted]

pohl 10mo ago

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.

PaulHoule 10mo ago
ML blew my mind back in the late 1980s when I got to use it on a 80286 machine for the first time!
kjmh 10mo ago
ML refers to Meta Language and LLM refers to Languages and Logic Montreal [0], a PL theory group. [0] https://llm.uqam.ca https://llm.uqam.ca
- embedding-shape 10mo ago
  > PL theory group I know there are great many Polish people in the world, but why it matters so much in this case? They could have been any nationality, even French!
  - pluralmonad 10mo ago
    I believe many people use PL to mean programming language. I'm wondering if your joke just wooshed me.
    - embedding-shape 10mo ago
      You believe I'd purposefully misread an abbreviation in a comment about misreading abbreviations, and also coincidentally tried to make fun of two other nationalities (maybe even three, depending on political views), all at the same time? I would never.
    - crdrost 10mo ago
      I mean pohl's joke above whooshed kjmh so it's all fine. The important thing for threads like this one is for us to name drop all of the weird programming languages that we have used, publicly avow the greatness of ones that we have not, and make a New Year's resolution that we will never follow, to actually pick up those great languages and write something in them...

wslh 10mo ago

Offtopic HTML issue to the author: there is a trailing </head> tag at the end of your generated HTML after the </body> (instead of </html>).

yawaramin 10mo ago
I don't see it...the end of the document is: </div> </body> </html>
- mccd 10mo ago
  I updated it just now :).
mccd 10mo ago
Fixed it, thanks for pointing it out :)

fmbb 10mo ago

> It is an old language, and there are a few features that could probably be left out like the OOP-related features, and some libraries in the ecosystem over-complicate things like in Haskell. If one can stand a language that is just a little bit older, there is always Standard ML. It is like OCaml, but perfect!

assbuttbuttass 10mo ago
I love standard ml (I'm currently writing a compiler for it), but it's far from perfect. There are weird special cases in the language definition like the ad-hoc overloading between int and real, or the annoying value restriction. Records also feel half-baked, with no support for updating fields or for partially-specified records where the full set of fields is not known
- mkehrt 10mo ago
  I've written a fair amount of SML (though years ago) and I can't remember the value restriction ever being an issue. I certainly agree that SML isn't really a production language, though.
- retrac 10mo ago
  > with no support for updating fields While it's not yet standard nearly all Standard ML implementations support what has become known as "Successor ML" [0]. A large subset of Successor ML is common to SML/NJ, MLton, Poly/ML, MLKit and other implementations. That includes record update syntax, binary literals, and more expressive patterns among other deficiencies in Standard ML. For me the two big remaining issues are: 1) There's only limited Unicode support in both the core language and the standard library. This is a big issue for many real-world programs including these days the compilers for which SML is otherwise a wonderful language. 2) The module system is a "shadow language" [0] which mirrors parts of SML but which has less expressiveness where modules cannot be treated as first-class values in the program. Also if you define infix operators in a module their fixity isn't exported along with the function type. (Little annoyance that gets me every time I am inclined to write Haskell-style code with lots of operators. Though maybe that's just another hint from the universe that I shouldn't write code like that.) Of course, the fix to that would be a fundamentally different language; not a revised SML. [0] http://mlton.org/SuccessorML http://mlton.org/SuccessorML [1] https://gbracha.blogspot.com/2014/09/a-domain-of-shadows.html https://gbracha.blogspot.com/2014/09/a-domain-of-shadows.htm...

DeathArrow 10mo ago

For something a bit more modern but still related to OCaml, one can try F#.

greener_grass 10mo ago
F# is a practical choice but the language features are quite far behind OCaml now. {Ecosystem, Functors} - choose 1
- runevault 10mo ago
  From an outsider's perspective, it feels like Ocaml has more active development of features, between the new effects system they added in 5 and all the work Janestreet is doing to let Ocaml developers have more control over performance. F# is not stagnant thankfully, it gets updates with each new version of dotnet (though I haven't checked what is coming with dotnet 10), but I don't recall anything on the level of the above Ocaml changes in years.
  - greener_grass 10mo ago
    Applicative Computation Expressions are a big deal (added in F# 5). Recent changes have been smaller in scope. Unfortunately lots of the more advanced stuff seems to be blocked on C# team making a decision. They want a smooth interop story. But F# remains a solid choice for general purpose programming. It's fast, stable and .NET is mainstream.
    - runevault 10mo ago
      Oh yeah I love f#, I need to find more excuses to use it. I just wish it felt like MS was willing to invest more into it. But at least they have not abandoned it and continue to put some resources into its ongoing growth.
- phplovesong 10mo ago
  F# also has a real slow compiler. Last time hello world took a few secs on brand new mac.

sanufar 10mo ago

OCaml’s REPL is lovely, but I found myself having some friction with initial startup. The build/package system was pretty convoluted, and I ended up choosing JS’s Core stdlib for my needs (a simple compiler). With the new multicore release it’d be cool to see OCaml in some more practical projects!

paulsmith 10mo ago
As an OCaml-curious, is this the community recommendation, to choose the Jane Street stdlib if you’re just getting started?
- tlavoie 10mo ago
  It's probably the path of least resistance if following the Real World OCaml book (https://dev.realworldocaml.org/ https://dev.realworldocaml.org/), which is quite excellent.
- debugnik 10mo ago
  Many learning materials will push you that way, but the vast majority of FOSS packages don't use it. There's nothing inherently wrong with using Jane Street's stdlibs if you miss the goodies they provide, but be aware the API suffers breaking changes from time to time and they support less targets than regular OCaml. I personally stopped using them, and use a few libraries from dbunzli and c-cube instead to fill the gaps.

pkilgore 10mo ago

There's some other stuff, but I personally believe if the tooling was closer to Rust/Go than C, it would be a lot, lot more popular. Nobody wants to effectively learn a lisp to configure a build system.

phplovesong 10mo ago
Dune is quite good these days. The lisp part is really just sexps (not a full languge). But i kind of get your point.

_gmkt 10mo ago

Yes, in every ML/OCaml tutorial, sooner or later the words object, class, and type inference appear and that’s when a once–minimalist language turns into an academic Frankenstein.

rwmj 10mo ago
I don't think objects and classes are used much by OCaml programmers (not by me anyway). Type inference is a rather fundamental feature, and fairly easy to understand.
giovannibonetti 10mo ago
Why does type inference contribute to that issue?
Barrin92 10mo ago
It's not a minimalist language, you know what the "O" in Ocaml stands for right? It's a multi-paradigm language that explicitly accommodates more styles of programming than Caml, it's why it exists.

pulkas 10mo ago

darklang team loved ocaml too. in the end they ended up using f#.

karmakaze 10mo ago

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 more about day to day usage pros/cons.

ernst_klim 10mo ago
> I'd like to hear some practical reasons for preferring OCaml over F# Bigger native ecosystem. C#/.net integration is a double edged sword: a lot of libraries, but the libraries are not written in canonical F#. A lot of language features F# misses, like effect handlers, modules, GADTs etc.
- karmakaze 10mo ago
  I did get some sense of that where F# sort of (actually is) 2nd class to C# which is slowly gaining some F# features, but F# itself isn't well promoted/supported. As for missing language features, they can also be a double-edged sword. I slid down that slippery slope in an earlier venture with Scala. (IIRC mostly implicits and compile times).
- Nelkins 10mo ago
  There are libraries that simulate a lot of these things (e.g. https://github.com/G-Research/TypeEquality https://github.com/G-Research/TypeEquality for GADTs). You're absolutely right that it's not as first class as in OCaml, but the tools are there if you want them.
  - debugnik 10mo ago
    I've written type-equality witnesses in F#, they can kinda recover type equalities (with cast methods) but not refute them, so you still need to raise exceptions for those cases.
10mo ago

p0nce 10mo ago

Well I need both float and double, so cannot even start using it.

ModernMech 10mo ago

>why isn’t OCaml more popular? OCaml did become popular, but via Rust, which took the best parts of OCaml and made the language more imperative feeling. That's what OCaml was missing!

StopDisinfo910 10mo ago
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.
- deleted 10mo ago
  [deleted]
reddit_clone 10mo ago
Ocaml can be as imperative as you need it to be. Or as functional. It has no dogmatic inclination towards functional. It has a very pragmatic approach to mutation.
- talideon 10mo ago
  True, but writing imperative code in OCaml feels quite right. Maybe it's just me, but it always feels significantly clunkier than the functional equivalent. I've had things I've been implementing and though "this works be easier to express imperatively", and almost invariably I've gone and rewritten the code to be functional because of how ungainly the imperative implementation ended up being. It feels a bit too much like somebody embedded a subset of Rexx or Pascal awkwardly into an otherwise perfectly reasonable functional language
abathologist 10mo ago
As someone who has worked professionally in both, programming in rust does not feel much like programming in OCaml. Working with traits in an imperative manual memory managed language is really different than working with proper modules in a mixed paradigm language with an awesome GC.

pasxizeis 10mo ago

As a Rust newbie and seasoned Go dev, I'm pretty interested to knownwhere would people experienced in both OCaml and Haskell, would put it in the spectrum.

hollerith 10mo ago
What does "it" refer to? Ocaml?
7thaccount 10mo ago
What spectrum? Language practicality? Popularity? OCaml has some high profile use at Jane Street which is a major fintech firm. Haskell is more research oriented. Both are cool, but wouldn't be my choice for most uses.
bojo 10mo ago
My team still has 8 year old Haskell systems in production. We pivoted away from the language a few years ago, which I discuss here a bit: https://news.ycombinator.com/item?id=37746386 https://news.ycombinator.com/item?id=37746386 I personally love ML languages and would be happy to keep developing in them, but the ecosystem support can be a bit of a hassle if you aren't willing to invest in writing and maintaining libraries yourself.
deleted 10mo ago
[deleted]
jlouis 10mo ago
I don't think it's a spectrum. Languages have features/constructs. It's better to look at what those are. And far more importantly: how they interact. Take something like subtyping for instance. What makes this hard to implement is that it interacts with everything else in your language: polymorphism, GADTs, ... Or take something like Garbage Collection. It's presence/absence has a large say in everything done in said language. Rust is uniquely not GC'ed, but Go, OCaml and Haskell all are. That by itself creates some interesting behavior. If we hand something to a process and get something back, we don't care if the thing we handed got changed or not if we have a GC. But in Rust, we do. We can avoid allocations and keep references if the process didn't change the thing after all. This permeates all of the language.

efficax 10mo ago

OCaml is fantastic, but I avoided it and went with Rust for many projects because it had no multicore story and no green threads for a very long time. But it has that now, and I wish I could go back and start everything over in OCaml.

darksaints 10mo ago
I've also felt very similar, and adopted Rust for those reasons. Even though I'd still love to have a garbage collected, AOT compiled ML-variant, using OCaml still feels like a step backwards now. OCaml's module system and generics feel clumsy and unintuitive now that I've used Rust's Trait system.

fer 10mo ago

One of the best P2P clients ever created is written in OCaml: https://github.com/ygrek/mldonkey https://github.com/ygrek/mldonkey I'm still surprised it can do so many things so well, so fast.

japhib 10mo ago

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 has a great track record as a foundation for backend systems. It doesn't have static typing, although the type system is a lot stronger than most other dynamic languages like JS or Python, and the language devs are currently adding gradual type checking into the compiler.

timeon 10mo ago
I do not think that monads/type system are issue, but yes BEAM runtime is killer feature.
vvpan 10mo ago
If it's functional (recursion vs imperative loops) most people/organizations will not use it. At this point that is just the reality.
- zaphar 10mo ago
  Having loops is not the defining feature that separates functional from imperative. Where did this idea come from? I'm suddenly seeing it in a lot of places.
  - gmadsen 10mo ago
    its a simplification of immutability and its consequences
  - vvpan 10mo ago
    It is not the defining feature but loss of the loop is one of the most obvious differences for people who look at a functional language Rust has immutability, pattern matching, etc, but it remains an imperative language with "some functional features". Or this is my subjective analysis.

a-dub 10mo ago

fun fact: the secret sauce that makes fftw fast is a code generator written in ocaml: https://github.com/FFTW/fftw3/tree/master/genfft https://github.com/FFTW/fftw3/tree/master/genfft

yujzgzc 10mo ago

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

phplovesong 10mo ago
You would not really build the same software tho.
abathologist 10mo ago
> It's got about the same amount of type safety What?
- yujzgzc 10mo ago
  Both languages have robust and expressive type systems. My experience is that TypeScript's is also more flexible. In Ocaml everything is cool as long as you stick with the functional programming style. But every "interesting" program also has imperative, non-functional-programming parts, and TypeScript has really good automatic "type narrowing" features that make that part much safer in my experience. In Ocaml however, type narrowing isn't automatic at all.
  - abathologist 10mo ago
    TypeScript certainly has a more complicated and flexible type systems in many respects, but it is not the same w/r/t safety. It is quite common to run across `any`s all over the place in TypeScript code, and there is no such thing in OCaml. TypeScript's systems is explicitly unsound (i.e., not fully type safe) by design: https://www.typescriptlang.org/docs/handbook/type-compatibility.html#a-note-on-soundness https://www.typescriptlang.org/docs/handbook/type-compatibil...
    - yujzgzc 10mo ago
      Ocaml has exactly the same kinds of escape hatches, like Obj.magic or unsafe accessors. The way I see it. it's a matter of community practice more than language capabilities. Typescript in practice has has the safety net of being interpreted rather than compiled, so I guess people tend to abuse its type flexibility more. But if you write without the escape hatches in both languages, in my experience the safety is exactly the same and the cost of that safety is lower in TypeScript. A very common example I've encountered is values in a const array which you want to iterate on and have guarantees about. TypeScript has a great idiom for this: ``` const arr = ['a', 'b'] as const; type arrType = typeof arr[number]; for (const x of arr) { if (x === 'a') { ... } else { // Type checker knows x === 'b' } } ``` I haven't experienced the same with Ocaml

phplovesong 10mo ago

I kind of wish (like the OP mentioned) there was a ML (ocaml) like language that compiled to Go source. You would get the best of both worlds and access to a huge ecosystem.

nathcd 10mo ago
There's Borgo: https://github.com/borgo-lang/borgo https://github.com/borgo-lang/borgo I've never used it so can't speak from any experience, and unfortunately it doesn't seem particularly active (and doesn't mention a current status anywhere), and doesn't have a license, so shrug. When it's been posted here (https://news.ycombinator.com/item?id=40211891 https://news.ycombinator.com/item?id=40211891), people seemed pretty excited about it.
- phplovesong 10mo ago
  Borgo looks like some guys phd thesis. It looks like it was a fun experiment. I feel a new simple ocaml like language that just compiled to Go would be really popular, really fast. And it would not even need to build a ecosystem, as Go already have all the things you need. Something like what Gleam is for Erlang.

fermigier 10mo ago

Little known fact: OCaml was at one point called "Zinc" ("Zinc is not Caml").

Qem 10mo ago
Perhaps the language would be more lucky with the original name. Zinc is used to galvanize steel and prevent Rust formation[1]. [1] https://en.wikipedia.org/wiki/Galvanization https://en.wikipedia.org/wiki/Galvanization

ilaksh 10mo ago

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.

MeetingsBrowser 10mo ago
I think popularity and regarded favorably are probably inversely correlated. Many of the most popular languages are also the most hated. Many of the more niche languages are viewed the most favorably. It is easy to dislike something yo are familiar with, and easy to be overoptimistic about something you don't know as well. "the grass is always greener ... "
levzettelin 10mo ago
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.
- StopDisinfo910 10mo ago
  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.
- 999900000999 10mo ago
  The popularity of a language usually translates into better support, tooling and learning materials.

ArnavAgrawal03 10mo ago

Came here to say I love Ocaml too

timhh 10mo ago

> 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 add a single character and the error message is essentially "syntax error in these 1000 lines". * Ocamlfmt is pretty bad. It thinks it is writing prose. It will even put complex `match`es on one line if they fit. Really hurts readability. * The documentation is super terse. Very few examples. * OPAM. In theory... I feel like it should be great. But in practice I find it to be incomprehensible, full of surprising behaviours, and also surprisingly buggy. I still can't believe the bug where it can't find `curl` if you're in more than 32 Unix groups. * Optional type annotation for function signatures throws away a significant benefit of static typing - documentation/understanding and nice error messages. * Tiny ecosystem. Rust gets flak for its small standard library, but OCaml doesn't even have a built in function to copy files. * Like all FP languages it has a weird obsession with singly linked lists, which are actually a pretty awful data structure. It's not all bad though, and I'd definitely take it over C and Python. Definitely wouldn't pick it over Rust though, unless I was really worried about compile times.

tempodox 10mo ago
> The syntax is hard to parse for humans. Funny how tastes differ. I'm glad it has a syntax that eschews all the noise that the blub languages add.
systems 10mo ago
+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
- thaumasiotes 10mo ago

agentultra 10mo ago

Why isn't it more popular? I think Richard Feldman [0] proposed some of the most reasonable theories as to why functional programming isn't the norm. Your language needs to be the platform-exclusive language for a widely used platform, have a killer application for a highly desired application domain, or be backed by a monster war-chest of marketing money to sway opinions. Since Feldman's talk, Python has grown much faster in popularity in the sense of wide use in the market place... but mostly because it's the scripting language of choice for PyTorch and AI-adjacent libraries/tooling/frameworks which is... a killer application. I like OCaml. I started evaluating functional programming in it by taking the INRIA course online. I spent the last four and half years working in Haskell. I've built some side projects in Zig. I was a CL stan for many years. I asked this question a lot. We often say, "use the best tool for the job." Often that means, "use the tool that's available." I think languages like OCaml, Rust, Haskell etc can be "popular," but in the sense that people like to talk about them and want to learn them and be able to use them (at least, as trends come and go). It's different from "popular" as in, "widely adopted." [0] https://www.youtube.com/watch?v=QyJZzq0v7Z4 https://www.youtube.com/watch?v=QyJZzq0v7Z4

m3at 10mo ago
> mostly because it's the scripting language of choice for PyTorch and AI-adjacent libraries/tooling/frameworks I would politely disagree. Torch started in Lua, and switched to Python because of its already soaring popularity. Whatever drove Python's growth predates modern AI frameworks
- spooky_deep 10mo ago
  Google blessed Python at a time when Java didn’t even have lambdas.
- int_19h 10mo ago
  Python was already big for scientists back in 2010. I remember working on Python tooling at the time, and DS/ML was one of our single largest user groups. It was already popular enough to have an IDE specifically for scientific Python use: https://en.wikipedia.org/wiki/Spyder_(software) https://en.wikipedia.org/wiki/Spyder_(software). As far as I could tell, it had to do with two things. First, Python is notoriously dynamic and extensible, making it possible to implement "sloppy" syntax like advanced slicing or dataframes. But also, those guys had lots of pre-existing C and Fortran code, and Python had one of the easiest extensibility APIs to wrap it as high-level packages. And with IPython, you had a nice REPL with graphing to use all that from, and then of course notebooks happened.

rootnod3 10mo ago

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.

deleted 10mo ago
[deleted]

mikaeluman 10mo ago

I like the ML languages, and as many others I spent a lot of time with F#. I would love to spend more time but even though Microsoft gives it plenty of support (nowhere near as much as C#), the community is just too small (and seems to have gotten smaller). Looking at https://www.tiobe.com/tiobe-index/ https://www.tiobe.com/tiobe-index/ numbers fall off pretty quickly from the top 5-7. Guessing this is the same for OCaml, even if the language as such is nice.

throwa567543 10mo ago
Anecdotally we are using F# more than ever before, and it works for us for a large sized organisation. Fast code, it is keeping up with the .NET features that matter for that (e.g. spans), and tbh has still been getting better over the years. In fact I find some of the new features like Span, SIMD/intrinsics somewhat synergise with existing F# features (e.g. inline). C# IMO still hasn't quite caught up but is getting there. Comparing to Go/Java/etc I can usually get faster code out of the .NET runtime as well especially in our domain which requires large scale computation. If I was to move to something else for our domain it would be C++ or Rust. F# piggy backing of the .NET platform in general, has a decent ecosystem and easy onboarding cross platform and gets a lot "for free" (e.g. CLI, GC improvements). Community is an interesting thing, and for some people I guess it is important. For me language is just a tool having coded for quite some time and seen communities come and go; don't care about being known or showing an example per se. If the tool on the balance allows me to write faster code, with less errors quicker and can be given to generic teams (e.g. ex Python, JS devs) with some in house training its a win. For me personally I just keep building large scale interesting systems with F#; its a tool and once you get a hang of its quirks (it does have some small ones) quite a good one that hits that sweet spot IMO. My feeling however is with AI/LLM's communities and syntax in general is in decline and less important especially for niche languages. Language matters less than the platform, ecosystem, etc. Its easier to learn a language then ever before for example, and get help from it. Any zero cost abstraction can be emulated with more code generation as well as much as I would hate reviewing it. More important is can you read the review the code easily, and does the platform offer you the things you need to deliver software to your requirements or not and can people pick it up.

tasuki 10mo ago

> Fast compile times > Fewer abstractions, and an easy to understand runtime > Strong static guarantees > Functional programming constructs. Especially pattern matching and sum types. > Good performance > Good documentation I feel this is also Elm!

creata 10mo ago
Elm is pure-functional, unlike OCaml, which has easy escape hatches (refs) when you need mutability.
- tasuki 10mo ago
  I feel as a frontend language Elm has somewhat less need for mutability. At least I haven't missed it.

pshirshov 10mo ago

> why isn’t OCaml more popular? Hashtbl.add table key value Precedence, nominal inheritance, HKTs, incoherent typeclasses make Scala much less aesthetically pleasant but much more productive.

rixed 10mo ago
Hashtbl.add table key value What's your point with that?

seabrookmx 10mo ago

Lots of complaints about the OCaml syntax here.. is ReasonML dead?

davesnx 10mo ago
is very alive, released with OCaml 5.4 support and improving bit by bit

olivia-banks 10mo ago

> 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 want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt. – Rob Pike 1" "It must be familiar, roughly C-like. Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical. – Rob Pike 2" Talking as someone who wrote OCaml at work for a while, the benefits of functional programming and the type guarantees that it's ilk provides cannot be understated; you only start to reach them, however, once most developers have shifted their way of thinking rather extremely, which is a time cost that that designers of Go did not want new Googlers to pay.

VirusNewbie 10mo ago
You would be surprised how many Googlers think the Go team is making bad decision after bad decision.
- olivia-banks 10mo ago
  How so? I’m not that familiar with Go anymore.
  - hyperhopper 10mo ago
    Search any Go codebase for err != nil, for starters.
    - olivia-banks 10mo ago
      Well, sure, but this is a problem nearly as old as Go itself. I thought they were referring to larger more recent things, like how generics work, or something to that effect.

olivia-banks 10mo ago

> OCaml is weird in that it’s a garbage collected language for systems, similar to Go. I don't understand why this isn't more popular. For most areas, I'd gladly take a garbage collector over manual memory management or explicit borrow checking. I think the GC in D was one of it's best features, but it's downfall nonetheless as everyone got spooked by those two letters.

DeathArrow 10mo ago

The problem I see for the adoption is that the landscape is very fragmented. ML is a family of languages and we have StandardML with different implementations, OCaml with official path and JS path, F# and whatnot. This is the problem for Lisp, too as there are many Lisps.

StopDisinfo910 10mo ago

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.

fithisux 10mo ago

"but the more I use it the more I feel like this old language had it all figured out," sounds superficially similar to Common Lisp