I’ll be streaming Dream development on Twitch at 14:00 CEST on most weekdays, and definitely on every Thursday. Each time, I’ll stream for at least one hour.
Tomorrow, on Wednesday, April 19th, at 14:00 CEST, I will be continuing to review the Dream Eio PR by @talex5 and @Willenbrink, adding more detail to and revising the Dream 1.0 roadmap, and generally just be available to talk about anything related to OCaml. We can build toy projects, demos, work out concepts, etc. If you’d like to contribute to Dream, we can discuss good first issues, review your PRs, and collabarote otherwise!
Outside the stream, I can be reached in #webdev on the OCaml Discord or dream on the Reason Discord. My nickname on both is antron.
In the future, I’d be happy to consider something more interactive than a Twitch stream – something where people can talk back, probably some sort of developer or contributor meeting. But it seems that Twitch is the right place to get started.
Slightly tangential, but this seems as good a place as any to ask:
It looks like this is pretty far along, and that a migration to Eio is fait accompli at this point.
I wonder if someone could elaborate on the rationale for the migration?
As things stand now, we have a number of applications built with Dream, and they already exceed our performance expectations as built on top of the existing Lwt-based infrastructure. I’m sure Eio has its advantages, but I personally (a) appreciate a monadic style, regardless of the underlying concurrency bits, and (b) I’m not at all looking forward to porting to a different API without there being some tangible benefit.
Looking at the router considerations, if it’s of interest, we use an implementation called, for the moment, Nightmare[1] which comes “on top” of Dream, and which provides a typed route approach. There is already the Nightmare_dream layer (yes… the name is very average) and Nightmare_tyxml which takes advantage of these routes. We are currently working on the formlet part.
Isn’t isn’t so that Dream can dispatch request-response pipeline jobs across all cores? Web servers especially stateless ones seem to be pretty obviously parallelizable, no?
The Dream Eio port will probably go into a branch at first. As @yawaramin suggests, we will want to look at how Dream can behave differently if it is multicore and other such considerations.
If there is a clear advantage, Dream will transition to Eio – and that advantage will also be the answer to your query. I haven’t actually empirically observed it yet, however, so I can’t answer right now – but, correspondingly, neither are we fully committed to transitioning, though I think that it is very likely that we will see an advantage and transition.
Also, a Dream port to Eio and some Web apps built with it will probably reveal some flaws in Eio that will take time to correct, and cause additional development in Eio, so Eio Dream will remain experimental while that work is done anyway.
@xvw I am taking a look. But I want to say immediately: I think the name is great
Except that the vast majority of web workloads are IO-bound, a problem that lwt (and analogous systems in e.g. node and python) have proven to be quite adept at addressing. I suspect it’d be very hard to find a non-synthetic web serving workload that would benefit from multicore; were that not the case, far far fewer folks would have been building web apps in OCaml (or node or python, for that matter).
True, to an extent, but it’s pretty much standard practice to spin up multiple instances of Python/Ruby/Node apps on each machine so they can fully use all cores. Process managers and runtimes, from pm2 to uwsgi to systemd, all enable this (it’s nothing new). And every other multicore runtime (BEAM, Scala, Go, Rust, etc.) does it. Also, Eio is going to target Linux’s io_uring which I don’t think Lwt will.
Things like uwsgi and unicorn/gunicorn were indeed the best (only) way to achieve scale, but that’s not been the case for a long time. Especially in cloud / kubernetes environments, it’s far easier and more common to let the platform you’re running on operate N replicas of your containerized runtime, and let the upstream load balancer take care of routing, etc. That’s ignoring the fact that OCaml is (thankfully!) so much faster than python and ruby that serving requests on a single core/container is not just possible, but the easy default until there’s good reason to investigate otherwise.
But anyway, that’s all sort of tangential to the base question about tangible, non-theoretical benefits from a change that breaks all existing Dream apps. I’m open to being convinced otherwise, but a skim of the draft PR looks like migrating will require a nontrivial amount of work and/or awkward integration with big chunks of functionality that won’t be moved off of lwt anytime soon.
This may be a controversial opinion but I think OCaml needs to unify a bit on IO.
In Haskell every library that does IO can work with another library that does IO. It does not ask – which IO backend do you use? They use the same IO concurrent+parallel backend provided by the Haskell runtime. Same with Golang.
With OCaml we need to ask – is the library interface blocking? using Async? Lwt? Eio? etc. This fragments an even smaller ecosystem.
With OCaml 5 we have a chance to unify under Eio. For those people who want to do something special, they always have effects to build something custom or stick with Async/Lwt. For a large number of people, Eio will just provide the functionality and get out of the way. Most servers are not facebook scale, they would do a good job with Lwt or Eio or Async. Given that Eio has some nice properties (works on multiple cores, avoids monadic style which can be confusing for beginners, has a good path forward when effects become typed in OCaml etc.) it’s a good idea for most people to “just use Eio”.
So what does this have to do with Dream?
Given that Eio is maturing well and far along, it makes sense to build atop Eio in the future for OCaml 5+. If everything is being built on Eio, then the small OCaml ecosystem will have the actual time to build higher level things rather than spend so much time on lower level plumbing.
Eio can never be perfect. It can never optimize all cases. The hope is that it will be “good” for some cases and “not bad” for everything else.
My hope is that anchor parts of the ecosystem like Dream will ultimately use Eio so a higher set of libraries can be built atop it e.g. a django equivalent atop Dream, a phoenix framework equivalent atop Dream etc. Otherwise a lot of time is spent doing low level plumbing and building abstractions so that you could plugin this IO backend or that.
Thanks to everyone for coming to the stream today! We had a pretty good viewership! The next stream is tomorrow, Thursday, April 20th, at the same time: 14:00 CEST.
Today, we got the Eio PR building, and found some problems with it – fixing those problems offline and during the next stream will be a good way to start reviewing the internal changes in detail! We also talked about plans for Dream and discussed some of Dream’s dependencies and developer tools.
I post the next stream time and its topic in the banner image of the stream, so you can easily find out when it’s planned even when the stream is offline. Planned streams are also in the schedule. For weekdays besides Thursday, I’ll decide about streaming a few days in advance.
Suggestions for how to make the stream nicer are welcome I try to maintain a good look for my windows and use some goofy VSCode extensions. If we start doing long, boring builds, we can maybe add games for viewers to play or even a cat cam, though I think that is a stretch at this point So far, I’ve been able to do all the very slow stuff offline.
As the stream becomes more of a regular occurrence, I’ll stop posting about it here, but I’ll probably continue to announce it in the Reason and OCaml Discords, once I figure out what channels are appropriate for that. Probably #dream and #webdev, respectively.
