15 ms·

OCaml 5.0 Multicore is out

465 points by sadiq 4y ago

iainctduncan 4y ago
My interest is in (soft) real-time music systems. I'm curious if anyone can comment whether this will make OCaml a potential language in that domain. I've held off on Haskell because of the whole "you might not know how long this will take", which is a non-starter for music. I mostly use Scheme and C (and Max/MSP but with custom C/Scheme in it), but I'd love to use something other than C for the low level stuff. Wondering if anyone can comment on whether this might mean OCaml can be a contender in that space now?
- nequo 4y ago
  You can tune the behavior of OCaml’s GC. See the discussion of best-fit/next-fit/first-fit allocation here: https://dev.realworldocaml.org/garbage-collector.html https://dev.realworldocaml.org/garbage-collector.html
  - iainctduncan 4y ago
    good to know, thanks!
sadiq 4y ago
There are a few OCaml contributors lurking and happy to answer questions if you have them.
- jon_smark 4y ago
  Are the plans for typed algebraic effects solidifying, or are they still nebulous? Concretely, are you willing to take a guess as to when we are expected to see OCaml 6? ;-)
  - kcsrk 4y ago
    Rather than a full effect system, we're very likely to have lexically scoped "checked" effects with the help of modal types. I briefly talked about it at the end of my ICFP keynote: https://icfp22.sigplan.org/details/icfp-2022-papers/48/Retrofitting-Concurrency-Lessons-from-the-Engine-Room https://icfp22.sigplan.org/details/icfp-2022-papers/48/Retro... There are other cool stuff that is being worked on, which I am very excited about: https://discuss.ocaml.org/t/jane-street-compiler-development-and-open-source/10806 https://discuss.ocaml.org/t/jane-street-compiler-development.... Hopefully, we will see many of these make it into OCaml 6.
    - jon_smark 4y ago
      Thanks for the reply. I hope that the array and list comprehensions land soon in upstream; it's a useful and hopefully not-too-controversial feature. I'm more ambivalent regarding the local allocations and the unboxed types. I totally understand why they'd be useful when you are trying to squeeze every last drop of performance, but they do require a not-so-trivial complexification of the language.
      - kcsrk 4y ago
        The local types are less invasive than the full support for typed effects. In particular, they are opt-in and associated complexity is pay-as-you-go. In my initial experiments, they seemed pretty nice to program with.
  - octachron 4y ago
    The type system for algebraic effects is still in the research and design phase at this point. Right now, I am not even taking a guess of what will be the defining new major features of OCaml 6 (effect system + modular implicits maybe? Maybe not?).
    - jon_smark 4y ago
      Thanks for the reply. I'm hoping that modular macros land soon. I'm very ambivalent about the PPX mechanism, and I hope that modular macros reduces the need of PPX.
- pdimitar 4y ago
  As an Elixir (which steps on Erlang) and Rust dev I'm curious if you think OCaml 5.0 / Eio will give the Erlang's BEAM VM and Rust's tokio a run for their money in the parallel runtime space. I'm super curious about OCaml, picked it up and left it several times in the last 3 years. Now that multicore is here I'll absolutely be picking it up again and try to use it for parallel scripting and for some of my work. Great job!
  - sadiq 4y ago
    We certainly hope so. You may find Thomas Leonard's talk from last year's workshop interesting: https://watch.ocaml.org/videos/watch/74ece0a8-380f-4e2a-bef5-c6bb9092be89 https://watch.ocaml.org/videos/watch/74ece0a8-380f-4e2a-bef5... The paper we wrote on retrofitting effect handlers: https://arxiv.org/abs/2104.00250 https://arxiv.org/abs/2104.00250 also has some http benchmarks
- tomp 4y ago
  How does "bounding races in space and time" impact the generated machine code? Do you have some interesting examples of how it's different from the code C++ or JVM JIT would generate? What's the performance impact? Thanks!
  - kcsrk 4y ago
    See examples in the second section and the results in the paper: https://kcsrk.info/papers/pldi18-memory.pdf https://kcsrk.info/papers/pldi18-memory.pdf
    - tomp 4y ago
      Do you mean section 2 of the paper? It only contains C-like pseudo-code, no machine code. The results section of the paper only compare the performance of Multicore OCaml with plain OCaml, not OCaml vs C++ / Java.
      - kcsrk 4y ago
        Right. It is hard in general to compare performance or generated code across languages as they make different trade offs. Table 3 and 5 show compilation of our memory model to X86 and ARMv7. The compilation and the related work section discusses trade offs. To summarise, atomic read and write in OCaml is more expensive than C++ since C++ SC atomics only establish total order between SC operations on not operations that are weaker but related to SC operations by happens before. We need stronger atomics for local data race freedom. Our non atomic are also stronger than non atomics on C++ and Java. That said, The non atomic operations are free on X86 (compiled to plain loads and stores) and involve a lightweight fence before stores on weaker architectures such as ARM, Power and RISC-V. The performance results show that extra fences before stores have a barely noticeable impact on ARM and Power.
jon_smark 4y ago
Congratulations and a big thank you to the OCaml team! I hope that multicore support finally ticks all the requirement boxes that had prevented many from taking a serious look at OCaml. The language certainly deserves it: it hits that sweet spot between expressiveness, performance, and pragmatism like no other.
_8j50 4y ago
I started learning ocaml and i stopped when I heard about the lack of multicore support (felt like it wasn't ready for general purpose use) this is an awesome developemt. From all the functional lanuages I've sampled so far Ocaml is the most intuitive. Hoping to finally get into it in 2023. Great work Ocaml devs!
- hnra 4y ago
  Did you compare it to F#? I’ll probably try to learn an ML language next year and without doing much research F# looks really nice since it gets all the .Net benefits.
  - mbac32768 4y ago
    F# is nicer than the alternatives if you need to be (or want to be) on the Microsoft ecosystem but there are some things I miss when I use it from OCaml, like modules and functors. It also doesn't support named arguments, which are a fairly trivial thing that drastically cuts down the bugspace and increase usability for me. I also don't think F# is as fast as OCaml? Fairly relevant piece of culture on why a company switched from OCaml to F# https://blog.darklang.com/new-backend-fsharp/ https://blog.darklang.com/new-backend-fsharp/
    - jjtheblunt 4y ago
      https://learn.microsoft.com/en-us/dotnet/fsharp/language-reference/parameters-and-arguments#named-arguments https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref... might be now in there.
    - int_19h 4y ago
      I would expect F# to be faster than OCaml, given that it doesn't box floats, and is backed by a JIT that proactively does monomorphization of generics.
      - naasking 4y ago
        I doubt very much that F#/.NET is faster than OCaml. The latter is very fast, and the CLR's runtime generics have runtime costs.
vkazanov 4y ago
Amazing! An incredible amount of effort! This was holding back ocaml almost for as long as I remember - and now it's just gone. Congratulations to the team! What are the next plans for the project? Spread newly available features..?
- sadiq 4y ago
  There's definitely some work to build atop the new functionality available in 5.0 and make sure there's plenty of good learning material. In terms of the compiler and runtime development, the OCaml and ML Workshops at ICFP in October have videos that cover some of the experimental work happening: https://watch.ocaml.org/video-channels/ocaml2022/videos https://watch.ocaml.org/video-channels/ocaml2022/videos and https://www.youtube.com/playlist?list=PLyrlk8Xaylp7f8T7L5SFFwOS5_c5d1Jyq https://www.youtube.com/playlist?list=PLyrlk8Xaylp7f8T7L5SFF... There's also a compiler development newsletter that's posted on the discuss at regular intervals which details some of the other work happening: https://discuss.ocaml.org/t/ocaml-compiler-development-newsletter-issue-6-march-2022-to-september-2022/10777 https://discuss.ocaml.org/t/ocaml-compiler-development-newsl...
maattdd 4y ago
Amazing work from the team! I wonder if this is actually the first mainstream language which has managed to remove its "global lock" without breaking changes ?
- gadmm 4y ago
  To clear up any misconception, out of the box OCaml will behave like OCaml 4 with a single domain and a "domain lock". Programs currently using multiple threads for concurrency will remain single-core for the time being, as they will need to opt-in to parallelism features. In this sense, adding parallelism to OCaml does not break existing programs, but they still might have to be audited for thread-safety depending on how they want to use parallelism. There is no magic.
- sadiq 4y ago
  Just to add to the sibling comment. To maintain backwards compatibility, OCaml 5 has both threads and domains. Threads belong to a domain and only one thread can hold the runtime lock for the domain. This is the same behaviour as in OCaml 4. With OCaml 5 you can have as many domains as you want though (we recommend no more than you have cores though).
  - edwintorok 4y ago
    This backwards compatibility decision to separate threads from domains has been very useful and allows to gradually "port" existing code to 5.0: first just fixup C bindings to avoid naked pointers, and then code can safely run on OCaml 5 just as before. And once a program (and all its dependencies) have removed dependence on global state they can opt-in to multicore by spawning additional domains.
melling 4y ago
OCaml has a reputation for being fast. https://sixthhappiness.github.io/articles/python-scheme-and-ocaml-speed-comparison/index.html https://sixthhappiness.github.io/articles/python-scheme-and-... Does anyone have any multicore benchmarks that illustrate performance increases in 5.0?
- kcsrk 4y ago
  Here are some parallel benchmarks from the Sandmark continuous benchmarking service: https://sandmark.tarides.com/?app=Parallel+Benchmarks&parallel_02=%5B%27turing_5.1.0%2Btrunk%2Bparallel_20221214_aa4f842%27%5D&parallel_00=5.1.0%2Btrunk%2Bparallel&parallel_find_by=variant&parallel_01=20221214&parallel_num_variants=1 https://sandmark.tarides.com/?app=Parallel+Benchmarks&parall...
- samuell 4y ago
  Great, so, can someone send me a PR with an OCaml implementation of "my"/our GC-content benchmark (a simple string proccessing benchmark counting the fraction of G:s and C:s in DNA sequences, compared to all the A:s, C:s, G:s and T:s)? https://github.com/samuell/gccontent-benchmark https://github.com/samuell/gccontent-benchmark :D
2wrist 4y ago
Oh congratulations! Well done to all involved!
pjmlp 4y ago
Great news! Kudos to everyone that helped make this happen.
- tempodox 4y ago
  Christmas came slightly early this year.
  - octachron 4y ago
    The Christmas presents will be all the issues and bugs that will be discovered between now and Christmas eve in the shiny new multicore runtime.
pjmlp 4y ago
Great news! Kudos to everyone that helped make this happen.
deleted 4y ago
[deleted]
aylmao 4y ago
No way, it's finally out! This is fantastic news.
nih0 4y ago
this was being talked about when i was still in high school and last year i did my masters
- octachron 4y ago
  The road to multicore OCaml was indeed longer and harder than expected. At the end of the day, the constraint of trying to preserve the behavior of almost all existing programs ended up driving a majority of design choices. Typically, this required at least one major rewrite of the multicore runtime along the way.
deleted 4y ago
[deleted]
toolslive 4y ago
Halleluja! I think they were at it for more than a decade.
logicchains 4y ago
I remember around a decade ago when I first got into programming, I was super excited that OCaml would soon get multicore, regularly checking the progress. Although it took a lot longer than I imagined it would, nevertheless it feels amazing to see it finally here, almost like a dream when you've waited so long for something and you can't believe it's finally happening.
- carlmr 4y ago
  I guess I was too impatient, switched to F# right away because it felt more complete.
nequo 4y ago
Signals and Threads had an interview with Anil Madhavapeddy last year: https://signalsandthreads.com/what-is-an-operating-system/ https://signalsandthreads.com/what-is-an-operating-system/ He talked about the work to put a multicore-ready memory model[1] and GC[2] under OCaml. [1] https://anil.recoil.org/papers/2018-pldi-memorymodel.pdf https://anil.recoil.org/papers/2018-pldi-memorymodel.pdf [2] https://arxiv.org/abs/2004.11663 https://arxiv.org/abs/2004.11663
- inbx0 4y ago
  Offtopic, but Signals and Threads is my absolute favourite programming podcast, maybe even favourite podcast overall. They go into interesting topics deeply, instead of the way too common "interviewer read the summary of the wikipedia page about the subject and is now interviewing someone who actually read the entire page." Hoping they'll get more content out soon.
  - dimitropoulos 4y ago
    thanks for mentioning this! I've been looking for a new one that's good. Even if they're behind schedule, it looks like I've got some catching up to do to keep me busy in the meantime.
  - mirekrusin 4y ago
    Yaron Minsky is such a charismatic speaker, watched all his recordings you can find on internet more times that I’d like to admit, s&t is great.
  - nielsole 4y ago
    They are doing a really good job at employer branding. They make the requirements/constraints of the finance industry sound interesting. A field that cares about correctness, ordering and accurate clocks.
- forkbomb123 4y ago
  Just FYI the talk about multicore starts at 44:22
- 4y ago
no_wizard 4y ago
Jane Street must be so happy today! I think this opens up a whole new host of fast applications on ocaml. I wonder how this will affect ReScript
- KMag 4y ago
  Presumably, in cases where performance really matters, they're using single-threaded processes pinned to cores and shared memory ring buffers to communicate across processes. It ends up looking not that much different from a high performance C++ project, except for the lack of full address space sharing. Modern MMUs don't require full TLB flushes when switching address spaces, and physically tagged cache lines allow the ring buffers to be shared in cache even if they're mapped at different virtual addresses in the different processes. Also, you're guaranteed to not have false sharing, and there's zero contention for locks within malloc/free. I don't mean to suggest there are no advantages to full address space sharing, but they're both fewer and less than one would initially assume.
Alifatisk 4y ago
What an amazing ending of 2022! Just Hotwire Strada left.
mbac32768 4y ago
People who aren't PL theorists understand the multicore benefits even if the retrofitting paper might be over their heads. On the other hand, the bounding data races in time and space paper/presentation is also a fairly significant change that I don't think the average dev has an easy to understand relationship with. Anil covers it in a bit more plain English in this Signals and Threads episode. Here's a bit of the transcript, starting at about 50 minutes in: https://signalsandthreads.com/what-is-an-operating-system/ https://signalsandthreads.com/what-is-an-operating-system/ > Ron: Do you have a pithy example of a pitfall in multicore Java that doesn’t exist in multicore OCaml? > Anil: There’s something called a data race. And when you have a data race, this means that two threads of parallel execution are accessing the same memory at the same time. At this point, the program has to decide what the semantics are. In C++, for example, when you have a data race, it results in undefined behavior for the rest of the program, the program can do anything. Conventionally, daemons could fly out of your nose is an example of just what the compiler can do. > In Java, you can have data races that are bounded in time so the fact that you change a value can mean later on in execution, because of the workings of the JVM, you can then have some kind of undefined behavior. It’s very hard to debug because it is happening temporally across executions of multiple threads. > In OCaml, we guarantee that the program is consistent and sequentially consistent between data races. It’s hard to explain any more without showing you fragments of code. But conceptually, if there’s a data race in OCaml code, it will not spread in either space or time. In C++, if there’s a data race, it’ll spread to the rest of the codebase. In Java, if there’s a data race, it’ll spread through potentially multiple executions of that bit of code in the future. > In OCaml, none of those things happen. The data race happens, some consequence exists in that particular part of the code but it doesn’t spread through the program. So if you’re debugging it, you can spot your data race because it happens in a very constrained part of the application and that modularity is obviously essential for any kind of semantic reasoning about the program because you can’t be looking in your logging library for undefined behavior when you’re working on a trading strategy or something else. It’s got to be in your face, at the point. (and so on)
- jojohohanon 4y ago
  This reminds of the worse is better debate. Specifically how the “better” crowd spent a lot of time trying to solve PCLSRing while the “worse” crowd just said: meh, throw an error and let the program figure it out. Previously https://news.ycombinator.com/item?id=20225555 https://news.ycombinator.com/item?id=20225555
runevault 4y ago
Been dabbling in f# lately, but this has me wanting to give OCaml a try for comparison, very interested in the new effects stuff.
- rigoleto 4y ago
  I wish OCaml had something like F#'s lightweight syntax: https://learn.microsoft.com/en-us/dotnet/fsharp/language-reference/verbose-syntax https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref...
  - runevault 4y ago
    I'd never seen the verbose syntax for f#, I thought you had to write it the whitespace dependent way. Huh.
  - bitbckt 4y ago
    It's been tried https://people.csail.mit.edu/mikelin/ocaml+twt/ https://people.csail.mit.edu/mikelin/ocaml+twt/
    - KMag 4y ago
      Note that The Whitespace Thing actually preceded F#. (Mike and I were in the same fraternity, I remember talking to him about TWT, and we haven't talked much since our college days, which pre-date F#.) IIRC, Mike was also doing a bunch of stuff with a Jabber client in OCaml around that time.
  - cies 4y ago
    ReasonML or ReScript not your cup of tea? They are different syntactical front-ends for OCaml.
  - hawk_ 4y ago
    Lightweight syntax is a pain to use for blind people. Glad OCaml hasn't fallen for that fad.
InitEnabler 4y ago
What OSS is out there that uses OCaml?
- abathologist 4y ago
  here are a few - https://github.com/coq/coq https://github.com/coq/coq - https://github.com/mirage/mirage https://github.com/mirage/mirage - https://github.com/returntocorp/semgrep https://github.com/returntocorp/semgrep - https://github.com/bcpierce00/unison https://github.com/bcpierce00/unison See https://v2.ocaml.org/learn/companies.html https://v2.ocaml.org/learn/companies.html for some more leads, as lots of those companies maintain useful OSS software.
- actionfromafar 4y ago
  The Haxe language: https://haxe.org/ https://haxe.org/ https://frama-c.com/ https://frama-c.com/ https://fbinfer.com/ https://fbinfer.com/ https://mirage.io/ https://mirage.io/ https://coq.inria.fr/ https://coq.inria.fr/ https://github.com/ygrek/mldonkey https://github.com/ygrek/mldonkey (Stale project but large codebase.) https://akabe.github.io/ocaml-jupyter/ https://akabe.github.io/ocaml-jupyter/ https://reasonml.github.io/ https://reasonml.github.io/ https://github.com/moby/vpnkit https://github.com/moby/vpnkit (Used by Docker)
  - dunham 4y ago
    Also https://flow.org/ https://flow.org/
- giraffe_lady 4y ago
  A lot of projects also started on ocaml and then later moved off of it once they had succeeded by showing the concept works and got some momentum going. People like it for exploratory compiler dev, then switch off it when their language can self host. IIRC both rust and elm started like this, certainly others as well.
  - Skinney 4y ago
    nitpick: Elm was and is written in Haskell.
Decabytes 4y ago
I'm curious about what design decisions lead to OCaml not having Multi-threading when version 1.0 came out. Majorly impressive work getting something as complex as that added on afterwards. Kudos to everyone involved!
- dljsjr 4y ago
  Caml 1.0 was released in '85 and OCaml (the O is for Object Orientation) was 1996. Multithreading wasn't a high priority for anybody back then. The JVM didn't even have threads until 1997 and those threads were green threads, OS threads came to Java later.
  - pasc1878 4y ago
    However this is all Unix and academia based. If you wrote code for Windows and OS/2 in the commercial world you were using threads sine '89 and thus did not want to use the languages that did not use threads e.g. python, OCaml
    - jeltz 4y ago
      That was much later, in the mid 90s. But who did have threads in the mid 80s was Erlang which back then only existed in Ericsson's research lab. Ericsson had anpther internal language which Erlang drev inspiration from which also had support for concurrency.
    - cmrdporcupine 4y ago
      In the late 80s and early 90s we wrote things with threads but they were primarily a kind of convenience to get multitasking behaviour and not any kind of performance boost. Multicore / multiprocessor systems were not a mainstream thing in consumer hardware until the 21st century.
    - int_19h 4y ago
      It would be pretty difficult to write threaded code for Windows in 1989, since it didn't support threads until WinNT 3.1 (1993). But even in late 90s it was still common for desktop Win9x apps to use the main window message loop for async processing (Win32 API itself heavily encouraged it at the time - e.g. that's how OS timers work) in lieu of threads.
lilactown 4y ago
Is there a guide on how to use the new constructs? The link to the 5.0 docs was broken on the site, and after manually fixing the URL all I found was some type annotations in the `Effects` module.
- c-cube 4y ago
  The Effects module is kind of low level right now, as it understand it. You should like at Eio for a library that gives you nice fibers and non blocking IOs on top of effects! It's a neat library.
  - cies 4y ago
    > like at Eio Look at Eio here: https://github.com/ocaml-multicore/eio https://github.com/ocaml-multicore/eio
- octachron 4y ago
  The link to the Effect section of the manual at https://v2.ocaml.org/releases/5.0/manual/effects.html https://v2.ocaml.org/releases/5.0/manual/effects.html works for me and should contain an higher level description of what are effect handlers. Which link was broken for you?
  - lilactown 4y ago
    The "Manual" link on this page https://ocaml.org/releases https://ocaml.org/releases is broken
    - octachron 4y ago
      This is fixed now, thanks!
  - lilactown 4y ago
    I also didn't think to look in the "language extensions" section of the manual, instead going to the API docs and clicking on the "Effect" module. This looks much more interesting, on a skim. Thanks!
ghostwriter 4y ago
Multicore is there, STM instead of mutable imperative logic in all the libraries developed for the past two decades: not so much though.
- c-cube 4y ago
  I haven't heard anyone talk about STM for OCaml, funny. People talk about, or work on, lightweight fibers, lockfree data structures, io_uring, etc. but not STM. Is it falling out of fashion? Even in clojure I hear that few people actually use it.
  - grumpyprole 4y ago
    It works great in Haskell. The problem is that it really needs typed effects, hopefully OCaml will get typed algebraic effects at some point.
- kcsrk 4y ago
  Still early days, but I had done some exploratory work in the past on Reagents, a composable lock-free library [1]. Now that OCaml 5 is released, we're reviving this work. It's semantics is weaker than STM -- unlike STM, it doesn't provide serializability but Reagents can compile down to multi-word compare and swap operations, which can be implemented with the help of hardware transactions (when present) or efficient software implementations of it [2]. Hence, Reagent programs should be faster than STM. [1] https://github.com/ocaml-multicore/reagents https://github.com/ocaml-multicore/reagents [2] https://arxiv.org/pdf/2008.02527.pdf https://arxiv.org/pdf/2008.02527.pdf
UncleOxidant 4y ago
$ opam update $ opam switch create 5.0.0 --repositories=default $ eval $(opam env) $ ocaml OCaml version 5.0.0 Enter #help;; for help.
systems 4y ago
Still no native windows build To install on windows, I guess your best bet is via WSL (Windows Subsystem for Linux) I now run mainly on windows and this is an issue for me to try OCaml
- runevault 4y ago
  I saw some kind of other installer that might come with either MSYS2 or Cygwin I forget which, but it also said that installer takes 2 hours to run. They seem to strongly recommend WSL over it based on how I read things.
- Tomte 4y ago
  Do I misremember? I thought that was a goal for 5.0.
  - octachron 4y ago
    Not for 5.0, the aim of 5.0 was to focus on getting multicore support out of the door. Thus only mingw64 is supported for Windows. Support for MSVC will come with later versions. At the same time, improving opam ecosystem support for Windows is one of the major goal of opam 2.2 . Thus hopefully the support for native Windows will improve in the future (next year?).
    - Tomte 4y ago
      Thank you, that's good.
- dra27 4y ago
  opam 2.2's release cycle has fallen a bit behind the compiler's (actually because of the Windows support). It's an experimental branch, but this works with opam-repository-mingw to get a vanilla mingw-w64 build of OCaml 5.0.0: opam switch create 5.0 --repos=dra27=git+https://github.com/dra27/opam-repository#windows-compilers https://github.com/dra27/opam-repository#windows-compilers --packages=ocaml.5.0.0,ocaml-option-mingw
keepquestioning 4y ago
Does it support Apple Silicon Macs?
- phplovesong 4y ago
  Yes.
poulpy123 4y ago
any easy way to try it on windows (not wsl) ?
- dra27 4y ago
  It's from an experimental branch, so not very easy, but this works with opam-repository-mingw to get a vanilla mingw-w64 build of OCaml 5.0.0: opam switch create 5.0 --repos=dra27=git+https://github.com/dra27/opam-repository#windows-compilers https://github.com/dra27/opam-repository#windows-compilers --packages=ocaml.5.0.0,ocaml-option-mingw
  - poulpy123 4y ago
    Thanks I will have a look
ecshafer 4y ago
OCaml is one of those languages that is a real joy to use and makes me wonder why its not used more often. I feel like if I jump into a Lisp or ML language, I am so productive and can write some really complicated software with relative ease. But they are relatively rare in industry, and I have never really crossed the t on why, despite various reasonings about it. This is a great achievement for OCaml, but does anyone have an explanation on why it was so difficult to implement for them?
- c-cube 4y ago
  It's just very hard to write a solid concurrent GC. There are not many in existence today. Here the challenge was doubled by the obligation to preserve the single core performance of existing programs, with the very fast allocation path on the minor heap. It's always harder to add these features to an existing language that already has significant programs written in it.
  - amelius 4y ago
    Would it be possible to take this work and turn it into a more general GC library that language implementers can use beside LLVM?
    - c-cube 4y ago
      If your language matches ocaml's runtime semantics, then sure. It means uniform representation, 63bits integers, etc. but can be quite useful if your language is ML-ish.
      - sadiq 4y ago
        Also worth pointing out there's design constraints on the OCaml 5 GC imposed by some of OCaml's language features (looking at you ephemerons) and C API invariants. There may be different constraints for other runtimes.
- epolanski 4y ago
  I think John Carmack made a good point on this topic which I did not think of before. He stated that albeit he spent years working with Lisps (CL and Racket mostly) or Haskell he stated that jumping on projects in those languages instantly requires you pay the price of having to learn the abstractions and DSLs that the users wrote for the project before being able to understand anything. He compared it with C or Go, where he realized that it was easier to him to read kernel code without any context, because there is no abstraction price to pay. What you see is what there is to understand. He basically says that those languages (MLs, Lisps) are great for personal projects or very small teams but they don't scale well, this also reflects on open source where many will build their libraries and programs, but very few get into collaborating in those communities.
rg111 4y ago
What is the most fun and best source to learn OCaml for a programmer? I know this one [0] so far. Also the famous Coursera PL course covers ML. [0]: https://cs3110.github.io/textbook/cover.html https://cs3110.github.io/textbook/cover.html
rg111 4y ago
What is the most fun and best source to learn OCaml for a programmer? I know this one [0] so far. Also the famous Coursera PL course [1] covers ML. [0]: https://cs3110.github.io/textbook/cover.html https://cs3110.github.io/textbook/cover.html [1]: https://coursera.org/learn/programming-languages https://coursera.org/learn/programming-languages
- nequo 4y ago
  Check out Real World OCaml too: https://dev.realworldocaml.org/ https://dev.realworldocaml.org/
eatonphil 4y ago
If you want to see an example of it: https://v2.ocaml.org/releases/5.0/manual/parallelism.html https://v2.ocaml.org/releases/5.0/manual/parallelism.html.
deleted 4y ago
[deleted]
laylomo2 4y ago
Congrats! Super excited to start playing around with the effects system.
mnming 4y ago
Is it still possible to use Reason as frontend for Ocaml 5? I felt an ergonomic and modern syntax is the only missing piece in Ocaml.
- grumpyprole 4y ago
  There's nothing "modern" about the C-style curly brace and semi-colon syntax in Reason. In fact, the rise of Python and it's lightweight syntax means that C-style languages are starting to look dated.
  - sqlserver2008 4y ago
    Indentation-sensitive syntax is totally obsolete in a world with autoformatters. In addition, with this kind of syntax you also lose the ability to have your code autoformatted in certain situations. Here's a trivial example to illustrate the point: def example(): x = 5 print("Hello world") What's the mistake here? Depending on whether the print is part of the function, it should either be indented or have a newline before it. The point is you (and any formatting tool) can't know what the horizontal alignment of this code should be just by examining the vertical line order. You can only determine this by knowing (or reanalyzing) the semantics of the code. During a refactor where you're moving around lots of code, this can be a significant PITA. However, in the JS example, function example() { let x = 5 console.log("Hello world") } it's unambiguous what the mistake is because you can determine the correct formatting entirely from the line order, without having to know anything about the code's semantics.
    - grumpyprole 4y ago
      This is a really good point, but one still doesn't need curly braces and semis. Despite having a lightweight syntax, OCaml isn't indentation sensitive, so doesn't suffer from this. The Ocamlformat tool also works really well.
      - sqlserver2008 4y ago
acaloiar 4y ago
Meta: I believe the title should be "OCaml 5 is out!", as it appears on the OCaml site. At first glance, I understood the title "OCaml 5.0 Multicore is out" to mean "Multicore is no longer part of OCaml 5.0".
didip 4y ago
OCaml syntax is a little hard to read for plebian like me. What is the use cases for OCaml?
- defrost 4y ago
  One famous example (from 1997) is to lay out the rules for generating Fast Fourier code (for any input range, not just powers of two) and have correct efficient C code generated. [1] https://www.fftw.org/ https://www.fftw.org/ [2] https://en.wikipedia.org/wiki/FFTW https://en.wikipedia.org/wiki/FFTW
- jasperry 4y ago
  One of the top use cases for OCaml is to build interpreters and compilers for new languages. Its syntax and type system makes it very natural to navigate tree-structured data, such as ASTs. It has a great parser generator library, Menhir, as well as an up-to-date LLVM API. The first version of Rust was written in OCaml.
leoh 4y ago
Anyone know if OCaml was used at FTX, btw? Given that it's big at Jane Street, where SBF worked.
- mc10 4y ago
  Probably not, given that their public sample code[1] has C++, Go, and Python. [1]: https://github.com/ftexchange/ftx https://github.com/ftexchange/ftx
- mbac32768 4y ago
  They did not. They were a Python and React shop, with efforts underway to rewrite in Rust.
  - leoh 4y ago
    Python for trading, yikes Would love to see that codebase Then again, Stripe has been wildly successful with Ruby Albeit they’ve had type checking with sorbet for years
melony 4y ago
What's the current status of Esy? https://github.com/esy/esy https://github.com/esy/esy Any plans to backport its design back to Opam?

465 points by sadiq 4y ago

My interest is in (soft) real-time music systems. I'm curious if anyone can comment whether this will make OCaml a potential language in that domain. I've held off on Haskell because of the whole "you might not know how long this will take", which is a non-starter for music. I mostly use Scheme and C (and Max/MSP but with custom C/Scheme in it), but I'd love to use something other than C for the low level stuff. Wondering if anyone can comment on whether this might mean OCaml can be a contender in that space now?

nequo 4y ago
You can tune the behavior of OCaml’s GC. See the discussion of best-fit/next-fit/first-fit allocation here: https://dev.realworldocaml.org/garbage-collector.html https://dev.realworldocaml.org/garbage-collector.html
- iainctduncan 4y ago
  good to know, thanks!

sadiq 4y ago

There are a few OCaml contributors lurking and happy to answer questions if you have them.

jon_smark 4y ago
Are the plans for typed algebraic effects solidifying, or are they still nebulous? Concretely, are you willing to take a guess as to when we are expected to see OCaml 6? ;-)
- kcsrk 4y ago
  Rather than a full effect system, we're very likely to have lexically scoped "checked" effects with the help of modal types. I briefly talked about it at the end of my ICFP keynote: https://icfp22.sigplan.org/details/icfp-2022-papers/48/Retrofitting-Concurrency-Lessons-from-the-Engine-Room https://icfp22.sigplan.org/details/icfp-2022-papers/48/Retro... There are other cool stuff that is being worked on, which I am very excited about: https://discuss.ocaml.org/t/jane-street-compiler-development-and-open-source/10806 https://discuss.ocaml.org/t/jane-street-compiler-development.... Hopefully, we will see many of these make it into OCaml 6.
  - jon_smark 4y ago
    Thanks for the reply. I hope that the array and list comprehensions land soon in upstream; it's a useful and hopefully not-too-controversial feature. I'm more ambivalent regarding the local allocations and the unboxed types. I totally understand why they'd be useful when you are trying to squeeze every last drop of performance, but they do require a not-so-trivial complexification of the language.
    - kcsrk 4y ago
      The local types are less invasive than the full support for typed effects. In particular, they are opt-in and associated complexity is pay-as-you-go. In my initial experiments, they seemed pretty nice to program with.
- octachron 4y ago
  The type system for algebraic effects is still in the research and design phase at this point. Right now, I am not even taking a guess of what will be the defining new major features of OCaml 6 (effect system + modular implicits maybe? Maybe not?).
  - jon_smark 4y ago
    Thanks for the reply. I'm hoping that modular macros land soon. I'm very ambivalent about the PPX mechanism, and I hope that modular macros reduces the need of PPX.
pdimitar 4y ago
As an Elixir (which steps on Erlang) and Rust dev I'm curious if you think OCaml 5.0 / Eio will give the Erlang's BEAM VM and Rust's tokio a run for their money in the parallel runtime space. I'm super curious about OCaml, picked it up and left it several times in the last 3 years. Now that multicore is here I'll absolutely be picking it up again and try to use it for parallel scripting and for some of my work. Great job!
- sadiq 4y ago
  We certainly hope so. You may find Thomas Leonard's talk from last year's workshop interesting: https://watch.ocaml.org/videos/watch/74ece0a8-380f-4e2a-bef5-c6bb9092be89 https://watch.ocaml.org/videos/watch/74ece0a8-380f-4e2a-bef5... The paper we wrote on retrofitting effect handlers: https://arxiv.org/abs/2104.00250 https://arxiv.org/abs/2104.00250 also has some http benchmarks
tomp 4y ago
How does "bounding races in space and time" impact the generated machine code? Do you have some interesting examples of how it's different from the code C++ or JVM JIT would generate? What's the performance impact? Thanks!
- kcsrk 4y ago
  See examples in the second section and the results in the paper: https://kcsrk.info/papers/pldi18-memory.pdf https://kcsrk.info/papers/pldi18-memory.pdf
  - tomp 4y ago
    Do you mean section 2 of the paper? It only contains C-like pseudo-code, no machine code. The results section of the paper only compare the performance of Multicore OCaml with plain OCaml, not OCaml vs C++ / Java.
    - kcsrk 4y ago
      Right. It is hard in general to compare performance or generated code across languages as they make different trade offs. Table 3 and 5 show compilation of our memory model to X86 and ARMv7. The compilation and the related work section discusses trade offs. To summarise, atomic read and write in OCaml is more expensive than C++ since C++ SC atomics only establish total order between SC operations on not operations that are weaker but related to SC operations by happens before. We need stronger atomics for local data race freedom. Our non atomic are also stronger than non atomics on C++ and Java. That said, The non atomic operations are free on X86 (compiled to plain loads and stores) and involve a lightweight fence before stores on weaker architectures such as ARM, Power and RISC-V. The performance results show that extra fences before stores have a barely noticeable impact on ARM and Power.

jon_smark 4y ago

Congratulations and a big thank you to the OCaml team! I hope that multicore support finally ticks all the requirement boxes that had prevented many from taking a serious look at OCaml. The language certainly deserves it: it hits that sweet spot between expressiveness, performance, and pragmatism like no other.

_8j50 4y ago

I started learning ocaml and i stopped when I heard about the lack of multicore support (felt like it wasn't ready for general purpose use) this is an awesome developemt. From all the functional lanuages I've sampled so far Ocaml is the most intuitive. Hoping to finally get into it in 2023. Great work Ocaml devs!

hnra 4y ago
Did you compare it to F#? I’ll probably try to learn an ML language next year and without doing much research F# looks really nice since it gets all the .Net benefits.
- mbac32768 4y ago
  F# is nicer than the alternatives if you need to be (or want to be) on the Microsoft ecosystem but there are some things I miss when I use it from OCaml, like modules and functors. It also doesn't support named arguments, which are a fairly trivial thing that drastically cuts down the bugspace and increase usability for me. I also don't think F# is as fast as OCaml? Fairly relevant piece of culture on why a company switched from OCaml to F# https://blog.darklang.com/new-backend-fsharp/ https://blog.darklang.com/new-backend-fsharp/
  - jjtheblunt 4y ago
    https://learn.microsoft.com/en-us/dotnet/fsharp/language-reference/parameters-and-arguments#named-arguments https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref... might be now in there.
  - int_19h 4y ago
    I would expect F# to be faster than OCaml, given that it doesn't box floats, and is backed by a JIT that proactively does monomorphization of generics.
    - naasking 4y ago
      I doubt very much that F#/.NET is faster than OCaml. The latter is very fast, and the CLR's runtime generics have runtime costs.

vkazanov 4y ago

Amazing! An incredible amount of effort! This was holding back ocaml almost for as long as I remember - and now it's just gone. Congratulations to the team! What are the next plans for the project? Spread newly available features..?

sadiq 4y ago
There's definitely some work to build atop the new functionality available in 5.0 and make sure there's plenty of good learning material. In terms of the compiler and runtime development, the OCaml and ML Workshops at ICFP in October have videos that cover some of the experimental work happening: https://watch.ocaml.org/video-channels/ocaml2022/videos https://watch.ocaml.org/video-channels/ocaml2022/videos and https://www.youtube.com/playlist?list=PLyrlk8Xaylp7f8T7L5SFFwOS5_c5d1Jyq https://www.youtube.com/playlist?list=PLyrlk8Xaylp7f8T7L5SFF... There's also a compiler development newsletter that's posted on the discuss at regular intervals which details some of the other work happening: https://discuss.ocaml.org/t/ocaml-compiler-development-newsletter-issue-6-march-2022-to-september-2022/10777 https://discuss.ocaml.org/t/ocaml-compiler-development-newsl...

maattdd 4y ago

Amazing work from the team! I wonder if this is actually the first mainstream language which has managed to remove its "global lock" without breaking changes ?

gadmm 4y ago
To clear up any misconception, out of the box OCaml will behave like OCaml 4 with a single domain and a "domain lock". Programs currently using multiple threads for concurrency will remain single-core for the time being, as they will need to opt-in to parallelism features. In this sense, adding parallelism to OCaml does not break existing programs, but they still might have to be audited for thread-safety depending on how they want to use parallelism. There is no magic.
sadiq 4y ago
Just to add to the sibling comment. To maintain backwards compatibility, OCaml 5 has both threads and domains. Threads belong to a domain and only one thread can hold the runtime lock for the domain. This is the same behaviour as in OCaml 4. With OCaml 5 you can have as many domains as you want though (we recommend no more than you have cores though).
- edwintorok 4y ago
  This backwards compatibility decision to separate threads from domains has been very useful and allows to gradually "port" existing code to 5.0: first just fixup C bindings to avoid naked pointers, and then code can safely run on OCaml 5 just as before. And once a program (and all its dependencies) have removed dependence on global state they can opt-in to multicore by spawning additional domains.

melling 4y ago

OCaml has a reputation for being fast. https://sixthhappiness.github.io/articles/python-scheme-and-ocaml-speed-comparison/index.html https://sixthhappiness.github.io/articles/python-scheme-and-... Does anyone have any multicore benchmarks that illustrate performance increases in 5.0?

kcsrk 4y ago
Here are some parallel benchmarks from the Sandmark continuous benchmarking service: https://sandmark.tarides.com/?app=Parallel+Benchmarks&parallel_02=%5B%27turing_5.1.0%2Btrunk%2Bparallel_20221214_aa4f842%27%5D&parallel_00=5.1.0%2Btrunk%2Bparallel&parallel_find_by=variant&parallel_01=20221214&parallel_num_variants=1 https://sandmark.tarides.com/?app=Parallel+Benchmarks&parall...
samuell 4y ago
Great, so, can someone send me a PR with an OCaml implementation of "my"/our GC-content benchmark (a simple string proccessing benchmark counting the fraction of G:s and C:s in DNA sequences, compared to all the A:s, C:s, G:s and T:s)? https://github.com/samuell/gccontent-benchmark https://github.com/samuell/gccontent-benchmark :D

2wrist 4y ago

Oh congratulations! Well done to all involved!

pjmlp 4y ago

Great news! Kudos to everyone that helped make this happen.

tempodox 4y ago
Christmas came slightly early this year.
- octachron 4y ago
  The Christmas presents will be all the issues and bugs that will be discovered between now and Christmas eve in the shiny new multicore runtime.

pjmlp 4y ago

Great news! Kudos to everyone that helped make this happen.

deleted 4y ago

[deleted]

aylmao 4y ago

No way, it's finally out! This is fantastic news.

nih0 4y ago

this was being talked about when i was still in high school and last year i did my masters

octachron 4y ago
The road to multicore OCaml was indeed longer and harder than expected. At the end of the day, the constraint of trying to preserve the behavior of almost all existing programs ended up driving a majority of design choices. Typically, this required at least one major rewrite of the multicore runtime along the way.

deleted 4y ago

[deleted]

toolslive 4y ago

Halleluja! I think they were at it for more than a decade.

logicchains 4y ago

I remember around a decade ago when I first got into programming, I was super excited that OCaml would soon get multicore, regularly checking the progress. Although it took a lot longer than I imagined it would, nevertheless it feels amazing to see it finally here, almost like a dream when you've waited so long for something and you can't believe it's finally happening.

carlmr 4y ago
I guess I was too impatient, switched to F# right away because it felt more complete.

nequo 4y ago

Signals and Threads had an interview with Anil Madhavapeddy last year: https://signalsandthreads.com/what-is-an-operating-system/ https://signalsandthreads.com/what-is-an-operating-system/ He talked about the work to put a multicore-ready memory model[1] and GC[2] under OCaml. [1] https://anil.recoil.org/papers/2018-pldi-memorymodel.pdf https://anil.recoil.org/papers/2018-pldi-memorymodel.pdf [2] https://arxiv.org/abs/2004.11663 https://arxiv.org/abs/2004.11663

inbx0 4y ago
Offtopic, but Signals and Threads is my absolute favourite programming podcast, maybe even favourite podcast overall. They go into interesting topics deeply, instead of the way too common "interviewer read the summary of the wikipedia page about the subject and is now interviewing someone who actually read the entire page." Hoping they'll get more content out soon.
- dimitropoulos 4y ago
  thanks for mentioning this! I've been looking for a new one that's good. Even if they're behind schedule, it looks like I've got some catching up to do to keep me busy in the meantime.
- mirekrusin 4y ago
  Yaron Minsky is such a charismatic speaker, watched all his recordings you can find on internet more times that I’d like to admit, s&t is great.
- nielsole 4y ago
  They are doing a really good job at employer branding. They make the requirements/constraints of the finance industry sound interesting. A field that cares about correctness, ordering and accurate clocks.
forkbomb123 4y ago
Just FYI the talk about multicore starts at 44:22
4y ago

no_wizard 4y ago

Jane Street must be so happy today! I think this opens up a whole new host of fast applications on ocaml. I wonder how this will affect ReScript

KMag 4y ago
Presumably, in cases where performance really matters, they're using single-threaded processes pinned to cores and shared memory ring buffers to communicate across processes. It ends up looking not that much different from a high performance C++ project, except for the lack of full address space sharing. Modern MMUs don't require full TLB flushes when switching address spaces, and physically tagged cache lines allow the ring buffers to be shared in cache even if they're mapped at different virtual addresses in the different processes. Also, you're guaranteed to not have false sharing, and there's zero contention for locks within malloc/free. I don't mean to suggest there are no advantages to full address space sharing, but they're both fewer and less than one would initially assume.

Alifatisk 4y ago

What an amazing ending of 2022! Just Hotwire Strada left.

mbac32768 4y ago

People who aren't PL theorists understand the multicore benefits even if the retrofitting paper might be over their heads. On the other hand, the bounding data races in time and space paper/presentation is also a fairly significant change that I don't think the average dev has an easy to understand relationship with. Anil covers it in a bit more plain English in this Signals and Threads episode. Here's a bit of the transcript, starting at about 50 minutes in: https://signalsandthreads.com/what-is-an-operating-system/ https://signalsandthreads.com/what-is-an-operating-system/ > Ron: Do you have a pithy example of a pitfall in multicore Java that doesn’t exist in multicore OCaml? > Anil: There’s something called a data race. And when you have a data race, this means that two threads of parallel execution are accessing the same memory at the same time. At this point, the program has to decide what the semantics are. In C++, for example, when you have a data race, it results in undefined behavior for the rest of the program, the program can do anything. Conventionally, daemons could fly out of your nose is an example of just what the compiler can do. > In Java, you can have data races that are bounded in time so the fact that you change a value can mean later on in execution, because of the workings of the JVM, you can then have some kind of undefined behavior. It’s very hard to debug because it is happening temporally across executions of multiple threads. > In OCaml, we guarantee that the program is consistent and sequentially consistent between data races. It’s hard to explain any more without showing you fragments of code. But conceptually, if there’s a data race in OCaml code, it will not spread in either space or time. In C++, if there’s a data race, it’ll spread to the rest of the codebase. In Java, if there’s a data race, it’ll spread through potentially multiple executions of that bit of code in the future. > In OCaml, none of those things happen. The data race happens, some consequence exists in that particular part of the code but it doesn’t spread through the program. So if you’re debugging it, you can spot your data race because it happens in a very constrained part of the application and that modularity is obviously essential for any kind of semantic reasoning about the program because you can’t be looking in your logging library for undefined behavior when you’re working on a trading strategy or something else. It’s got to be in your face, at the point. (and so on)

jojohohanon 4y ago
This reminds of the worse is better debate. Specifically how the “better” crowd spent a lot of time trying to solve PCLSRing while the “worse” crowd just said: meh, throw an error and let the program figure it out. Previously https://news.ycombinator.com/item?id=20225555 https://news.ycombinator.com/item?id=20225555

runevault 4y ago

Been dabbling in f# lately, but this has me wanting to give OCaml a try for comparison, very interested in the new effects stuff.

rigoleto 4y ago
I wish OCaml had something like F#'s lightweight syntax: https://learn.microsoft.com/en-us/dotnet/fsharp/language-reference/verbose-syntax https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref...
- runevault 4y ago
  I'd never seen the verbose syntax for f#, I thought you had to write it the whitespace dependent way. Huh.
- bitbckt 4y ago
  It's been tried https://people.csail.mit.edu/mikelin/ocaml+twt/ https://people.csail.mit.edu/mikelin/ocaml+twt/
  - KMag 4y ago
    Note that The Whitespace Thing actually preceded F#. (Mike and I were in the same fraternity, I remember talking to him about TWT, and we haven't talked much since our college days, which pre-date F#.) IIRC, Mike was also doing a bunch of stuff with a Jabber client in OCaml around that time.
- cies 4y ago
  ReasonML or ReScript not your cup of tea? They are different syntactical front-ends for OCaml.
- hawk_ 4y ago
  Lightweight syntax is a pain to use for blind people. Glad OCaml hasn't fallen for that fad.

InitEnabler 4y ago

What OSS is out there that uses OCaml?

abathologist 4y ago
here are a few - https://github.com/coq/coq https://github.com/coq/coq - https://github.com/mirage/mirage https://github.com/mirage/mirage - https://github.com/returntocorp/semgrep https://github.com/returntocorp/semgrep - https://github.com/bcpierce00/unison https://github.com/bcpierce00/unison See https://v2.ocaml.org/learn/companies.html https://v2.ocaml.org/learn/companies.html for some more leads, as lots of those companies maintain useful OSS software.
actionfromafar 4y ago
The Haxe language: https://haxe.org/ https://haxe.org/ https://frama-c.com/ https://frama-c.com/ https://fbinfer.com/ https://fbinfer.com/ https://mirage.io/ https://mirage.io/ https://coq.inria.fr/ https://coq.inria.fr/ https://github.com/ygrek/mldonkey https://github.com/ygrek/mldonkey (Stale project but large codebase.) https://akabe.github.io/ocaml-jupyter/ https://akabe.github.io/ocaml-jupyter/ https://reasonml.github.io/ https://reasonml.github.io/ https://github.com/moby/vpnkit https://github.com/moby/vpnkit (Used by Docker)
- dunham 4y ago
  Also https://flow.org/ https://flow.org/
giraffe_lady 4y ago
A lot of projects also started on ocaml and then later moved off of it once they had succeeded by showing the concept works and got some momentum going. People like it for exploratory compiler dev, then switch off it when their language can self host. IIRC both rust and elm started like this, certainly others as well.
- Skinney 4y ago
  nitpick: Elm was and is written in Haskell.

Decabytes 4y ago

I'm curious about what design decisions lead to OCaml not having Multi-threading when version 1.0 came out. Majorly impressive work getting something as complex as that added on afterwards. Kudos to everyone involved!

dljsjr 4y ago
Caml 1.0 was released in '85 and OCaml (the O is for Object Orientation) was 1996. Multithreading wasn't a high priority for anybody back then. The JVM didn't even have threads until 1997 and those threads were green threads, OS threads came to Java later.
- pasc1878 4y ago
  However this is all Unix and academia based. If you wrote code for Windows and OS/2 in the commercial world you were using threads sine '89 and thus did not want to use the languages that did not use threads e.g. python, OCaml
  - jeltz 4y ago
    That was much later, in the mid 90s. But who did have threads in the mid 80s was Erlang which back then only existed in Ericsson's research lab. Ericsson had anpther internal language which Erlang drev inspiration from which also had support for concurrency.
  - cmrdporcupine 4y ago
    In the late 80s and early 90s we wrote things with threads but they were primarily a kind of convenience to get multitasking behaviour and not any kind of performance boost. Multicore / multiprocessor systems were not a mainstream thing in consumer hardware until the 21st century.
  - int_19h 4y ago
    It would be pretty difficult to write threaded code for Windows in 1989, since it didn't support threads until WinNT 3.1 (1993). But even in late 90s it was still common for desktop Win9x apps to use the main window message loop for async processing (Win32 API itself heavily encouraged it at the time - e.g. that's how OS timers work) in lieu of threads.

lilactown 4y ago

Is there a guide on how to use the new constructs? The link to the 5.0 docs was broken on the site, and after manually fixing the URL all I found was some type annotations in the `Effects` module.

c-cube 4y ago
The Effects module is kind of low level right now, as it understand it. You should like at Eio for a library that gives you nice fibers and non blocking IOs on top of effects! It's a neat library.
- cies 4y ago
  > like at Eio Look at Eio here: https://github.com/ocaml-multicore/eio https://github.com/ocaml-multicore/eio
octachron 4y ago
The link to the Effect section of the manual at https://v2.ocaml.org/releases/5.0/manual/effects.html https://v2.ocaml.org/releases/5.0/manual/effects.html works for me and should contain an higher level description of what are effect handlers. Which link was broken for you?
- lilactown 4y ago
  The "Manual" link on this page https://ocaml.org/releases https://ocaml.org/releases is broken
  - octachron 4y ago
    This is fixed now, thanks!
- lilactown 4y ago
  I also didn't think to look in the "language extensions" section of the manual, instead going to the API docs and clicking on the "Effect" module. This looks much more interesting, on a skim. Thanks!

ghostwriter 4y ago

Multicore is there, STM instead of mutable imperative logic in all the libraries developed for the past two decades: not so much though.

c-cube 4y ago
I haven't heard anyone talk about STM for OCaml, funny. People talk about, or work on, lightweight fibers, lockfree data structures, io_uring, etc. but not STM. Is it falling out of fashion? Even in clojure I hear that few people actually use it.
- grumpyprole 4y ago
  It works great in Haskell. The problem is that it really needs typed effects, hopefully OCaml will get typed algebraic effects at some point.
kcsrk 4y ago
Still early days, but I had done some exploratory work in the past on Reagents, a composable lock-free library [1]. Now that OCaml 5 is released, we're reviving this work. It's semantics is weaker than STM -- unlike STM, it doesn't provide serializability but Reagents can compile down to multi-word compare and swap operations, which can be implemented with the help of hardware transactions (when present) or efficient software implementations of it [2]. Hence, Reagent programs should be faster than STM. [1] https://github.com/ocaml-multicore/reagents https://github.com/ocaml-multicore/reagents [2] https://arxiv.org/pdf/2008.02527.pdf https://arxiv.org/pdf/2008.02527.pdf

UncleOxidant 4y ago

$ opam update $ opam switch create 5.0.0 --repositories=default $ eval $(opam env) $ ocaml OCaml version 5.0.0 Enter #help;; for help.

systems 4y ago

Still no native windows build To install on windows, I guess your best bet is via WSL (Windows Subsystem for Linux) I now run mainly on windows and this is an issue for me to try OCaml

runevault 4y ago
I saw some kind of other installer that might come with either MSYS2 or Cygwin I forget which, but it also said that installer takes 2 hours to run. They seem to strongly recommend WSL over it based on how I read things.
Tomte 4y ago
Do I misremember? I thought that was a goal for 5.0.
- octachron 4y ago
  Not for 5.0, the aim of 5.0 was to focus on getting multicore support out of the door. Thus only mingw64 is supported for Windows. Support for MSVC will come with later versions. At the same time, improving opam ecosystem support for Windows is one of the major goal of opam 2.2 . Thus hopefully the support for native Windows will improve in the future (next year?).
  - Tomte 4y ago
    Thank you, that's good.
dra27 4y ago
opam 2.2's release cycle has fallen a bit behind the compiler's (actually because of the Windows support). It's an experimental branch, but this works with opam-repository-mingw to get a vanilla mingw-w64 build of OCaml 5.0.0: opam switch create 5.0 --repos=dra27=git+https://github.com/dra27/opam-repository#windows-compilers https://github.com/dra27/opam-repository#windows-compilers --packages=ocaml.5.0.0,ocaml-option-mingw

keepquestioning 4y ago

Does it support Apple Silicon Macs?

phplovesong 4y ago
Yes.

poulpy123 4y ago

any easy way to try it on windows (not wsl) ?

dra27 4y ago
It's from an experimental branch, so not very easy, but this works with opam-repository-mingw to get a vanilla mingw-w64 build of OCaml 5.0.0: opam switch create 5.0 --repos=dra27=git+https://github.com/dra27/opam-repository#windows-compilers https://github.com/dra27/opam-repository#windows-compilers --packages=ocaml.5.0.0,ocaml-option-mingw
- poulpy123 4y ago
  Thanks I will have a look

ecshafer 4y ago

OCaml is one of those languages that is a real joy to use and makes me wonder why its not used more often. I feel like if I jump into a Lisp or ML language, I am so productive and can write some really complicated software with relative ease. But they are relatively rare in industry, and I have never really crossed the t on why, despite various reasonings about it. This is a great achievement for OCaml, but does anyone have an explanation on why it was so difficult to implement for them?

c-cube 4y ago
It's just very hard to write a solid concurrent GC. There are not many in existence today. Here the challenge was doubled by the obligation to preserve the single core performance of existing programs, with the very fast allocation path on the minor heap. It's always harder to add these features to an existing language that already has significant programs written in it.
- amelius 4y ago
  Would it be possible to take this work and turn it into a more general GC library that language implementers can use beside LLVM?
  - c-cube 4y ago
    If your language matches ocaml's runtime semantics, then sure. It means uniform representation, 63bits integers, etc. but can be quite useful if your language is ML-ish.
    - sadiq 4y ago
      Also worth pointing out there's design constraints on the OCaml 5 GC imposed by some of OCaml's language features (looking at you ephemerons) and C API invariants. There may be different constraints for other runtimes.
epolanski 4y ago
I think John Carmack made a good point on this topic which I did not think of before. He stated that albeit he spent years working with Lisps (CL and Racket mostly) or Haskell he stated that jumping on projects in those languages instantly requires you pay the price of having to learn the abstractions and DSLs that the users wrote for the project before being able to understand anything. He compared it with C or Go, where he realized that it was easier to him to read kernel code without any context, because there is no abstraction price to pay. What you see is what there is to understand. He basically says that those languages (MLs, Lisps) are great for personal projects or very small teams but they don't scale well, this also reflects on open source where many will build their libraries and programs, but very few get into collaborating in those communities.

rg111 4y ago

What is the most fun and best source to learn OCaml for a programmer? I know this one [0] so far. Also the famous Coursera PL course covers ML. [0]: https://cs3110.github.io/textbook/cover.html https://cs3110.github.io/textbook/cover.html

rg111 4y ago

What is the most fun and best source to learn OCaml for a programmer? I know this one [0] so far. Also the famous Coursera PL course [1] covers ML. [0]: https://cs3110.github.io/textbook/cover.html https://cs3110.github.io/textbook/cover.html [1]: https://coursera.org/learn/programming-languages https://coursera.org/learn/programming-languages

nequo 4y ago
Check out Real World OCaml too: https://dev.realworldocaml.org/ https://dev.realworldocaml.org/

eatonphil 4y ago

If you want to see an example of it: https://v2.ocaml.org/releases/5.0/manual/parallelism.html https://v2.ocaml.org/releases/5.0/manual/parallelism.html.

deleted 4y ago

[deleted]

laylomo2 4y ago

Congrats! Super excited to start playing around with the effects system.

mnming 4y ago

Is it still possible to use Reason as frontend for Ocaml 5? I felt an ergonomic and modern syntax is the only missing piece in Ocaml.

grumpyprole 4y ago
There's nothing "modern" about the C-style curly brace and semi-colon syntax in Reason. In fact, the rise of Python and it's lightweight syntax means that C-style languages are starting to look dated.
- sqlserver2008 4y ago
  Indentation-sensitive syntax is totally obsolete in a world with autoformatters. In addition, with this kind of syntax you also lose the ability to have your code autoformatted in certain situations. Here's a trivial example to illustrate the point: def example(): x = 5 print("Hello world") What's the mistake here? Depending on whether the print is part of the function, it should either be indented or have a newline before it. The point is you (and any formatting tool) can't know what the horizontal alignment of this code should be just by examining the vertical line order. You can only determine this by knowing (or reanalyzing) the semantics of the code. During a refactor where you're moving around lots of code, this can be a significant PITA. However, in the JS example, function example() { let x = 5 console.log("Hello world") } it's unambiguous what the mistake is because you can determine the correct formatting entirely from the line order, without having to know anything about the code's semantics.
  - grumpyprole 4y ago
    This is a really good point, but one still doesn't need curly braces and semis. Despite having a lightweight syntax, OCaml isn't indentation sensitive, so doesn't suffer from this. The Ocamlformat tool also works really well.
    - sqlserver2008 4y ago

acaloiar 4y ago

Meta: I believe the title should be "OCaml 5 is out!", as it appears on the OCaml site. At first glance, I understood the title "OCaml 5.0 Multicore is out" to mean "Multicore is no longer part of OCaml 5.0".

didip 4y ago

OCaml syntax is a little hard to read for plebian like me. What is the use cases for OCaml?

defrost 4y ago
One famous example (from 1997) is to lay out the rules for generating Fast Fourier code (for any input range, not just powers of two) and have correct efficient C code generated. [1] https://www.fftw.org/ https://www.fftw.org/ [2] https://en.wikipedia.org/wiki/FFTW https://en.wikipedia.org/wiki/FFTW
jasperry 4y ago
One of the top use cases for OCaml is to build interpreters and compilers for new languages. Its syntax and type system makes it very natural to navigate tree-structured data, such as ASTs. It has a great parser generator library, Menhir, as well as an up-to-date LLVM API. The first version of Rust was written in OCaml.

leoh 4y ago

Anyone know if OCaml was used at FTX, btw? Given that it's big at Jane Street, where SBF worked.

mc10 4y ago
Probably not, given that their public sample code[1] has C++, Go, and Python. [1]: https://github.com/ftexchange/ftx https://github.com/ftexchange/ftx
mbac32768 4y ago
They did not. They were a Python and React shop, with efforts underway to rewrite in Rust.
- leoh 4y ago
  Python for trading, yikes Would love to see that codebase Then again, Stripe has been wildly successful with Ruby Albeit they’ve had type checking with sorbet for years

melony 4y ago

What's the current status of Esy? https://github.com/esy/esy https://github.com/esy/esy Any plans to backport its design back to Opam?