33 ms·

Why I love OCaml (2023)

391 points by art-w 11mo ago

dmpk2k 11mo 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. :/
- StopDisinfo910 11mo 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 11mo 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 11mo 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 11mo ago
        [deleted]
      - dmpk2k 11mo ago
        Maybe it's post-hoc? I wanted to use OCaml since 2002, since it was a GC'd language with good performance, achieving a lot with relatively few lines of code. Being a language nerd, I was (am?) positively inclined to the language. Yet there was always something that made it notably less pleasant to solve my current problem in than in than some other language. If it had trouble getting traction with me, that's bad 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.
        hollerith 11mo ago
        GC was standard already in 2000: Perl, Python, Ruby, Java and JS all had GC from day 1.
        dmpk2k 11mo ago
        Crappy GC for most of them, but... fair point.
        creata 11mo ago
        Off-topic: What language would you say is the closest thing to "Rust with a GC"? (Rust has refcounting, but it's slow, and needing to handle cycles manually limits its usefulness.)
        11mo ago
    - StopDisinfo910 11mo ago
      > there's multiple standard libraries 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.
    - brabel 11mo ago
      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!
  - greener_grass 11mo ago
    For me the issue is ecosystem. The foundations are great but I need more useful and well supported packages. For example, there is no OAuth2 client library for OCaml [1] [1] https://ocaml.org/docs/is-ocaml-web-yet https://ocaml.org/docs/is-ocaml-web-yet
  - creata 11mo ago
    > Because plenty of people have been shipping great projects in Ocaml What applications are written in OCaml? All I can think of (which says more about me than it does about OCaml) is the original Rust compiler. Even Haskell has Pandoc and Xmonad.
    - jlouis 11mo ago
      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.
    - StopDisinfo910 11mo ago
      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.
- jddj 11mo ago
  Almost there, but in the meantime supporting a casual squillion dollars of trades at JS
  - zdragnar 11mo 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 11mo 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 11mo 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 11mo 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 11mo 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.
- hardwaregeek 11mo 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 11mo ago
    That would be Elm :)
    - giovannibonetti 11mo ago
      Roc says hi!
    - 1-more 11mo 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 11mo 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 11mo ago
  [deleted]
pohl 11mo 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 11mo 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 11mo 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 11mo 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 11mo ago
      I believe many people use PL to mean programming language. I'm wondering if your joke just wooshed me.
      - embedding-shape 11mo 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 11mo 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 11mo 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 11mo ago
  I don't see it...the end of the document is: </div> </body> </html>
  - mccd 11mo ago
    I updated it just now :).
- mccd 11mo ago
  Fixed it, thanks for pointing it out :)
fmbb 11mo 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 11mo 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 11mo 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 11mo 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 11mo ago
For something a bit more modern but still related to OCaml, one can try F#.
- greener_grass 11mo ago
  F# is a practical choice but the language features are quite far behind OCaml now. {Ecosystem, Functors} - choose 1
  - runevault 11mo 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 11mo 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 11mo 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 11mo ago
    F# also has a real slow compiler. Last time hello world took a few secs on brand new mac.
sanufar 11mo 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 11mo ago
  As an OCaml-curious, is this the community recommendation, to choose the Jane Street stdlib if you’re just getting started?
  - tlavoie 11mo 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 11mo 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 11mo 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 11mo 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 11mo 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 11mo 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 11mo ago
  Why does type inference contribute to that issue?
- Barrin92 11mo 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 11mo ago
darklang team loved ocaml too. in the end they ended up using f#.
karmakaze 11mo 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 11mo 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 11mo 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 11mo 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 11mo 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.
- 11mo ago
p0nce 11mo ago
Well I need both float and double, so cannot even start using it.
ModernMech 11mo 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 11mo 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 11mo ago
    [deleted]
- reddit_clone 11mo 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 11mo 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 11mo 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 11mo 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 11mo ago
  What does "it" refer to? Ocaml?
- 7thaccount 11mo 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 11mo 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 11mo ago
  [deleted]
- jlouis 11mo 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 11mo 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 11mo 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 11mo 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 11mo 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.
- DrewADesign 11mo ago
  I think it’s odd that elixir doesn’t get more love. It ticks a lot of boxes that folks here get excited about, has a great ecosystem and tooling, BEAM is great, and it’s much more syntactically familiar than erlang to my eye. I know of a couple companies aside from the perennial goto examples that built sizable saas products backed by it.
  - skybrian 11mo ago
    What does deployment look like? Can you get a static binary easily like with Go?
    - crdrost 11mo ago
      You don't get it from language tooling because you are compiling to a bytecode that runs in a virtual machine (BEAM). The current tool to wrap your bytecode with a VM so that it becomes standalone is Burrito[1], but there's some language support[2] (I think only for the arch that your CPU is currently running? contra Golang) and an older project called Distillery[3]. 1: https://github.com/burrito-elixir/burrito https://github.com/burrito-elixir/burrito 2: https://hexdocs.pm/mix/Mix.Tasks.Release.html https://hexdocs.pm/mix/Mix.Tasks.Release.html 3: https://hexdocs.pm/distillery/home.html https://hexdocs.pm/distillery/home.html
  - pluralmonad 11mo ago
a-dub 11mo 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 11mo 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 11mo ago
  You would not really build the same software tho.
- abathologist 11mo ago
  > It's got about the same amount of type safety What?
  - yujzgzc 11mo 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 11mo 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 11mo 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 11mo 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 11mo 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 11mo 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 11mo ago
Little known fact: OCaml was at one point called "Zinc" ("Zinc is not Caml").
- Qem 11mo 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 11mo 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 11mo 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 11mo 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 11mo 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 11mo ago
    The popularity of a language usually translates into better support, tooling and learning materials.
ArnavAgrawal03 11mo ago
Came here to say I love Ocaml too
timhh 11mo 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.
- systems 11mo 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 11mo ago
    > just to give an idea how bad, until recently, you could not just go to ocaml.org and download ocaml for windows On the other hand, you could get ocaml for Windows from Microsoft ever since 2005.
agentultra 11mo 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 11mo 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
  - int_19h 11mo 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 11mo 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 11mo ago
  [deleted]
mikaeluman 11mo 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 11mo 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 11mo 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 11mo ago
  Elm is pure-functional, unlike OCaml, which has easy escape hatches (refs) when you need mutability.
  - tasuki 11mo ago
    I feel as a frontend language Elm has somewhat less need for mutability. At least I haven't missed it.
pshirshov 11mo 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 11mo ago
  Hashtbl.add table key value What's your point with that?
seabrookmx 11mo ago
Lots of complaints about the OCaml syntax here.. is ReasonML dead?
- davesnx 11mo ago
  is very alive, released with OCaml 5.4 support and improving bit by bit
olivia-banks 11mo 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 11mo ago
  You would be surprised how many Googlers think the Go team is making bad decision after bad decision.
  - olivia-banks 11mo ago
    How so? I’m not that familiar with Go anymore.
    - hyperhopper 11mo ago
      Search any Go codebase for err != nil, for starters.
      - olivia-banks 11mo 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 11mo 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 11mo 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 11mo 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 11mo 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 11mo ago

dmpk2k 11mo 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. :/

StopDisinfo910 11mo 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 11mo 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 11mo 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 11mo ago
      [deleted]
    - dmpk2k 11mo ago
      Maybe it's post-hoc? I wanted to use OCaml since 2002, since it was a GC'd language with good performance, achieving a lot with relatively few lines of code. Being a language nerd, I was (am?) positively inclined to the language. Yet there was always something that made it notably less pleasant to solve my current problem in than in than some other language. If it had trouble getting traction with me, that's bad 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.
      - hollerith 11mo ago
        GC was standard already in 2000: Perl, Python, Ruby, Java and JS all had GC from day 1.
        dmpk2k 11mo ago
        Crappy GC for most of them, but... fair point.
      - creata 11mo ago
        Off-topic: What language would you say is the closest thing to "Rust with a GC"? (Rust has refcounting, but it's slow, and needing to handle cycles manually limits its usefulness.)
        11mo ago
  - StopDisinfo910 11mo ago
    > there's multiple standard libraries 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.
  - brabel 11mo ago
    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!
- greener_grass 11mo ago
  For me the issue is ecosystem. The foundations are great but I need more useful and well supported packages. For example, there is no OAuth2 client library for OCaml [1] [1] https://ocaml.org/docs/is-ocaml-web-yet https://ocaml.org/docs/is-ocaml-web-yet
- creata 11mo ago
  > Because plenty of people have been shipping great projects in Ocaml What applications are written in OCaml? All I can think of (which says more about me than it does about OCaml) is the original Rust compiler. Even Haskell has Pandoc and Xmonad.
  - jlouis 11mo ago
    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.
  - StopDisinfo910 11mo ago
    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.
jddj 11mo ago
Almost there, but in the meantime supporting a casual squillion dollars of trades at JS
- zdragnar 11mo 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 11mo 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 11mo 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 11mo 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 11mo 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.
hardwaregeek 11mo 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 11mo ago
  That would be Elm :)
  - giovannibonetti 11mo ago
    Roc says hi!
  - 1-more 11mo 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 11mo 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 11mo ago
[deleted]

pohl 11mo 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 11mo 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 11mo 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 11mo 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 11mo ago
    I believe many people use PL to mean programming language. I'm wondering if your joke just wooshed me.
    - embedding-shape 11mo 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 11mo 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 11mo 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 11mo ago
I don't see it...the end of the document is: </div> </body> </html>
- mccd 11mo ago
  I updated it just now :).
mccd 11mo ago
Fixed it, thanks for pointing it out :)

fmbb 11mo 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 11mo 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 11mo 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 11mo 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 11mo ago

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

greener_grass 11mo ago
F# is a practical choice but the language features are quite far behind OCaml now. {Ecosystem, Functors} - choose 1
- runevault 11mo 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 11mo 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 11mo 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 11mo ago
  F# also has a real slow compiler. Last time hello world took a few secs on brand new mac.

sanufar 11mo 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 11mo ago
As an OCaml-curious, is this the community recommendation, to choose the Jane Street stdlib if you’re just getting started?
- tlavoie 11mo 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 11mo 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 11mo 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 11mo 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 11mo 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 11mo 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 11mo ago
Why does type inference contribute to that issue?
Barrin92 11mo 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 11mo ago

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

karmakaze 11mo 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 11mo 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 11mo 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 11mo 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 11mo 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.
11mo ago

p0nce 11mo ago

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

ModernMech 11mo 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 11mo 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 11mo ago
  [deleted]
reddit_clone 11mo 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 11mo 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 11mo 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 11mo 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 11mo ago
What does "it" refer to? Ocaml?
7thaccount 11mo 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 11mo 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 11mo ago
[deleted]
jlouis 11mo 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 11mo 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 11mo 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 11mo 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 11mo 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.

DrewADesign 11mo ago
I think it’s odd that elixir doesn’t get more love. It ticks a lot of boxes that folks here get excited about, has a great ecosystem and tooling, BEAM is great, and it’s much more syntactically familiar than erlang to my eye. I know of a couple companies aside from the perennial goto examples that built sizable saas products backed by it.
- skybrian 11mo ago
  What does deployment look like? Can you get a static binary easily like with Go?
  - crdrost 11mo ago
    You don't get it from language tooling because you are compiling to a bytecode that runs in a virtual machine (BEAM). The current tool to wrap your bytecode with a VM so that it becomes standalone is Burrito[1], but there's some language support[2] (I think only for the arch that your CPU is currently running? contra Golang) and an older project called Distillery[3]. 1: https://github.com/burrito-elixir/burrito https://github.com/burrito-elixir/burrito 2: https://hexdocs.pm/mix/Mix.Tasks.Release.html https://hexdocs.pm/mix/Mix.Tasks.Release.html 3: https://hexdocs.pm/distillery/home.html https://hexdocs.pm/distillery/home.html
- pluralmonad 11mo ago

a-dub 11mo 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 11mo 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 11mo ago
You would not really build the same software tho.
abathologist 11mo ago
> It's got about the same amount of type safety What?
- yujzgzc 11mo 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 11mo 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 11mo 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 11mo 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 11mo 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 11mo 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 11mo ago

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

Qem 11mo 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 11mo 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 11mo 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 11mo 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 11mo 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 11mo ago
  The popularity of a language usually translates into better support, tooling and learning materials.

ArnavAgrawal03 11mo ago

Came here to say I love Ocaml too

timhh 11mo 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.

systems 11mo 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 11mo ago
  > just to give an idea how bad, until recently, you could not just go to ocaml.org and download ocaml for windows On the other hand, you could get ocaml for Windows from Microsoft ever since 2005.

agentultra 11mo 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 11mo 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
- int_19h 11mo 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 11mo 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 11mo ago
[deleted]

mikaeluman 11mo 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 11mo 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 11mo 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 11mo ago
Elm is pure-functional, unlike OCaml, which has easy escape hatches (refs) when you need mutability.
- tasuki 11mo ago
  I feel as a frontend language Elm has somewhat less need for mutability. At least I haven't missed it.

pshirshov 11mo 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 11mo ago
Hashtbl.add table key value What's your point with that?

seabrookmx 11mo ago

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

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

olivia-banks 11mo 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 11mo ago
You would be surprised how many Googlers think the Go team is making bad decision after bad decision.
- olivia-banks 11mo ago
  How so? I’m not that familiar with Go anymore.
  - hyperhopper 11mo ago
    Search any Go codebase for err != nil, for starters.
    - olivia-banks 11mo 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 11mo 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 11mo 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 11mo 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 11mo 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