[HN Gopher] OCaml's Wings for Machine Learning
___________________________________________________________________
OCaml's Wings for Machine Learning
Author : musha68k
Score : 98 points
Date : 2025-04-30 12:31 UTC (10 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| evacchi wrote:
| so finally someone is actually putting ML in ML
| cube2222 wrote:
| Fingers crossed, though I'm not holding my breath for anything
| taking a sizable bite out of Python in the area of ML/DL.
|
| OCaml seems to be a lovely language based on my limited
| experience with it. It's a pity it's not more popular.
| lawnchair wrote:
| Terrateam is hiring ;)
| behnamoh wrote:
| OCaml surprises me--it's old enough to be mature in terms of
| features and libs, and it's got a small but enthusiastic
| community, but every time I tried to convince myself to OCaml I
| found myself more drawn to Haskell and Elixir.
| giraffe_lady wrote:
| I like ocaml for the things other people like go for. It's a
| grimy roughneck language. Not a lot of fun to play around with
| or explore ideas but in my experience codebases written in it
| are stable and age well, easy to maintain.
|
| Elixir vs ocaml I use both languages but for such completely
| different things I don't even think about a comparison. Elixir
| is for when the problem I have suits beam's strengths.
| noelwelsh wrote:
| Its unfortunate the cleaned up syntax never took off, and
| that OCaml dropped the ball on multicore for over a decade.
| If OCaml had decent multicore around 2010 or so the current
| programming language langscape could look very different.
| behnamoh wrote:
| > Its unfortunate the cleaned up syntax never took off, and
| that OCaml dropped the ball on multicore for over a decade.
|
| It just shows the mindset of its devs was a little behind
| the realities of the industry, or they simply didn't care
| about concurrency.
|
| In comparison, I like how Python always tries to be on top
| of things by exploring new PEPs.
| toolslive wrote:
| I'm going to be sarcastic _and_ on topic (you baited me):
| yeah, like how python completely solved concurrency &
| parallelism.
| sidkshatriya wrote:
| > It just shows the mindset of its devs was a little
| behind the realities of the industry, or they simply
| didn't care about concurrency.
|
| OCaml cared about concurrency (e.g. Lwt, Async are old
| libraries that provide concurrency -- they didn't need
| multicore Ocaml). OCaml didn't care so much about true
| _parallelism_ in threads until recently. Parallelism was
| to be obtained via processes and not threads in pre OCaml
| 5.0. True parallelism in threads is available in OCaml >=
| 5.0
|
| Python is actually trying to go multicore too ! OCaml
| however beat it to the punch. The strengths of Python are
| elsewhere though, a topic for another day.
| jimbokun wrote:
| > Python is actually trying to go multicore too ! OCaml
| however beat it to the punch.
|
| This is debating the relative finishing places of the two
| runners finishing last in the marathon after most of the
| other runners have already gone home and had their
| dinner.
| neonsunset wrote:
| If you care about efficient parallelism, F# might give
| you much better experience and results.
| jimbokun wrote:
| As well as many, many other programming languages!
| ackfoobar wrote:
| To be pedantic, concurrency in OCaml has been fine with
| lwt. Single threaded concurrency, not unlike how JS does
| it.
| abathologist wrote:
| OCaml has had great concurrency support for years and
| years. Multicore is only a question of shared memory
| parallelism.
| giraffe_lady wrote:
| Yeah though iirc they did have to rewrite the runtime to
| get multicore so who knows what sort of tradeoffs they'd
| have had to make to have had it be like that from the
| beginning. A lot of what made it good (to the extent it
| was) in the 2000s was you got a very sophisticated type &
| module system and a fast compiler without giving up any
| runtime performance compared to its peers. I don't know if
| that would have been achievable with its dev resources
| alongside multicore early. I don't know that it wouldn't
| either though. Just a big what if all round.
|
| I suspect a larger or at least comparable limitation was
| essentially pretending windows didn't exist for uh like
| thirty years. If you knew what you were doing you could
| cross compile for it but it was not easy. Getting a dev
| environment running on windows was basically impossible
| until like five years ago.
|
| The syntax idk I don't have strong feelings about it. I
| initially recoiled like everyone else of course, but to me
| style and naming conventions are almost as important and on
| that front ocaml's are also among the worst in the world
| lol. Once you get used to it it's kind of endearing how
| fucked up it is.
| toolslive wrote:
| > ... with its dev resources ... Opening a pull request
| to the compiler or std lib was also treated with some
| French love. (I never bothered to open one again after
| that)
| suspended_state wrote:
| Who are you quoting here?
| toolslive wrote:
| the quote is the part between the dots; my comment is
| about why the number of developer resources might
| limited.
| StopDisinfo910 wrote:
| > style and naming conventions are almost as important
| and on that front ocaml's are also among the worst in the
| world
|
| I'm a bit lost because Ocaml has a Pascal-like syntax (I
| find it nice but I generally dislike B syntax and am
| amongst the rare bread of developer who didn't start with
| a language using it) and an extremely nice naming
| convention. Ocaml strongly discourages overloading, weird
| operators and shortly named variables unless they are
| local and used for a short time or an idiom like the
| default type of a module being named _t_. Everything has
| a long name in a module with a long name. It's extremely
| nice.
| Jtsummers wrote:
| > I'm a bit lost because Ocaml has a Pascal-like syntax
|
| OCaml's syntax is not particularly Pascal-like. It'd be
| very hard for someone to mistake Pascal code for OCaml or
| vice versa.
| StopDisinfo910 wrote:
| Ocaml has the same ALGOL roots as Pascal (which is what I
| meant by Pascal like) and you can see the influence in
| the syntax: words pairing for blocks (begin/end,
| do/done), same use of ":". Keywords are quite close.
|
| It obviously went through ML but you can tell the
| influence.
| StopDisinfo910 wrote:
| Python had no multicore during the same period and that
| never prevented it from becoming successful. Plus, Ocaml
| always had descent solution for concurrent I/O. The absence
| of multicore is a complete red herring in why Ocaml isn't
| more successful.
|
| Ocaml issue never was the syntax which is completely fine.
| The current syntax is actually a lot nicer that what
| Facebook proposed. Ocaml issue is not being a USA-born
| project nor having a significant marketing push in English.
|
| Plus, Ocaml always was too far ahead of its time (including
| now with its effect system). First, you have the functional
| approach which was already very unfamiliar for most. Then,
| you have to add module level programming on top which is
| still very unfamiliar to most. Just look at this comment
| page and people thinking Ocaml is not fun to use or less
| interesting than Haskell, it's trully sad.
|
| Multicore has added the extremely promising effect system
| but that's once again a step too far for most current
| developers.
|
| In a lof of way, Ocaml is to programming language what the
| Pixies are to rock music. Everyone who felt deeply in love
| with it went on to write a language of their own. Some got
| really successful.
| behnamoh wrote:
| > Ocaml issue is not being a USA-born project nor having
| a significant marketing push in English.
|
| Python is a counter argument here.
| StopDisinfo910 wrote:
| It's not. Van Rossum is Dutch but Python always had a
| strong marketing push in English.
|
| The first version was announced in English on Usenet. Van
| Rossum moved to the USA quite quickly to work on Python
| from CNRI in 1995. Then, it got funding from DARPA in
| 1999 with this as part of its pitch: "Create a code that
| is easy to understand and looks as easy as the _English_
| language. "
|
| Ocaml meanwhile is an INRIA child made by a French team
| to develop another INRIA child made by another French
| team. I think in Europe, that's approximately as US
| hostile as you can be.
|
| Actually, Ocaml has only become somewhat popular since
| it's pushed a bit from the UK which I find amusing.
| kangda123 wrote:
| As far as my experience, there's little code in Python
| that I would like to replace with OCaml. Python stuff is
| research code and small services that were written
| hastily.
|
| I would love to replace my Go code with OCaml. It was
| always kind of on the verge though. On one hand, once you
| use a proper type system, you cannot look at Go. On the
| other, Go's multicore is just so much better than
| Async/Lwt. In terms of programming, in terms of
| debuggability, surely in terms of performance too. Having
| proper multithreading in 5.0 suddenly makes OCaml
| strictly superior in my (rather biased) opinion.
| deredede wrote:
| The lack of ad-hoc polymorphism has to be there somewhere
| as well.
| giraffe_lady wrote:
| I don't think so really. It might help lure people over
| from haskell or rust or whatever but ocaml has its own
| solutions to the problems solved by ad hoc polymorphism.
| Usually in the module system, sometimes a ppx.
|
| There's nothing comparable to ocaml's module system that
| I know of in any other mature language so no one really
| arrives in ocaml with well developed intuition for what
| sorts of things are possible and worth doing with it. But
| once you've put the time in it's usually the correct
| answer to "how to do I do <haskell type system thing> in
| ocaml."
|
| I'm not a type systems expert though and it's likely
| there are some novel & unique situations where it's the
| best or only solution. Just maybe not as much as people
| assume from outside. Anyway I think there is a proposal
| for it so it'll probably work its way in eventually.
| hajile wrote:
| Isn't Ocaml's module system based on StandardML? SML
| predates Ocaml by a few years and non-standardized ML by
| a couple decades.
| giraffe_lady wrote:
| Oh actually I'm not sure. I was thinking it was one of
| the things ocaml added but now I think you're right.
| aseipp wrote:
| Haskell's "mixin modules" AKA backpack are I think the
| closest thing you're going to get outside of SML (they
| are a different trade off in the design space, it's not
| 1-to-1), but they have languished in the broader
| community due to a couple social factors. They are
| excellent for many of the same things you use modules
| for, though, and work just fine in my experience.
|
| On the same note, the lack of some kind of module system
| along these lines (broadly all defined in terms of
| "holes" in a compilation unit which are "plugged up"
| later on at instantiation time), is one of my biggest
| complaints about Rust. The extensive usage of traits in
| the broader ecosystem results in this phenomenon
| (identical to Haskell) where global coherence requires
| your dependency tree gets tied up in the location of
| types and their trait impls. In other words, you cannot
| abstract over your dependencies in a truly modular way.
|
| Global coherence requirements are fine (preferable even!)
| for many things but if it's the only hammer you have,
| well, you know the rest of the metaphor.
|
| > Anyway I think there is a proposal for it so it'll
| probably work its way in eventually.
|
| Modular implicits have been shelved indefinitely from
| what I understand, if that's what you're referring to.
| hardwaregeek wrote:
| I'd disagree about syntax. It really does matter. So much
| of Rust's success is tricking people into writing a
| functional style while having it look like an imperative
| language. OCaml syntax isn't bad per se but it's
| unfamiliar and that's enough to discourage users.
| myaccountonhn wrote:
| I think you're right, and I hate it. Just look at Gleam
| as an example where adopting a more C like syntax got
| them a ton more adoption almost over night.
|
| I love Ocaml (and Haskell-esque) syntax, but I must admit
| it can be detrimental to getting adopted.
|
| I think another issue was bad tooling for a long time.
| Now with Dune it's great though, with very fast compile
| speeds.
|
| Hopefully OCaml slowly gets the recognition it deserves,
| because it really is a great language.
| noelwelsh wrote:
| Go / Rust / Scala are the competition for OCaml, not
| Python. Around 2010 there weren't great options if you
| wanted a vaguely modern language in the server backend
| space. Java was stagnant and Scala was just getting going
| commercially. OCaml could have been in there.
| dismalaf wrote:
| > Ocaml issue is not being a USA-born project
|
| Tons of languages started outside the US. Python and Ruby
| being notable.
| aseipp wrote:
| OCaml's syntax is not what's "holding it back" in my
| personal opinion, but that doesn't mean it's "fine". I
| regularly praise it as a language (even as a former
| developer of the main Haskell compiler, which adopted
| Mixin-style modules decades after the fact) and "the
| syntax looks like shit" is absolutely one of the first
| immediate turn-offs for pretty much everyone I talk to.
| It's also one of my own complaints, but OCaml has a lot
| of good stuff too so I can put up with it.
| deredede wrote:
| This looks interesting, it's great to see more machine learning
| efforts in typed languages.
|
| I'm a bit surprised to see no mention of Owl
| (https://github.com/owlbarn/owl an older project for scientific
| computing in OCaml that was resurrected recently), I wonder how
| they compare.
|
| The Raven README mentions:
|
| > We prioritize developer experience and seamless integration.
|
| so maybe that's one difference -- I used Owl on a course project
| about a decade ago, and while it got the job done, I remember the
| experience being rather painful compared to Numpy (even though I
| was more experienced with OCaml than with Python at the time).
| UncleOxidant wrote:
| Wasn't there something about Owl being "concluded" about a year
| ago because the 2 developers no longer had time for the
| project? Is Raven the successor to Owl?
| FrustratedMonky wrote:
| Is anybody building things like this using FSharp? It seems like
| FSharp would have more of the ecosystem for machine learning and
| AI, than OCaml, yet with the functionality of OCaml.
| greener_grass wrote:
| A small community but some things going on:
|
| - https://github.com/dotnet/TorchSharp
|
| - https://github.com/DiffSharp/DiffSharp
|
| - https://github.com/fsprojects/Furnace
|
| - https://github.com/plotly/Plotly.NET
| rybosome wrote:
| As it happens, I've been thinking about a library I'd like to
| develop in F# as an exercise to learn the language.
|
| I have a hand-rolled proxying inference framework written in
| Python that is similar in purpose to something like LangChain
| but much more stripped down, less abstraction. Similarly to
| many other Python tools, it leverages the reflective
| capabilities of the language to do things like ask LLMs for
| responses conforming to a data class, or pass native Python
| functions as tools. Best of all, it relies on native Python
| constructs like docstrings to provide additional context to the
| inference APIs, making clean and well documented code a
| secondary programming model in a sense.
|
| Perhaps it's vanity, but at least in Python I find the
| resulting code quite elegant. I became curious what it would be
| like to port this to other languages, and surprisingly found
| that F# would, to my eyes, end up with the most lovely
| analogue.
|
| Even languages I expected to be expressive and terse, like
| Haskell, couldn't express the same ideas as understandably yet
| concisely as F#.
| nickpeterson wrote:
| It's a true shame F# isn't more popular. It's a great
| language/runtime combination for doing work quickly,
| correctly.
| nextos wrote:
| F# has bindings to Infer.NET, by MS Research, which is
| _incredibly_ good for some classes of probabilistic models and
| very mature.
|
| In particular, it shines on very large models or where fast
| quasi real-time inference is required.
| StopDisinfo910 wrote:
| F# is a nice language if you want to use the dotnet ecosystem
| but it's basically Ocaml without anything that makes Ocaml
| interesting (parametrised modules).
| toolslive wrote:
| Am I the only one who doesn't like notebooks ?
|
| I don't want to write code in a browser. For python you have
| something like ipython which allows you to have an interactive
| experience, while also allowing you to have your favourite
| editing environment. For ocaml, surely there are also repls that
| provide this kind of thing.
| neonsunset wrote:
| Me too, I just write .fsx scripts instead (F# interactive), it
| works nicely together with Plotly.NET. And can crunch /
| parallelize well if you want to do something over many files.
| bb1234 wrote:
| I don't like them either. I find it hard to articulate why I
| don't like them. I definitely have experienced problems with
| them where they get into some state where the cell results are
| incorrect. Then, if I restart the kernel and run the cells
| again, I get the correct result. But I don't like them for
| reasons other than this one, and cannot explain why. I prefer
| the ipython REPL to the notebook.
| sahilagarwal wrote:
| Its a bit of nostalgia for me. It took a bit of work to
| understand ipython when I first started as a programmer, but
| that effort helped me in the long run. Using ipdb for
| breakpoints was a game changer in my first job.
|
| And it also was a good way to get comfortable with using
| terminal.
|
| Using notebooks removes all these learnings. I dislike it
| because it makes for less confident programmers in the long
| run.
| nathan_compton wrote:
| I hate em. They make people write bad code and using them for
| interactive development is much worse than using a REPL. I
| cannot understand what people see in them.
| pletnes wrote:
| I use my IDE when I care about the production code, but I
| prefer notebooks when I'm just using code to understand data
| through visualization and statistics.
|
| It drives me nuts that some people see this as <<either or>>.
|
| Linqpad is another and different take on data-driven
| environments. As is various <<SQL admin>> alternatives.
| nathan_compton wrote:
| I love my fellow humans and do not begrudge you the
| workflow that you feel works for you.
| patagurbon wrote:
| They're great for teaching. But I agree for actual work.
| nsingh2 wrote:
| My workflow is to keep the notebook as thin as possible, and
| concise enough to fit in my brain. I explore the problem
| space and write some functions and data structures directly
| in the notebook, but as soon as I can, I refactor them into
| separate modules that I then import.
|
| If I don't, the notebook quickly becomes bloated, I start
| getting paranoid about stale cells and lose track of what I'm
| actually trying to do.
|
| Ideally the notebook's sole purpose is interactivity, as kind
| of a quick-and-dirty frontend when it's not worth it to write
| an actual frontend, everything infrastructural gets moved
| out.
| TJSomething wrote:
| My issue with REPLs is that they're often too transient.
| Sometimes I make a mistake on step 2 that I realize while
| iterating on step 10 of exploring some data. Then I need to
| iterate on step 2 a little, taking advantage of the ability to
| easily just run some of the calculations. Once I've got that, I
| can run the whole notebook again and make sure all my
| intermediate graphs look good.
| abathologist wrote:
| OCaml has utop, down, and the unadorned ocaml top-level.
___________________________________________________________________
(page generated 2025-04-30 23:01 UTC)