[HN Gopher] Why I love OCaml (2023)
___________________________________________________________________
Why I love OCaml (2023)
Author : art-w
Score : 379 points
Date : 2025-11-07 14:05 UTC (1 days ago)
(HTM) web link (mccd.space)
(TXT) w3m dump (mccd.space)
| dmpk2k wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| dmpk2k wrote:
| 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 wrote:
| GC was standard already in 2000: Perl, Python, Ruby, Java
| and JS all had GC from day 1.
| dmpk2k wrote:
| Crappy GC for most of them, but... fair point.
| creata wrote:
| 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.)
| whats_the_buzz wrote:
| The closest thing to "Rust with a GC" in my mind is
| Ponylang or just Pony:
|
| https://www.ponylang.io/
| https://github.com/ponylang/ponyc
|
| The Pony community is here:
|
| https://ponylang.zulipchat.com/
|
| Pony's garbage collection and runtime can yield
| performance faster than C/C++/Rust because the compiler
| eliminates data races at compile time, and thus no locks
| are needed.
|
| It features implementations of Dmitri Vyukov
| (www.1024cores.net) algorithms for work stealing and
| Multi-producer single consumer queues that use only a
| single atomic instruction to read. The designer, Sylvan
| Clebsch, is an ex-game-developer and ex-high-frequency-
| trading-infrastructure engineering lead; he knew what he
| was doing when he designed the language for high
| performance on multicore systems.
|
| On the other hand, you do have to re-wire your thinking
| to think in terms of Actors and their state, and this is
| kind of hard to wrap one's head around if you are used to
| Go's CSP or the popular async/await approaches -- it is a
| somewhat different paradigm.
| StopDisinfo910 wrote:
| > 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 wrote:
| 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 wrote:
| 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
| creata wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| Almost there, but in the meantime supporting a casual squillion
| dollars of trades at JS
| zdragnar wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Yes and they had to basically build their own version of the
| compiler to keep everything from falling over
| (https://oxcaml.org/).
| byefruit wrote:
| 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 wrote:
| > 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 wrote:
| Yes but the context of the thread is OCaml being "almost
| there". Having to build this stuff in-house is pretty
| good evidence.
| StopDisinfo910 wrote:
| 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 wrote:
| 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
| abathologist wrote:
| A different perspective is that JS has made practical
| application of PLT part of their secret sauce, and
| deepening into their PLT roots is thickening the sauce.
| procaryote wrote:
| 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 wrote:
| Clearly Jane Street wouldn't be where it is, a top
| proprietary trading firm in US, without static type
| checking.
| 7thaccount wrote:
| 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 wrote:
| > 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.
| 7thaccount wrote:
| Do those devs actively use OCaml? I thought most of the
| folks writing OCaml were writing the actual trade
| algorithms as opposed to infrastructure folks. My post
| was made off what I recall their lead technologist
| saying.
| wk_end wrote:
| Absolutely. Everyone uses OCaml at Jane Street; pretty
| much everything at Jane Street is OCaml. If an OCaml
| version of something doesn't exist, there's a decent
| enough chance that they'll write it themselves rather
| than resort to a non-OCaml solution.
|
| Like I said, my information might be a hair out of date,
| but it's first-hand.
| 7thaccount wrote:
| Gotcha. Mine is just some old blog posts and a long talk
| from the guy that got OCaml started. Nothing like your
| actual first person experience. Thanks for adding!
| bsder wrote:
| Yes, _everybody_ in JaneStreet is expected to be able to
| use Ocaml, Neovim, and R /Julia/etc.
|
| Everybody in the company is expected to be able to sling
| numbers in text on a computer super efficiently.
| hardwaregeek wrote:
| 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/
| greener_grass wrote:
| That would be Elm :)
| giovannibonetti wrote:
| Roc says hi!
| 1-more wrote:
| 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
| specialgoodness wrote:
| Xavier Leroy as Lou Reed... :-) Don't forget the amazing
| theorem provers too, like Imandra (
| https://www.imandra.ai/core ), HOL-Light ( https://hol-
| light.github.io/ ) and Rocq ( https://rocq-prover.org/ ), ...
| !
| pohl wrote:
| 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 wrote:
| ML blew my mind back in the late 1980s when I got to use it on
| a 80286 machine for the first time!
| kjmh wrote:
| ML refers to Meta Language and LLM refers to Languages and
| Logic Montreal [0], a PL theory group. [0] https://llm.uqam.ca
| embedding-shape wrote:
| > 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 wrote:
| I believe many people use PL to mean programming language.
| I'm wondering if your joke just wooshed me.
| embedding-shape wrote:
| 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 wrote:
| 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...
| bigstrat2003 wrote:
| > make a New Year's resolution that we will never follow,
| to actually pick up those great languages and write
| something in them...
|
| Why must you call me out in this way? How did I wrong
| you, that I deserve this?
| seanw444 wrote:
| I'd rather have that issue than seeing "AI" plastered all over
| the place. I'm of the opinion AI should be reserved for
| artificial _general_ intelligence. These things aren 't
| intelligent yet. They're just em-bloat-ified traditional
| machine learning techniques. Not that they're useless. I just
| hate the terminology.
|
| If people start using the term AI, we better be living in I,
| Robot. Not whatever the hell this is.
|
| Tangential rant. Sorry.
| crdrost wrote:
| We lost this fight at least by 1994 when Sun acquired
| "Thinking Machines," which to its credit _was_ bankrupting
| itself by making highly parallel supercomputers, at least.
| Now of course there is a new AI company of the same name. If
| the wrestling world echoes the computing world, one can only
| wonder what in 5-10 years will be the equivalent of
| Undertaker throwing Mankind off of Hell In A Cell to plummet
| 16 feet down through an announcer's table...
| timeon wrote:
| I also think AK would fit better.
| fuzztester wrote:
| AK-42
| afiori wrote:
| I believe that current publicly available Ais are more
| intelligent than a non trivial fraction of adults.
| jrh3 wrote:
| Thanks for posting about ML! I made a post similar to yours a
| couple of years ago and got downvoted, lol.
| wslh wrote:
| 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 wrote:
| I don't see it...the end of the document is:
| </div> </body> </html>
| mccd wrote:
| I updated it just now :).
| mccd wrote:
| Fixed it, thanks for pointing it out :)
| fmbb wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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
|
| [1] https://gbracha.blogspot.com/2014/09/a-domain-of-
| shadows.htm...
| jimbokun wrote:
| As I was saying, Successor ML is like OCaml, but perfect!
| cmrdporcupine wrote:
| I far preferred Standard ML when I learned both back in the
| day, but it was OCaml that won the headspace it seemed.
|
| Ironically probably because it had the "O"bjects in it, "which
| was the style of the time"... something that has since dropped
| off the trendiness charts.
| abathologist wrote:
| I love SML, and came to OCaml a bit begrudgingly initially just
| for a larger ecosystem. But, I think the object system gets a
| unjustly bad wrap. The OCaml object system is dope. It is
| rarely needed and not the best feature for most use cases, but
| when you want structurally-typed records, or need open
| recursion (or need to represent JS objects for the amazing
| `Js_of_ocaml`), they are a perfect fit.
| DeathArrow wrote:
| For something a bit more modern but still related to OCaml, one
| can try F#.
| greener_grass wrote:
| F# is a practical choice but the language features are quite
| far behind OCaml now.
|
| {Ecosystem, Functors} - choose 1
| runevault wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| F# also has a real slow compiler. Last time hello world took
| a few secs on brand new mac.
| Bootvis wrote:
| What about a strict subset of C#. The use case for F# seems
| to be shrinking because MS is putting all its energy in
| language.
| greener_grass wrote:
| This isn't true, because more is not always better.
|
| C# has lots of anti-features that F# does not have.
| sanufar wrote:
| 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 wrote:
| As an OCaml-curious, is this the community recommendation, to
| choose the Jane Street stdlib if you're just getting started?
| tlavoie wrote:
| It's probably the path of least resistance if following the
| Real World OCaml book (https://dev.realworldocaml.org/),
| which is quite excellent.
| pkilgore wrote:
| 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 wrote:
| Dune is quite good these days. The lisp part is really just
| sexps (not a full languge). But i kind of get your point.
| ufko_org wrote:
| 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 wrote:
| 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 wrote:
| Why does type inference contribute to that issue?
| Barrin92 wrote:
| 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 wrote:
| darklang team loved ocaml too. in the end they ended up using f#.
| karmakaze wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| There are libraries that simulate a lot of these things (e.g.
| 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 wrote:
| 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.
| debugnik wrote:
| It's a matter of trends: F# is losing compatibility with the
| overall CLR ecosystem due to the churn in C# features with poor
| F# interop, but F# has already mingled its design with the
| CLR's, too much to live on its own as a native language. Plus
| its compiler is slow and the tooling is getting increasingly
| unstable.
|
| Meanwhile, OCaml got rid of its global lock, got a really fast-
| compiling native toolchain with stable and improving editor
| tooling, and has a cleaner language design with some really
| powerful features unavailable to F#, like modules/functors,
| GADTs, effects or preprocessors. It somehow got immutable
| arrays before F#!
|
| F# still has an edge on some domains due to having unboxed
| types, SIMD, better Windows support and the CLR's overall
| performance. But the first two are already in the OxCaml fork
| and will hopefully get upstreamed in the following years, and
| the third is improving already, now that the opam package
| manager supports Windows.
| neonsunset wrote:
| > has an edge on some domains due to having unboxed types
|
| If a language makes "unboxed types" a feature, a specific
| distinction, and has to sell "removing global lock" as
| something that is a massive breakthrough and not table stakes
| from 1.0, it can't possibly be compared to F# in favourable
| light.
| debugnik wrote:
| I vouched for your dead comment because I get where you're
| coming from. But OCaml 1.0 was in 1996 in an academic
| setting. I care about the language I can use now, not the
| one I didn't use.
|
| Let's not dismiss that their solution to remove the global
| lock has been both simpler than Python's (better funded?)
| ongoing work and backwards compatible; and the multicore
| support came with both a memory model with strong
| guarantees around data races, and effect handlers which
| generalize lightweight threads.
|
| I agree that lack of unboxed types is a fatal flaw for
| several domains (Worse, domains I care about! I usually
| consider Rust/Go/.NET for those.) But when the comparison
| with OCaml is favourable to F#, the gap isn't much wider
| than just unboxed types. F# has an identity crisis between
| the ML parts and the CLR parts, its C# interop is decaying
| as the ecosystem evolves, and newer .NET APIs aren't even
| compatible with F# idioms (here's a .NET 6+ example [1]).
|
| [1]: https://sharplab.io/#v2:DYLgZgzgNAJiDUAfA9gBwKYDsAEBlA
| nhAC7o...
| neonsunset wrote:
| Ref structs are hard to solve because they require, in
| some ways, a lot more work than the way C# solved the
| lifetimes as the lifetimes in F# may need to become much
| closer to what they are in Rust. Some constructs may not
| be able to consume them still (can't move ref struct into
| an object with effective lifetime 'static) and there
| really is no easy solution short of language editions and
| breaking standard library changes. A limited improvement
| is possible, but we're still in the realm where the
| lifetimes may become a part of type identity or somehow
| generalized over, which is hard.
| mrkeen wrote:
| Where can I read more on F# unboxed types? My searches are
| only turning up examples of unboxed primitives.
|
| Where's the equivalent to https://hackage-
| content.haskell.org/package/vector-0.13.2.0/... ?
| debugnik wrote:
| F# uses the CLR term "value types" instead, or sometimes
| "struct" types as in the C# keyword.
|
| These are usually defined with the [<Struct>] attribute
| over a regular type definition, or using the struct
| keyword before tuple/anonymous record types. Also, the
| original 'T option type now has a value-type successor 'T
| voption.
| DeathArrow wrote:
| In .NET the unboxed types are value types and boxed types
| are reference types. And you can box and unbox them.
| debois wrote:
| We've used f# professionally for the computations-intensive
| parts of our product for a couple of years. Here's what comes
| to mind:
|
| 1. Interop with C# is great, but interop for C# clients using
| an F# library is terrible. C# wants more explicit types, which
| can be quite hard for the F# authors to write, and downright
| impossible for C# programmers to figure out. You end up
| maintaining a C#-shell for your F# program, and sooner or later
| you find yourself doing "just a tiny feature" in the C# shell
| to avoid the hassle. Now you have a weird hybrid code base.
|
| 2. Dotnet ecosystem is comprehensive, you've got state-of-the
| web app frameworks, ORMs, what have you. But is all OOP, state
| abounds, referential equality is the norm. If you want to write
| Ocaml/F#, you don't want to think like that. (And once you've
| used discriminated unions, C# error-handling seems like it
| belongs in the 1980'ies.)
|
| 3. The Microsoft toolchain is cool and smooth when it works,
| very hard to wrangle when it doesn't. Seemingly simple things,
| like copying static files to output folders, require semi-
| archaic invocations in XML file. It's about mindset: if
| development is clicking things in a GUI for you, Visual Studio
| is great (until it stubbornly refuses to do something) ; if you
| want more Unix/CLI approach, it can be done, and vscode, will
| sort of help you, but it's awkward.
|
| 4. Compile-times used to be great, but are deteriorating for
| us. (This is both F# and C#.)
|
| 5. Perf was never a problem.
|
| 6. Light syntax (indentation defines block structure) is very
| nice until it isn't; then you spend 45 minutes how to indent
| record updates. (Incidentally, "nice-until-it-isn't" is a good
| headline for the whole dotnet ecosystem.
|
| 7. Testing is quite doable with dotnet frameworks, but awkward.
| Moreover. you'll want something like quickcheck and maybe
| fuzzing; they exist, but again, awkward.
|
| We've been looking at ocaml recently, and I don't buy the
| framework/ecosystem argument. On the contrary, all the
| important stuff is there, and seems sometimes easier to use.
| Having written some experimental code in Ocaml, I think
| language ergonomics are better. It sort of makes sense: the
| Ocaml guys have had 35 years or so to make the language /nice/.
| I think they succeeded, at least writing feels, somehow, much
| more natural and much less inhibited than writing F#.
| int_19h wrote:
| OCaml is a much more powerful language. Take a look at
| functors, for example, or modules as first-class values, or
| GADTs, or its object system that can do type inference from
| use: # let foo x = x#frob;; val foo : <
| frob : 'a; .. > -> 'a = <fun>
|
| F# is often called "OCaml for .NET", but it is a
| misrepresentation. It is an ML-family language for .NET, but
| aside from that ML core they don't have much in common.
|
| Whether those features are more valuable to you than the
| ability to tap into .NET libraries depends largely on what
| you're doing.
| p0nce wrote:
| Well I need both float and double, so cannot even start using it.
| ModernMech wrote:
| >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 wrote:
| 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.
| reddit_clone wrote:
| 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 wrote:
| 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 wrote:
| 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.
| int_19h wrote:
| Aside from ADTs, what else did Rust take from OCaml?
| ModernMech wrote:
| Expression-based, immutable by default, pattern matching,
| static typing, and result / option types are the mix of
| features that make Rust what it is at its core, and each of
| those you'll find in OCaml. There's a couple others but
| that's the heart of it.
|
| I'm not saying that Rust feels like Ocaml as some are
| interpreting, I said Rust is more imperative feeling, they're
| not the same. The reason Rust has had success bringing these
| features to the mainstream where Ocaml has not, I believe, is
| because Rust does not describe itself as a functional
| language, where as Ocaml does, right up front. Therefore,
| despite Rust having a reputation for being difficult, new
| learners are less intimidated by it than something calling
| itself "functional". I see it all the time. By the time they
| learn Rust, they are ready to take on a language like Ocaml,
| because they've already learned some of the best parts of
| that language _via_ Rust.
|
| Note my comment about their similarities is not at the level
| of borrow checkers and garbage collectors.
| pasxizeis wrote:
| 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 wrote:
| What does "it" refer to? Ocaml?
| 7thaccount wrote:
| 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 wrote:
| 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
|
| 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.
| jlouis wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| One of the best P2P clients ever created is written in OCaml:
| https://github.com/ygrek/mldonkey
|
| I'm still surprised it can do so many things so well, so fast.
| japhib wrote:
| 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 wrote:
| 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 wrote:
| What does deployment look like? Can you get a static binary
| easily like with Go?
| crdrost wrote:
| 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
|
| 2: https://hexdocs.pm/mix/Mix.Tasks.Release.html
|
| 3: https://hexdocs.pm/distillery/home.html
| pluralmonad wrote:
| Elixir is good at managing complexity. I love flattening
| hierarchy and dealing with edge cases right in function
| definitions using pattern matching. Every other language
| without it just feels crippled after getting used to the
| feature.
| cardanome wrote:
| The backend work I do is just super boring.
|
| I always wanted to learn Elixir but never had a project where
| it could show it strengths. Good old PHP works perfectly
| fine.
|
| Also corporations like their devs to be easily replaceable
| which is easier with more mainstream languages, so it is
| always hard for "newer" languages to gain traction. That said
| I am totally rooting for Elixir.
| DrewADesign wrote:
| I think it's great for boring stuff -- the Phoenix web
| framework is really straightforward. Learning a whole new
| language paradigm and environment for a professional
| project you need to be productive in ASAP is definitely the
| worst kind of 'not boring' though.
|
| I know of a Haskell shop and everybody said they'd have a
| hell of a time finding people... but all them nerds were
| (and are) tripping over themselves to work there because
| they love Haskell... though some I've talked to ended up
| not liking Haskell _in production_ after working there.
| There seems to be a similar dynamic, if a bit less extreme,
| in Elixir shops.
| lenkite wrote:
| The BEAM VM executing bytecode is slower than a compiled
| binary. Sure, it is great when compared to Python and other
| interpreted languages. Not so much when you need fast
| processing and raw CPU performance. It also loses out to the
| JVM in performance, but wins in memory consumption.
| DrewADesign wrote:
| But how many things involve fulfilling basic requests over
| a network pulling information from a database? Most things
| just don't need that kind of performance.
| lenkite wrote:
| Sure for basic, dead CRUD, the choice of middleware
| language rarely makes any difference.
|
| But even bog-standard business processes eventually find
| the need for data-processing, crypto and parsing - the
| use-cases where people code Elixir NIF's. That is why for
| example you have projects like html5ever_elixir for
| parsing HTML/XML. Another use case is crypto - you have
| NIF's for several crypto libraries. Data processing -
| there are NIF's for Rust polars.
| DrewADesign wrote:
| > Sure for basic, dead CRUD
|
| From a technical perspective, this is the overwhelming
| majority of what makes the Net happen. BEAM is great for
| that and many other things, like extremely reliable
| communication streams.
|
| Use the right tool for the job. Rust sucks for high-level
| systems automation but that doesn't make it any less
| useful than bash. It's all about about use cases and
| Elixir fits many common use cases nicely, while providing
| some nice-to-haves that people often ask for in other
| common web dev environments.
| dmpk2k wrote:
| It is slower, but a big cause of the slowness is a lot of
| copying (immutable data structures and separate heaps for
| every process). Nowadays the BEAM has a JIT.
|
| If you use type guards correctly the performance can be
| surprisingly good. Not C/C++/Rust/Go/Java good, but not too
| far off either. This is definitely a corner-case though.
| phplovesong wrote:
| Gleam also. But i cant justify a non compiled language in many
| things i do.
| cultofmetatron wrote:
| gleam is compiled... to erlang bytecode
| seafoamteal wrote:
| It's compiled to Erlang, not BEAM bytecode, as the latter
| is not a stable, backward-compatible API to target, and you
| lose all of the optimization work put into the Erlang
| compiler. It's also compiled to JavaScript, so it can run
| on both the front-end and back-end.
| phplovesong wrote:
| I want a static binary. Not some IR i run on some VM.
| vvpan wrote:
| If it's functional (recursion vs imperative loops) most
| people/organizations will not use it. At this point that is
| just the reality.
| zaphar wrote:
| 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 wrote:
| its a simplification of immutability and its consequences
| vvpan wrote:
| 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.
| jlouis wrote:
| You can be functional "in spirit" more than purely
| functional. OCaml and Standard ML falls into this
| category. Ocaml has loops for instance. You might just
| not see many loops if code is written by OCaml
| developers, because there's frankly no need to use them
| in a lot of places. You often want to lift the
| abstraction level of iteration to an arbitrary data
| structure such that you get freedom of implementation.
| See Applicative and Monad.
| int_19h wrote:
| But, again, loops aren't automatically imperative per se.
| Consider loop / recur in Clojure for an example. For
| someone coming from JavaScript, it's not really much
| different from writing a while loop where every branch
| has to terminate with an explicit break or continue.
| tome wrote:
| So is Haskell not functional? Or an imperative language
| with some functional features? -- ghci>
| example -- Triangular number 1 is 0 --
| Triangular number 2 is 1 -- Triangular number 3
| is 3 -- Triangular number 4 is 6 --
| Triangular number 5 is 10 example = runEff $ \io
| -> evalState 0 $ \st -> do for_ [1..5] $ \i ->
| do n <- get st let msg =
| "Triangular number " <> show i <> " is " <> show n
| effIO io (putStrLn msg) st += i
| where st += n = modify st (+ n)
|
| (This is not a trick question. Simon Peyton Jones
| described Haskell as "the world's finest imperative
| language" [1], and I agree. This code is written using
| https://hackage.haskell.org/package/bluefin)
|
| [1] Tackling the Awkward Squad: monadic input/output,
| concurrency, exceptions, and foreign-language calls in
| Haskell
| bsder wrote:
| I really wish people would quit pushing "functional". People
| equate that with "My programming is now always a recursive
| logic puzzle."
|
| Talk about "immutable by default". Talk about "strong
| typing". Talk about "encapsulating side effects". Talk about
| "race free programming".
|
| Those are the things that programmers currently care about. A
| _lot_ of current Rust programmers are people who came there
| almost exclusively for "strong typing".
| cyberpunk wrote:
| immutability? Interactive Elixir (1.19.0) -
| press Ctrl+C to exit (type h() ENTER for help) iex(1)>
| x = 1 1 iex(2)> x = 2 2 iex(3)>
|
| What's immutable about elixir? It's one of the things which I
| _MISS_ from Erlang -- immutability.
| nitros wrote:
| This is like saying Haskell doesn't have immutability because
| it has the state monad, or that rust doesn't because you can
| shadow with let.
|
| Data is immutable and thats much more important than whether
| local variables can be modified imo.
| debugnik wrote:
| Shadowing is not mutability. The former isn't affected by
| control flow nor does it affect closures.
| int_19h wrote:
| What you wrote is roughly equivalent to this in C:
| { const int x = 1; { const int x =
| 2; } }
|
| which is to say, there are two different `x` in there, both
| immutable, one shadowing the other. You can observe this if
| you capture the one that is shadowed in a closure:
| iex(1)> x = 1 1 iex(2)> f = fn () -> x end
| #Function<43.113135111/0 in :erl_eval.expr/6> iex(3)> x
| = 2 2 iex(4)> f.() 1
| BenGosub wrote:
| Writing OCaml and writing Elixir code is much different for me.
| OCaml requires more braincells, while Elixir is more flexible.
| BenGosub wrote:
| I think that a better question is why F# isn't a more popular
| language, since it's much closer to OCaml, than Elixir and you
| can use the whole Dotnet ecosystem in F#, which is one of the
| weakest points of OCaml (no libraries).
| schonfinkel wrote:
| The answer is (most likely) Microsoft, I kid you not. I've
| worked with F# professionally for many years is its
| incredible how they are literally sitting atop a gold mine
| that is the output of Microsoft research and do basically
| nothing with it. Even though it's sold as an ecosystem, .NET
| revolves around C# and its related tooling.
|
| "Type Providers" are an example of such negligence btw, it's
| something from the early 2010's that never got popular even
| though some of its ideas (Typed SQL that can generate
| compile-time errors) are getting traction now in other
| ecosystems (like Rust's SQLx).
|
| My team used SQL Providers in a actual production system,
| combined with Fable (to leverage F# on the front end) and
| people always commented how our demos had literally 0 bugs,
| maybe it was too productive for our own good.
| belter wrote:
| BEAM performance model trades throughput for isolation, which
| hurts CPU-bound tasks, and ironically, whenever you need speed,
| you end up using NIFs that break BEAM safety guarantees, and
| reintroduce the exact fragility Elixir was supposed to avoid.
|
| In 2025, Elixir is a beautiful system for a niche that
| infrastructure has already abstracted away.
| jimbokun wrote:
| > In 2025, Elixir is a beautiful system for a niche that
| infrastructure has already abstracted away.
|
| Do you mean Kubernetes?
|
| My mental model of Erlang and Elixir is programming languages
| where the qualities of k8s are pushed into the language
| itself. On the one hand this restricts you to those two
| languages (or other ports to BEAM), on the other hand it
| allows you to get the kinds of fall over, scaling, and
| robustness of k8s at a much more responsive and granular
| level.
| creata wrote:
| > whenever you need speed, you end up using NIFs that break
| BEAM safety guarantees, and reintroduce the exact fragility
| Elixir was supposed to avoid.
|
| That's like complaining that unsafe{} breaks Rust's safety
| guarantees. It's true in some sense, but the breakage is in a
| smaller and more easily tested place.
| jlouis wrote:
| It's not isolation which hampers throughput. That's a red
| herring. In fact, isolation increases throughput, because it
| reduces synchronization. A group of isolated tasks are
| embarrassingly parallel by definition.
|
| The throughput loss stems from a design which require
| excessive communication. But such a design will always be
| slow, no matter your execution model. Modern CPUs simply
| don't cope well if cores need to send data between them.
| Neither does a GPU.
| creata wrote:
| But the isolation is what necessitates (or at least
| encourages) a design that requires more communication,
| isn't it?
| jlouis wrote:
| Not a priori.
|
| The grand design of BEAM is that you are copying data
| rather than passing it by reference. A copy operation
| severs a data dependency by design. Once the copy is
| handed somewhere, that part can operate in isolation. And
| modern computers are far better at copying data around
| than what people think. The exception are big-blocks-of-
| data(tm), but binaries are read-only in BEAM and thus not
| copied.
|
| Sure, if you set up a problem which requires a ton of
| communication, then this model suffers. But so does your
| GPU if you do the same thing.
|
| As Joe Armstrong said: our webserver is a thousand small
| webservers, each serving one request.
|
| Virtually none of them have to communicate with each
| other.
| timeon wrote:
| I do not think that monads/type system are issue, but yes BEAM
| runtime is killer feature.
| a-dub wrote:
| fun fact: the secret sauce that makes fftw fast is a code
| generator written in ocaml:
| https://github.com/FFTW/fftw3/tree/master/genfft
| yujzgzc wrote:
| 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 wrote:
| You would not really build the same software tho.
| abathologist wrote:
| > It's got about the same amount of type safety
|
| What?
| yujzgzc wrote:
| 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 wrote:
| 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-
| compatibil...
| yujzgzc wrote:
| 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 wrote:
| 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 wrote:
| There's 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), people seemed
| pretty excited about it.
| phplovesong wrote:
| 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 wrote:
| Little known fact: OCaml was at one point called "Zinc" ("Zinc is
| not Caml").
| Qem wrote:
| 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
| ilaksh wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| The popularity of a language usually translates into better
| support, tooling and learning materials.
| ArnavAgrawal03 wrote:
| Came here to say I love Ocaml too
| timhh wrote:
| > 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 wrote:
| +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 wrote:
| > 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.
| int_19h wrote:
| F# is not "OCaml for Windows". Not even close.
| mbac32768 wrote:
| The Windows support is bad because OCaml is a PL designed by
| people who are deep in Linux life. Windows is not something
| that keeps them up at night. (Which isn't to say they didn't
| try, just, you know, not as much as it takes)
|
| One of the things people often neglect to mention in their
| love letters to the language (except for Anil Madhavapeddy)
| is that it actually _feels_ UNIXy. It feels like home.
| obezyian wrote:
| > designed by people who are deep in Linux life.
|
| > it actually feels UNIXy. It feels like home.
|
| They use single dashes for long options.
|
| This is not home.
|
| https://linux.die.net/man/1/ocaml
| kragen wrote:
| Unix doesn't use double dashes for options; that's a GNU
| thing, and, as everyone knows, GNU's Not Unix.
|
| Normally the Unix/GNU opposition is irrelevant at this
| point, but you managed to pick one of the few significant
| points of difference.
| talideon wrote:
| If that's what you use as your yardstick of what's Unixy,
| then I guess you don't consider "find" to be Unixy, in
| spite of being one of the early Programmer's Workbench
| tools.
|
| Short options were a compromise to deal with the limits
| of the input hardware at the time. Double dashes were a
| workaround for the post-dash option car crash traditional
| Unix tooling allows because teletypes were so slow. There
| is nothing particularly Unixy about any of these options
| other than the leading hyphen convention.
|
| OCaml using single hyphens is not un-Unixy.
| kragen wrote:
| Caml was developed in 01985, Linux was first released in
| 01991, and Caml was extended into OCaml in 01996. I don't
| think the developers were using Linux at the time; SunOS 4
| would be my best guess. I didn't work on it, but I was in
| the sort of internetty environment that OCaml came from,
| and I was using Solaris at work and got my first Linux box
| at home. As another commenter mentioned, the command line
| follows Unix conventions rather than the Linux conventions
| from GNU.
| fithisux wrote:
| Opam on Windows is a masterpiece of engineering
| delta_p_delta_x wrote:
| I would suggest that people interested in using OCaml on
| Windows (or indeed, OCaml at all) try F# instead. It is still
| an ML-family language. Incidentally, by targeting the CLR, F#
| is considerably more deployable (both to users and to
| developers) than OCaml is. Plus, any old NuGet library written
| in C# or VB.NET can be used almost trivially in F#. This also
| solves the problem OP listed about a tiny ecosystem, because
| the C#/.NET ecosystem is _massive_.
|
| I couldn't agree more with the parent commenter about OCaml
| documentation. Functional programmers appear to love terseness
| to an almost extreme degree. Things like `first` are
| abbreviated to `fst`, which is just odd. Especially now that
| good IntelliSense means there is no real functional (heh)
| difference between typing `.fi` and pressing Tab, and typing
| `.fs` and pressing Tab.
|
| The F# documentation is comparatively very spiffy and detailed,
| with plenty of examples[1][2][3].
|
| [1]: https://learn.microsoft.com/en-gb/dotnet/fsharp/language-
| ref...
|
| [2]: https://fsharp.github.io/fsharp-core-docs/
|
| [3]: https://fsprojects.github.io/fsharp-cheatsheet/fsharp-
| cheats...
| mbac32768 wrote:
| I find F# nowhere near as good as OCaml and think this
| comparison is ugly, but if I was forced to use a .NET
| platform I would almost certainly use F#
| delta_p_delta_x wrote:
| > nowhere near as good as OCaml
|
| I'd really like to hear more about this. From what I've
| used of F# and OCaml, both languages are around 95% the
| same.
| mbac32768 wrote:
| I'll give you my top 3.
|
| F# is worse because the type inferencing isn't as good.
| You need to type annotate in more places. It's a drag,
| because it feels like a missed opportunity to let the
| machine do work for you.
|
| Additionally, one of the most pleasant and unique
| features of OCaml, strong named arguments, doesn't exist
| in F# (except in methods or whatever). Most programming
| languages don't have this (or it's hamfisted like in more
| dynamic languages) so it doesn't seem like a loss, unless
| you are very cozy with them in OCaml.
|
| (I'm bitter about this one because named arguments give
| safety and convenience. But when you combine them with
| currying it's like 4 or 5 design patterns that are
| elegantly provided for you. You just do it implicitly,
| without ever having to study a book about using them.)
|
| Finally, F# brings back the NULL problem that OCaml
| worked so hard to eradicate.
| tempodox wrote:
| And you cannot have default arguments for function
| parameters in F#. They are only allowed with methods.
| codesnik wrote:
| interesting. how named arguments work with currying?
| octachron wrote:
| Nearly the same as with positional argument: Partially
| applying a function to a named argument creates a closure
| with this argument filled in, and you can apply the
| argument in whichever order you want:
| let f a ~x ~y b = a + x + y + b let g = f ~y:1 (*
| g is closure with the argument named ~y filled in *)
| let h = g 2 (* another closure with the first positional
| argument filled in *) let int_15 = h 8 ~x:4 (* =
| g 2 8 ~y:4 = f ~y:1 2 8 ~x:4 *)
|
| The more complex interaction is rather with type
| inference and currying, or the interaction between
| currying and optional arguments.
| nukifw wrote:
| If you are interested, I think I adress this here
| https://xvw.lol/en/articles/why-ocaml.html#ocaml-and-f
| delta_p_delta_x wrote:
| Thanks, this is a very nice article.
| int_19h wrote:
| F# is indeed an ML-family language, but at this point it
| doesn't have all that much in common with OCaml specifically:
| it doesn't have the latter's structurally typed object model
| with inferred row-polymorphic types, nor its extremely
| powerful module system, not even many convenience features
| like open variants.
| bmitc wrote:
| F# has plenty of features that OCaml doesn't have like
| proper cross-platform support, proper deployment, active
| patterns, units of measure, computation expressions, type
| providers, interfaces on unions and records, etc. F# is
| probably faster as well and definitely has a larger
| ecosystem through .NET.
| Syzygies wrote:
| To decide on a language for a math research project, I
| implemented a toy problem in many languages: What is the
| distribution of cycle counts for signed permutations on n
| letters? Use all cores in parallel. C++ 100
| 19.57s Rust 96 20.40s
| F# 95 20.52s Nim 75 26.04s
| Julia 64 30.40s Ocaml 48 41.07s
| Haskell 41 47.64s Chez 39 49.53s
| Swift 33 58.46s Lean 7 278.88s
| Tarjan, n = 10 Nyx - Apple M4 Max - 12 performance and
| 4 efficiency cores n! * 2^n = 3,715,891,200 signed
| permutations score = gops normalized so best language
| averages 100 time = running time in seconds
|
| This had me briefly smitten with F#, till I realized the
| extent that rusty .NET bed springs were poking through. Same
| as the JVM and Clojure, or Erlang and Elixir. The F# JIT
| compiler is nevertheless pretty amazing.
|
| I nearly settled on OCaml. After AI warning me that proper
| work-stealing parallelism is a massive, sophisticated project
| to code properly, the 40 lines of OCaml code I wrote that
| beat available libraries is my favorite code file in years.
|
| Nevertheless, once one understands lazy evaluation in
| Haskell, it's hard to use any other language. The log
| slowdown for conventional use of a functional data structure
| becomes a linear speedup once one exploits persistence.
| fud101 wrote:
| Interesting, would be a good blog post to read.
| delta_p_delta_x wrote:
| I would really like to read more about this!
| fithisux wrote:
| No Fortran?
| jibal wrote:
| What about D? Can you post any of the 10 source codes?
| davidwritesbugs wrote:
| F# would be awesome but for the dogs*t .Net backend that
| made the tiniest error insoluble
| 7thaccount wrote:
| F# pretty much assumes you already know C#. I found that it
| made it hard to get up to speed on it. I really do enjoy the
| the syntax though.
| mbac32768 wrote:
| A lot of these are learning curve issues, but once you scale
| them you still permanently suffer with a very deficient,
| fragmented ecosystem. Until you have built up your own curated
| set of dependencies for your business stack, anyway.
|
| > * 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.
|
| I suggest configuring ocamlformat to use the janestreet profile
| for better defaults.
|
| > * Optional type annotation for function signatures throws
| away a significant benefit of static typing -
| documentation/understanding and nice error messages.
|
| People should be providing .mli files, but don't. That said, an
| IDE with type hints helps this enormously. The VS Code plugin
| for OCaml is the best experience for noobs, hands down.
|
| > OPAM
|
| yes
| boppo1 wrote:
| With all the issues, how does janestreet love it so?
| LAC-Tech wrote:
| I wish I could make a list like this about rust in this place
| and not be flagged.
| timhh wrote:
| I don't think you would be flagged. Rust definitely has
| flaws:
|
| * Compile time is only ok. On par with C++.
|
| * Async has a surprisingly number of footguns and ergonomic
| issues.
|
| * There's no good solution to self-borrowing or partial
| borrows.
|
| * While using macros is fine, _writing_ them is pretty awful.
| Fortunately you rarely need to do that. Relatedly it is
| missing introspection support.
|
| * Sometimes the types and lifetimes get very complex.
|
| But overall I still much prefer it to OCaml. The syntax is
| much nicer, it's easier to read, the ecosystem and tooling
| are much better, the documentation is much better, and it
| actively hates linked lists!
| cmrdporcupine wrote:
| You missed one:
|
| * Crates.io is an unmoderated wasteland of infinite
| transitive dependency chaos
|
| But my "favourite":
|
| * It's 2025 and allocator-api (or its competitors) is still
| in nightly only and no sign of stabilizing
|
| I work almost exclusively in Rust, and I like the language
| but in many respects a) Rust is the language that tokio
| ate, and b) it has been deluged with people coming from the
| NodeJS/NPM ecosystem doing Web Scale Development(tm) and
| its terrible practices around dependency management.
| timhh wrote:
| > Crates.io is an unmoderated wasteland of infinite
| transitive dependency chaos
|
| Well, I'm not sure I agree with that. If by "unmoderated"
| you mean anyone can upload a crate without going through
| bureaucratic approvals processes then that seems like a
| good thing to me!
|
| But you did remind me of one other majorly annoying thing
| about the crate system: the global namespace. It doesn't
| have the same security issues as Python's global package
| namespace, but it is really really annoying because you
| pretty much have to break large projects down into
| multiple crates for compile time reasons, and then good
| luck publishing those on crates.io. Plus you end up with
| a load of crate names like `myproject-foo`, `myproject-
| bar`, which is very verbose.
|
| Oh and yeah, the Tokio situation is a bit sad.
|
| Also the proliferation of some _types_ of crates like
| error handling. This should _really_ be in the standard
| library by now (or at least fairly soon). Any large
| project ends up with like 5 different error handling
| libraries just because dependencies made different
| choices about which to use. It 's not a _major_ issue but
| it is silly.
|
| Overall though, still my favourite language by far.
| vacuity wrote:
| I think the error type stuff should be less prominent,
| and really shouldn't be front-and-center in the standard
| library, or any library. Error handling is undoubtedly
| important, but its expression in the API is a different
| matter. I don't have fully formed opinions, but I do feel
| that the common recommendations are bad.
| vacuity wrote:
| On the topic of allocators, I noticed some PRs to add
| allocator support to more types recently...great, now we
| just need to stabil--oh, wait. Although I care more about
| not stabilizing a bad API than eternal unstability, if it
| comes down to that.
| DeathArrow wrote:
| The problem for me is that instead of focusing on the
| problem at hand and the business logic, I have to focus on
| the Rust memory model and the borrow checker. And seems
| very verbose.
|
| Thing is, if I sketch something in pseudocode, I should be
| able to translate it to any mainstream programming
| languages. With Rust I can't just do that, I have to bend
| the problem to fit the way the language works.
| kristianp wrote:
| > * Like all FP languages it has a weird obsession with singly
| linked lists, which are actually a pretty awful data structure
|
| This made me chuckle. I've had that thought before, shouldn't
| the default be a vector on modern devices? Of course other
| collection types are available.
| olivia-banks wrote:
| I'd say that functional programming is probably one of the
| only domains where linked lists actually make sense. Vectors
| certainty have their use in more places though.
| spooky_deep wrote:
| A good compiler will make the lists disappear in many
| cases. No runtime overhead. I actually love single linked
| lists as a way to break down sequences of problem steps.
| int_19h wrote:
| Why would a specific way of structuring data in memory be
| relevant to breaking down sequences of problem steps?
|
| If what you mean is the ability to think in terms of
| "first" and "rest", that's just an interface that doesn't
| have to be backed by a linked list implementation.
| olivia-banks wrote:
| I'm curious what you mean. Surely there's the overhead of
| unpredictable memory access?
| deredede wrote:
| Not GP but bump allocation (OCaml's GC uses a bump
| allocator into the young heap) mitigates this somewhat,
| list nodes tend to be allocated near each other. It is
| worse than the guaranteed contiguous access patterns of a
| vector, but it's not completely scattered either.
| kragen wrote:
| In Haskell, yes, because laziness permits deforestation.
| ML, including OCaml, is eager and consequently cannot do
| this.
| MrJohz wrote:
| I believe it's possible in theory - Koka has a whole
| "functional but in-place" set of compiler optimisations
| that essentially translate functional algorithms into
| imperative ones. But I think that's also possible in Koka
| in part because of its ownership rules that track where
| objects are created and freed, so might also not be
| feasible for OCaml.
| kragen wrote:
| I mean, the set of valid deforestation transformations
| you could do to an OCaml program is not _literally_ the
| empty set, but OCaml functions can do I /O, update refs,
| and throw exceptions, as well as failing to terminate, so
| you would have to be sure that none of the code you were
| running in the wrong order did any of those things. I
| don't think the garbage collection issues you mention are
| a problem, though maybe I don't understand them?
| MrJohz wrote:
| Part of what Koka's functional-but-in-place system relies
| on is the Perceus program analysis, which, as I
| understand it, is kind of like a limited Rust-like
| lifetime analysis which can determine statically the
| lifetime of different objects and whether they can be
| reused or discarded or whatever. That way, if you're,
| say, mapping over a linked list, rather than construct a
| whole new list for the new entries, the Koka compiler
| simply mutates the old list with the new values. You
| write a pure, functional algorithm, and Koka converts it
| to the imperative equivalent.
|
| That said, I think this is somewhat unrelated to the idea
| of making linked lists disappear - Koka is still using
| linked lists, but optimising their allocation and
| deallocation, whereas Haskell can convert a linked list
| to an array and do a different set of optimisations
| there.
|
| See: https://koka-lang.github.io/koka/doc/book.html#sec-
| fbip
| otabdeveloper4 wrote:
| Ah yes, our old friend - the sufficiently smart compiler.
| int_19h wrote:
| The reason why functional languages like linked lists so much
| is because they are very easy to make immutable without a lot
| of pain all around. If you implement an immutable vector in a
| straightforward way, though, you basically need to do a lot
| of copying for any operation that needs to construct one (the
| rigmarole with immutable strings, and existence of hacks such
| as StringBuilder, is a good illustration of the problem).
|
| But you _can_ have a data structure that is more like vector
| under the hood while still supporting efficient copy-with-
| modifications. Clojure vectors, for example.
| gigatexal wrote:
| That makes sense. But LinkedIn lists are horrible for cache
| efficient things no? I think there was an article on HN
| from a Golang perspective padding structs or something such
| that they are efficient wrt to cache hits.
| rkomorn wrote:
| > But LinkedIn lists are horrible for cache efficient
| things no?
|
| LinkedIn Lists you say? (Sorry. (But not that sorry.))
|
| Edit meta sidenote: in this modern meme world, it's
| virtually impossible to know if a typo is a typo or just
| a meme you haven't heard of yet.
| gigatexal wrote:
| lol my phone autocorrected ugh.
|
| But you know what I mean. Some grace would be nice.
| rkomorn wrote:
| I know. It was just too hard to pass up. :)
| gigatexal wrote:
| Well you got me. I audibly groaned and slapped my
| forehead.
| stirfish wrote:
| LinkedIn lists will tell you they contain one new
| element, but you have to click on a link and scroll
| through their suggested new elements to see what it is
| rkomorn wrote:
| Do they also always end with an element that tells you
| what the LinkedIn list taught it about B2B sales?
| mrkeen wrote:
| They are, but you don't tend to keep them around in
| memory long enough. Start consuming the front before you
| produce the back.
| dontlaugh wrote:
| Which is a pity, you can fit entire small arrays in a cache
| line to end up with no pointer chasing at all.
| le-mark wrote:
| > The syntax is hard to parse for humans
|
| This was my problem as well, the object oriented related syntax
| is just too much. ML of which caml is a version of, has really
| tight syntax. The "o" in ocaml ruins it imo.
| StopDisinfo910 wrote:
| No offense but the only time I have encountered objects in
| Ocaml was while using LablGTK a long time ago and the object
| syntax was pretty clean and not far from the module one. They
| are also structurally typed which is very handy.
|
| Considering it only impacts a fairly small subset of the
| language, could you explain how it supposedly ruins
| everything?
| Kwpolska wrote:
| > * 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.
|
| I couldn't believe this was an actual bug in opam, and I found
| it: https://github.com/ocaml/opam/issues/5373
|
| I don't think that's an opam bug, it's an issue with musl, and
| they just happened to build their binaries with it.
| chris_armstrong wrote:
| It's interesting reading many of the associated comments,
| because there is a genuinely active effort to address many of
| the pain points of the language:
|
| * Windows support has improved to the point where you can just
| download opam, and it will configure and set up a working
| compiler and language tools for you[^1]. The compiler team
| treat Windows as an first tier target. opam repository
| maintainers ensure new libraries and library versions added to
| the opam repository are compiled and tested for Windows
| compatibility, and authors are encouraged to fix it before
| making a release if its reasonably straightforward
|
| * debugger support with gdb (and lldb) is slowly being improved
| thanks to efforts at Tarides
|
| * opam is relatively stable (I've never found it "buggy and
| surprising"), but there are aspects (like switches that behave
| more like python venvs) which don't provide the most modern
| behaviour. dune package management (which is still in the
| works) will simplify this considerably, but opam continues to
| see active development and improvement from release to release.
|
| * the platform team (again) are working on improving
| documentation with worked recipes and examples for popular uses
| cases (outside of the usual compiler and code generation cases)
| with the OCaml Cookbook: https://ocaml.org/cookbook
|
| There are other things I find frustrating or that I work
| around, or are more misperceptions:
|
| * there isn't a builtin way to copy files because the standard
| library is deliberately very small (like Rust), but there is a
| significant ecosystem of packages (this is different to other
| languages which cram a lot into their standard library). The
| result is a lot of friction for newcomers who have to install
| something to get what they need done, but that's valued by more
| experienced developers who don't want the whole kitchen sink in
| their binary and all its supply chain issues.[^2]
|
| * the type inference can be a bit of a love/hate thing. Many
| people find it frustrating because of the way it works, and
| start annotating everything to short-circuit it. I've
| personally found it requires a bit of work to understand what
| it is doing, and when to rely on it, and when not to
| (essentially not trying to make it do things it simply will
| never be able to do).[^3]
|
| * most people use singly-linked lists because they work
| reasonably well for their use cases and don't get in their way.
| There are other data structures, they work well and have better
| performance (for where it is needed). The language is pragmatic
| enough to offer mutable and immutable versions.
|
| * ocamlformat is designed to work without defaults (but some of
| them I find annoying and reconfigure)
|
| Please don't take this as an apology for its shortcomings - any
| language used in the wild has its frustrations, and more
| "niche" languages like OCaml have more than a few. But for me
| it's amazing how much the language has been modernised
| (effects-based runtime, multicore, etc) without breaking
| compatibility or adding reams of complexity to the language.
| Many of these things have taken a long time, but the result is
| usually much cleaner and better thought out than if they were
| rushed.
|
| [^1] This in itself is not enough, and still "too slow". It
| will improve with efforts like relocatable OCaml (enabling
| binary distribution instead of compiling from source
| everywhere) and disentangling the build system from Unixisms
| that require Cygwin.
|
| [^2] I particularly appreciate that the opam repository is
| actively tested (all new package releases are tested in a CI
| for dependency compatibility and working tests), curated (if
| its too small to be library, it will probably be rejected) and
| pruned (unmaintained packages are now being archived)
|
| [^3] OCaml sets expectations around its type inference ("no
| annotations!") very high, but the reality is that it relies on
| a very tightly designed and internally coherent set of language
| constructs in order to achieve a high level of type inference /
| low level of annotation, but these are very different to how
| type inference works in other languages. For example, I try and
| avoid using the same field name in a module because of the
| "flat namespace" of field names used to infer record types, but
| this isn't always possible (e.g. generated code), so I find
| myself compensating by moving things into separate modules
| (which are relatively cheap and don't pollute the scope as
| much).
| tempodox wrote:
| > 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.
| codesnik wrote:
| I kinda feel that singly linked lists isn't a data structure in
| FP as much as a (dynamic) control flow structure. It's okay in
| that application.
| thw_9a83c wrote:
| > The documentation is super terse. Very few examples.
|
| I agree. OCaml is a complex language with very beginner-
| unfriendly documentation. In fact, I would even say it's
| unfriendly to engineers (as developers). The OCaml community
| prefers to see this language as an academic affair and doesn't
| see the need to attract the masses. E.g. Rust is an example of
| the opposite. It's a complex language, but it's pushing hard to
| become mainstream.
| yodsanklai wrote:
| I just don't get these comments about syntax...
|
| Just taking the first example I can find of some auto-formatted
| OCaml code
|
| https://github.com/janestreet/core/blob/master/command/src/c...
|
| It doesn't look more a soup of words than any other language.
| Not sure what's hard to parse for humans.
| agentultra wrote:
| 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
| m3at wrote:
| > 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 wrote:
| 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).
|
| 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.
| agentultra wrote:
| Yeah, I can see that. At the time of the talk Feldman claims
| Python is a slow-and-steady language. It definitely did get a
| lot of support from the scientific/engineering community for
| a long time. I spent a good part of my career with Python
| from about 2006-2016.
|
| It had boosts from Django... but it never had Rails' level of
| popularity. You kinda have to be first-to-market _and_ that
| good to get the "killer app" effect.
|
| It's also been integrated as the scripting language for
| several popular software pacakges (Blender comes to mind).
|
| Machine learning and now... "AI"; seems to be a market
| cornered by Python quite a bit.
| aeonik wrote:
| A MAJOR portion of popularity was because of this xkcd comic.
|
| https://xkcd.com/353/
|
| It hit the front page of Slashdot, Digg, Reddit, made the
| rounds on Hacker news, etc...
| (https://news.ycombinator.com/item?id=86246)
|
| Django was also very popular at the time.
|
| I had already learned Basic, C++, Java, and C#. I wanted to
| add a dynamic scripting language that was cross-platform
| under my belt.
|
| A lot of my peers were in the same boat.
|
| Python seemed at the time, to be the only general purpose
| scripting language that was easy to use on multiple
| platforms.
|
| I had heard bad things about Perl being write only, and Ruby
| being tough to deploy, I also found it hard to read. (Which
| is a shame they are wonderful languages, though Ruby is dog
| slow, Python is slow too, but Ruby is worse somehow).
|
| IIRC Google and some other large companies were pushing it as
| one of their official languages.
|
| Right as Python was rocketing in popularity, Go came out, and
| I also heard a lot of good things about Clojure (they seemed
| neck and neck in popularity from my incorrect perspective at
| the time, lol).
| graemep wrote:
| I think Python became popular before Go came out.
|
| Do you mean the comic was responsible, or the comic
| explains why Python is popular? It is definitely the
| ecosystem. As you said its general purpose. It is used for
| numerical computing and visualisation, web apps, GUIs,
| sysadmin. Even a reasonably popular DVCS is written in
| Python.
| aeonik wrote:
| I wrote: "Right as Python was rocketing in popularity, Go
| came out."
|
| I wasn't talking chronology of first release, just
| describing the overlap in hype cycles back then.
|
| The comic was released in 2007, and started heading to
| the moon. Go came out around 2009, and almost instantly
| got traction.
| graemep wrote:
| I do not mean to disagree with just, just wanted to
| clarify some wording and add to the "general purpose
| aspect of Python.
| spooky_deep wrote:
| Google blessed Python at a time when Java didn't even have
| lambdas.
| bsder wrote:
| > I think Richard Feldman [0] proposed some of the most
| reasonable theories as to why functional programming isn't the
| norm.
|
| Functional programming isn't the norm because its primary
| adherents suffer from cranio-rectal impaction. The FP people
| have missed _soooo_ many technological inflection points
| because everything was beneath them.
|
| Microprocessors were toys--so C and Pascal became the norm
| instead of FP. Embedding and sysadmin were icky--so Tcl and
| Perl got used instead of FP. Windows or GUI support--pshaw! I
| can go on and on and on ...
|
| It makes me _weep_ thinking about all the time teenage me
| wasted writing assembly language and C that greybeard me could
| have explained how to side step with even the simplest FP.
|
| In the end, the imperative programming priests came down to
| proselytize among the hoi polloi while the FP priests stayed
| holed up in the Cathedral. And that made all the difference.
| anthk wrote:
| TCL it's almost Lisp with strings instead of atom lists. I
| prefer it a little over Perl.
| graemep wrote:
| No macros, limited support for higher order functions. Its
| big drawback is the small ecosystem.
|
| I like TCL, but its not really comparable to lisp. Its
| definitely a great scripting language and is a lot more
| flexible than it gets credit for.
|
| It got a lot of things right. Event driven concurrency (and
| its got a good threading model) which is often given as a
| reason to use JS to right servers. Sandboxing untrusted
| code. Easy GUIs with Tk. Easy cross platform deployment.
| Unfortunately it never got traction.
| atombender wrote:
| I look at how people write TypeScript these days, and think
| about how the world might have been different if, 10-15 years
| ago, these functional languages had been a bit closer to the
| imperative world. OCaml allows mutation and side effects and
| could even feel a bit imperative if it weren't for the "let ...
| in" syntax.
|
| Let's face it, syntax matters. We saw that with Elixir becoming
| much more popular than Erlang ever did. We saw it with
| TypeScript being able to introduce a fairly complex type system
| into JavaScript, and becoming successful among web devs by
| adapting to established ecosystem and offering a gradual
| approach, rather than forcing an entirely new, incompatible
| paradigm on it. The TypeScript story seems a little improbable
| in hindsight, but it was able to get there by offering an
| incremental path and making a lot of compromises (such as
| config options to allow less strict enforcement) along the way.
|
| Personally, I think a new syntax for OCaml might actually be
| successful if done right. Sure, there have been multiple
| attempts (the "revised" syntax, Reason, etc.), but none of them
| are really willing to modernize in ways that would attract your
| average programmer. The toolchain also needs work to appeal to
| non-OCaml programmers.
| debugnik wrote:
| [delayed]
| rootnod3 wrote:
| 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.
| mikaeluman wrote:
| 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/ 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 wrote:
| 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.
| mikaeluman wrote:
| Interesting take. I agree with you mostly but regarding
| "community" I am more thinking of the side effects there in
| terms of _other_ people developing interesting libraries etc.
|
| I don't know if AI can change that but when using python,
| there is a feeling that there is an awesome quality library
| for just about anything.
| tasuki wrote:
| > 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 wrote:
| Elm is pure-functional, unlike OCaml, which has easy escape
| hatches (refs) when you need mutability.
| tasuki wrote:
| I feel as a frontend language Elm has somewhat less need for
| mutability. At least I haven't missed it.
| pshirshov wrote:
| > 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 wrote:
| Hashtbl.add table key value
|
| What's your point with that?
| seabrookmx wrote:
| Lots of complaints about the OCaml syntax here.. is ReasonML
| dead?
| davesnx wrote:
| is very alive, released with OCaml 5.4 support and improving
| bit by bit
| olivia-banks wrote:
| > 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 wrote:
| You would be surprised how many Googlers think the Go team is
| making bad decision after bad decision.
| olivia-banks wrote:
| How so? I'm not that familiar with Go anymore.
| hyperhopper wrote:
| Search any Go codebase for err != nil, for starters.
| olivia-banks wrote:
| 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.
| galvatron9k wrote:
| > is a problem nearly as old as Go itself
|
| It's as old as C. C and Go are the only two significant
| languages which end up constantly checking for errors
| like this.
| keyle wrote:
| Not just Googlers. There is a certain pragmatism and then
| there is being stubborn.
| boppo1 wrote:
| I am exactly the type of novice programmer described in the
| quotes.
|
| >have shifted their way of thinking rather extremely
|
| What could I read to shift my way of thinking?
|
| The signals & threads episode about OCaml strongly piqued my
| interest, and not because I have any JS delusions (they would
| never, lol).
| olivia-banks wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| "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
___________________________________________________________________
(page generated 2025-11-08 23:01 UTC)