OCaml's Wings for Machine Learning(github.com)
github.com
OCaml's Wings for Machine Learning
https://github.com/raven-ml/raven
72 comments
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.
The alternative is not programming purely in the repl but to have an editor where you type out your code and from where you can send bits of text to the repl to run and get feedback. All major editors have plugins to do this.
[deleted]
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.
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.
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.
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.
I love my fellow humans and do not begrudge you the workflow that you feel works for you.
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.
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.
You can write great code in notebooks; it all depends on you. Eg if you use vscode and not the browser for jupyter notebooks, you will have the same type checking and formatting as in the editor itself if you have it enabled.
For interactive development, repl is a joke. Sketching out a fully working prototype of a few hundred lines of code (possibly depending on some data and context you don't want to reload) is impossible in repl.
For interactive development, repl is a joke. Sketching out a fully working prototype of a few hundred lines of code (possibly depending on some data and context you don't want to reload) is impossible in repl.
They’re great for teaching. But I agree for actual work.
I totally dislike notebooks in the first place for a totally different reason. I'm really attached to my keyboard shortcuts, when I'm in a text editor or an IDE I have one specific "layout", but in the browser another. Some of my text editing shortcuts conflict with those in the browser (looking at you, ctrl-w for example).
I don't want to adapt, the shortcuts in the browser remain in the browser, and same for text editing, no overlapping.
I don't want to adapt, the shortcuts in the browser remain in the browser, and same for text editing, no overlapping.
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.
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.
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.
OCaml has utop, down, and the unadorned ocaml top-level.
Obligatory, Joel Grus: I don't like notebooks.
https://www.youtube.com/watch?v=7jiPeIFXb6U
And the slides; https://docs.google.com/presentation/d/1n2RlMdmv1p25Xy5thJUh...
https://www.youtube.com/watch?v=7jiPeIFXb6U
And the slides; https://docs.google.com/presentation/d/1n2RlMdmv1p25Xy5thJUh...
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.
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#.
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#.
It’s a true shame F# isn’t more popular. It’s a great language/runtime combination for doing work quickly, correctly.
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
- https://github.com/dotnet/TorchSharp
- https://github.com/DiffSharp/DiffSharp
- https://github.com/fsprojects/Furnace
- https://github.com/plotly/Plotly.NET
Yes, I use F# with TorchSharp to do machine learning. My most recent project is a Hearts AI that is quite good. Here are some links:
* https://github.com/brianberns/Hearts
* https://github.com/brianberns/MinGptSharp
* https://github.com/brianberns/ModestGpt
* https://github.com/brianberns/DeepKuhnPoker
* https://github.com/brianberns/Hearts
* https://github.com/brianberns/MinGptSharp
* https://github.com/brianberns/ModestGpt
* https://github.com/brianberns/DeepKuhnPoker
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.
In particular, it shines on very large models or where fast quasi real-time inference is required.
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).
Besides parametrized modules what else do you think F# is missing? To me it seems like a 10x more powerful choice because of much richer GUI and web framework choices, great tooling and high flexibility as a language (computation expressions, does scripting, multitasking/multithreading and even low-level (when needed) quite well).
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).
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).
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?
It was, but then they changed their mind apparently
https://discuss.ocaml.org/t/owl-project-restructured/14226
Too early to tell what it will lead to.
> Is Raven the successor to Owl?
That's what I am wondering too (especially with the name), but I couldn't find a reference to Owl in the repo.
https://discuss.ocaml.org/t/owl-project-restructured/14226
Too early to tell what it will lead to.
> Is Raven the successor to Owl?
That's what I am wondering too (especially with the name), but I couldn't find a reference to Owl in the repo.
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.
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.
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.
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.
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.
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.
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.
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.
Maybe F# as a middle ground? Although if you have religious avoidance of JIT compilation, using NativeAOT with F# has a few rough edges right now (it works, but you need to be aware of edge cases, with that said, you can still make fairly compact standalone binaries with JIT, it's just that they'll take say 10MB and not 2-3).
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.
> Ocaml issue is not being a USA-born project
Tons of languages started outside the US. Python and Ruby being notable.
Tons of languages started outside the US. Python and Ruby being notable.
100% agreed. The moment I saw the “revised” syntax I had a real “what were they thinking” moment. You’re supposed to take the good parts of a good thing and add it to a bad thing, not the other way around!
Really, OCaml’s syntax is beautiful, unless you’re one of those people who loves to show off how adept they are at typing matching braces, parentheses, commas, and semicolons. Writing a little lambda in C++ is an impressive display of manual dexterity… [&](…,…){… return …; }; Who would rather write that than let f x y = … in?
The only way I’d improve OCaml syntax would be to add something like python style list comprehension.
Really, OCaml’s syntax is beautiful, unless you’re one of those people who loves to show off how adept they are at typing matching braces, parentheses, commas, and semicolons. Writing a little lambda in C++ is an impressive display of manual dexterity… [&](…,…){… return …; }; Who would rather write that than let f x y = … in?
The only way I’d improve OCaml syntax would be to add something like python style list comprehension.
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.
Scala really had potential. But I really think they pushed away the average developer and with Scala 3 fractured their ecosystem even more. I personally wish the community had stayed true to the vision of fusing object and functional programming.
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.
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.
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.
Rust refs are not OCaml refs though. Rust just places more guardrails around update-in-place model, instead of using controlled references to immutable data like OCaml (and Clojure).
The lack of ad-hoc polymorphism has to be there somewhere as well.
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.
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.
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.
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.
> Modular implicits have been shelved indefinitely from what I understand, if that's what you're referring to.
They have not — people are still working on it. There's been a paper at the OCaml Workshop at ICFP this year, and a PR on the OCaml repo. The student who worked on this is now starting a PhD on modular implicits in the lab that created OCaml.
They have not — people are still working on it. There's been a paper at the OCaml Workshop at ICFP this year, and a PR on the OCaml repo. The student who worked on this is now starting a PhD on modular implicits in the lab that created OCaml.
Isn't Ocaml's module system based on StandardML? SML predates Ocaml by a few years and non-standardized ML by a couple decades.
Oh actually I'm not sure. I was thinking it was one of the things ocaml added but now I think you're right.
> Ocaml issue is not being a USA-born project nor having a significant marketing push in English.
Python is a counter argument here.
Python is a counter argument here.
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.
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.
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.
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.
> 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.
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.
> 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.
OCaml's syntax is not particularly Pascal-like. It'd be very hard for someone to mistake Pascal code for OCaml or vice versa.
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.
It obviously went through ML but you can tell the influence.
If you compare OCaml and Standard ML, which came before it, it seems like OCaml is a lot like SML but with some changed syntax for convenience, and imperative features syntax for featyres that were technically supported by SML but still awkward, and I think it's in those imperative parts where they most resemble Pascal and Algol. They added "begin" and "end" as keywords equivalent to parentheses, they added for loops, and classes, and changed array syntax to resemble other languages more (by using square brackets to indicate an array subscript).
http://adam.chlipala.net/mlcomp/
http://adam.chlipala.net/mlcomp/
> ... 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)
Who are you quoting here?
the quote is the part between the dots; my comment is about why the number of developer resources might limited.
> the quote is the part between the dots; my comment is about why the number of developer resources might limited.
Very confusing. On HN, it's customary to follow the email-style convention of using the '>' symbol for quotes and placing them on separate lines.
Very confusing. On HN, it's customary to follow the email-style convention of using the '>' symbol for quotes and placing them on separate lines.
You are right.
However, in my defense, the '>' is there, the dots are an ellipse omitting the part that I'm not commenting on and I only noticed my comment was not placed on a separate line after I was no longer able/allowed to edit the comment.
However, in my defense, the '>' is there, the dots are an ellipse omitting the part that I'm not commenting on and I only noticed my comment was not placed on a separate line after I was no longer able/allowed to edit the comment.
> 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.
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.
> 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.
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.
> 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.
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.
If you care about efficient parallelism, F# might give you much better experience and results.
To be pedantic, concurrency in OCaml has been fine with lwt. Single threaded concurrency, not unlike how JS does it.
I'm going to be sarcastic _and_ on topic (you baited me): yeah, like how python completely solved concurrency & parallelism.
OCaml has had great concurrency support for years and years. Multicore is only a question of shared memory parallelism.
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.