I am developing a hobby project in Kotlin. It relies on a main java library that uses a lot message bus and reactive streams (rxjava3). On top of that, I have to deal with Kotlin coroutines (because of some Kotlin libraries) and different java multi-threading and async techniques (such as CompletableFuture). The system works ok for a while (several hours or days) but in the end it get always stucked. And because events, async wait, exceptions are everywhere, running on 10s of different threads, I find very hard to understand where the problem is. Debugging this State Machine is a nightmare.
The main java library is also available in c++. 3 years ago, I have developed some hobby projects on OCaml, without using async or multi-threading libraries (lwt etc.), but enough to know the tooling (opam, ocamlfind, dune, etc) and to develop some small text parsers. I liked it a lot, because it was like F# but (at least !) free from Microsoft. The main issue was documentation. I have done some basic drawing with ocaml-sfml (which binds to the SFML c++ library), just to understand how to develop and build using a c++ lib. Compiling using a c++ lib was not easy but doable in the end (I was not even sure how to compile c++ code alone at that time !).
Besides the issue of using the c++ library, my question is around the multicores abilities of OCaml 5, which I have never used and know almost nothing, except some quick readings of Oxidizing Ocaml series on Jane Street’s website. OCaml 5 seems really interesting. I believe my Kotlin app mixes too many different techniques (rx/coroutines/java async/multithreading). I wonder if the new multicores abilities of OCaml 5 would allow to develop a simpler system. It would always be based on the message bus/rx streams of the main c++ lib, may be wrapped in something simpler. But could the remaining be handled with few multithreading/multicores techniques of OCaml 5 ? Another way to consider the problem is: how OCaml 5 multicores/multithreading model compares to java multithreading techniques and Kotlin coroutines ? Would it be simpler ?