Peertube has been a fantastic way to mirror videos from Youtube and have embedded versions that are ad- and cookie-free. It's got support for mirroring channels from the other video providers which makes it a breeze to run. I've deployed it for various communities:
The fediverse integration is a minor plus, but the permanent nature of the video hosting. My only wish is that there was a way to bidirectionally mirror view counts, so that the Peertube mirrors don't look like a ghost town.
There was a Commercial Uses of Functional Programming workshop talk back in 2009 where the engineers behind Facebook Chat talked about their use of Erlang.
Effects are included in OCaml 5, but considered experimental. This doesn't stop us from building libraries that take advantage of them internally, in order to provide really nice external interfaces.
The best developed one is "eio", which uses effects (and io_uring on Linux) internally in order to provide a really high performance, direct-style IO library for OCaml. You can walk through some of the code here: https://github.com/ocaml-multicore/eio#getting-started
And then there are deployments in QubesOS, Xen, Nitrokey, etc. Bear in mind that MirageOS is a library OS, which doesn't just mean "compile to a standalone kernel instance". It just means that it can be linked into all sorts of embedded environments, some of which are the solo5 or Xen backends you see in talks.
This all started because we wanted to _get away_ from the need to fork or run multiple processes, since that's so hard in a variety of hardware architectures (like mobile or embedded).
It took a little longer than I'd planned, but thanks to the hard work of so many MirageOS contributors, now's a pretty good time to glue back personal containers and self-hosted data management infrastructure again! Unikernel-based messaging has really come together in the past couple of years: https://tarides.com/blog/2022-03-08-secure-virtual-messages-...
Just substitute 'microservice' with 'unikernel' and you do broadly the same things. There's a prometheus library that you link with the MirageOS unikernel and it exports using that: https://github.com/mirage/prometheus
No FAQ for this sort of thing yet, but we should start assembling one sometime soon. Questions like this very welcome on the discussion forums: https://discuss.ocaml.org/t/ann-mirageos-4-0/9598 to help us get started.
Note that Eio is more than just a direct replacement for Lwt and Async. We couldn't resist using some of the experiences also gained from the MirageOS (mirage.io) unikernel framework in EIO. This means that the backends are highly optimised to use the best syscalls available in the OS (e.g. io_uring by default in Linux). If you write your applications to use Eio natively, then performance is very high so far. The ergonomics of programming in it also compare favourably to using monadic concurrency.
I just lurk the OCaml forums so don't take what I say as gospel but from what I've understood EIO will _not_ be part of stdlib. The OCaml devs go out of their way to not break things in stdlib so from what I've gathered they don't want to include it EIO until there's more real world experience with it and the API has started to settle down. Including it in stdlib might also never happen but that remains to be seen.
It's too early to say. Eio is still under very active development, so we'll have to see how it goes. The more useful feedback we get on it now, the more likely it'll be submitted for consideration in the OCaml stdlib when appropriate.
The performance numbers are in the paper abstract: "our evaluation demonstrates that it is possible to balance a comprehensible memory model with a reasonable (no overhead on x86, ~0.6% on ARM) sequential performance trade-off in a mainstream programming language". It's a little higher on PowerPC but still very usable, and RISC-V overheads should be roughly comparable to ARM.
As the paper clarifies, this is for the performance of non-atomic read/writes in sequential setting. The paper left the performance evaluation for atomic read/writes to future work. Is there any indication yet regarding the performance in a parallel setting compared to weaker guarantees?
That's right -- we first wanted to establish that existing OCaml code wouldn't be adversely impacted. There are various efforts ongoing to build interested (locked and lock-free) concurrent data structures, so that will inform the parallel performance results. Nothing published yet.
We are just finishing edits of a few chapters (the tooling, testing and GADT ones), and then it’ll be off to the publishers early in the new year. The online one is therefore pretty up to date.
since you're here, what do you think about starting a new OCaml project with esy as best practice today? I was working on https://o1-labs.github.io/ocamlbyexample/ and I was thinking of starting with that approach as it seems to provide a more modern experience than just opam/dune. (I read your book as introduction to OCaml and still struggled a ton with all the edge-cases of dune and opam. Even today I'm iffy every time I start working on some OCaml code again because I know I'll have to deal with opam/dune issues.)
You may find the “nnpchecker” configure option in 4.13.0 useful. This will print a detected use of naked pointers to stderr, which can hopefully be triggered by test suites.
Noalloc and registering roots should all be the same, as are callbacks (for sequential code, which all existing code will be)
- https://watch.ocaml.org (for all the OCaml language talks over the past 20 years)
- https://watch.eeg.cl.cam.ac.uk (for our research group on environmental science)
- https://crank.recoil.org (for my personal talks and videos)
The fediverse integration is a minor plus, but the permanent nature of the video hosting. My only wish is that there was a way to bidirectionally mirror view counts, so that the Peertube mirrors don't look like a ghost town.