we have 2 main competitors right now: eio and miou
I’d like to emphasise this sentence. As far as Robur and Miou are concerned, we don’t see ourselves as a competitor to Eio. In fact, we don’t consider Eio to be bad but, as it says in Miou’s genesis, our aim has been to separate ourselves (by creating a new scheduler) from Eio because we don’t want to fit in socially with what Eio represents (in its proposal and in its method of adoption).
In this respect, and I’ve been able to say this publicly several times, we’ve had various differences of opinion with the Eio team that aren’t technical. Being a small team at Robur, we decided, precisely 2 and a half years ago, to save our brain time because we were not satisfied with the interactions we were able to have with the Eio team.
the problem is not to enable concurrency model to co-exist, the problem is that there are multiple concurrency models
I’d also like to reiterate what we’ve been saying for quite a few years now. The fragmentation of the community across several schedulers didn’t pose any particular problem for us at the time of Lwt/Async. It still doesn’t pose a problem for us at this stage, despite the saturation of schedulers for OCaml 5. We think of our libraries independently of schedulers and our approach has worked for over 10 years. I’ve already said that we’ll continue this approach even if we develop Miou ourselves. We could be more authoritarian and consider that all our interactions with the system in our libraries should go through Miou but our experience shows us day after day that the time spent making libraries independent from schedulers is a good approach for the community in general.
A home-made composition of these libraries with any scheduler is often quite satisfying (especially when it comes to grasping the specific advantages of these schedulers).
As far as I can remember, the history of compatibility between schedulers does not date back to OCaml 5 but attempts have been made in the past. My opinion (and I may be wrong but I tend to think so) is that it is indeed impossible to reconcile several models of cooperation even if partial efforts can be made in this direction at the community level. In this case, the trials between Picos & Miou have confirmed this observation more than the other way round. The past also confirms it.
I also think that Picos goes too far in what it proposes and already has a certain opinion of what a scheduler should be. Here too, like Eio, an attempt has been made to develop our libraries in a way that would satisfy the community. Unfortunately this attempt failed because of trivial issues. And here again, as a small team unable to manage several fronts, we decided not to make any more effort than was necessary.
More generally, I think that two trends are emerging on the question of schedulers. There is one approach, which I would call authoritarian, where the idea is to propose a single model of task cooperation that will satisfy as many people as possible. It seems accepted that the latter should be integrated into OCaml, a point on which I agree. One could imagine Picos as a candidate but it has been confirmed to me that the Picos developers do not wish to interact with the OCaml core-team. Eio also took this approach at the beginning, presenting itself as the scheduler for OCaml 5 and having a fairly aggressive communication compared to the other proposals.
Personally, and from my experience with Lwt and Async and my opinions too, I’m not too keen on this approach preferring diversity of solutions and the possibility of choice.
The other approach is to accept the situation as it is. Again, as far as Robur is concerned, this situation is not unsatisfactory. Eio supports co-exist with those of Miou and Lwt in our libraries. Switching from one scheduler to another is not a problem for us. It may be unsatisfactory for new users, but I think that from this particular point of view, even a new user can identify and understand the difficulty of homogenising an entire community on a single scheduler. They can also understand the frameworks within which the various schedulers have been developed.
As it happens, some articles and discussions I’ve had with others about the choice between Lwt and Async are essentially based on social and concrete realities (maintenance of the scheduler by a large company or a small cooperative, documentation, examples of use, interactions with maintainers, etc.). And if we had to specify the subtle and technical differences that there may be between schedulers in order to make a choice, a third possibility exists (just as legitimate): you could make your own scheduler! And this is perhaps the big difference between OCaml 4 and OCaml 5, with the effects, it’s easy to make a new scheduler.
its own controversial decisions, such as supporting only select.
Miou was designed (as was Affect, I think) for strict separation between the system polling method and the scheduler. The very basic idea behind such a separation (which also concerns Lwt by the way) is that we don’t have Unix.select on our unikernels.
Extending Miou with epoll or io_uring is possible. Unix.select was chosen because it is the easiest and quickest to develop.
The most prominent example I know of is tokio in Rust.
I don’t think the grass is any greener elsewhere. Rust also has a fragmented community when it comes to schedulers (radeon, smol, embassy, glommio).
This is where I’d like to re-clarify Miou. Miou is based on objectives linked to our cooperative: developing services and unikernels. That’s the case with all the other proposals for that matter - but I’d be careful not to say what their objectives are. Miou’s ambition is not to satisfy as many people as possible or to compete with anyone else. Its aim is to satisfy, in this case, 4 people first and foremost, the members of our Robur cooperative - which is not bad at all! And that’s all… Then we can try to communicate about Miou and show that it’s a solution that at least works for us. But we won’t pretend that it’s the solution.
Finally, if people want to participate in Miou, they can, as is the case with all our other projects. Our interactions with users over the years are proof of our openness to contribution and compromise. But if people want to use something else, that’s their fundamental choice.
