how does this compare to the inbox and supervisor model of erlang/elixir?

  >> Its' interprocess communication is TCP based in general case
  > No, it is not. Only between machines is that true.

  > Why are you rolling with "speaking a whole lot of BS based on ignorance" today?

I'm always hearing about FoundationDB but not much about who uses it. I know Deno and obviously Apple is using it. Who else? I'd love to hear some stories about it.

How did they come up with such an original and unique name? Apple does it again.

Type-safe message-passing is such a wonderful programming paradigm - and not just for distributed applications. I remember using QNX back in the 1990s. One of its fabulous features was a C message passing library allowing you to send arbitrary binary structs from one process to another. In the context of realtime software development, you often find yourself having one process that watches for events from a certain device, modify the information somehow, and then pass it on to another process that ends up doing something else. The message-passing idiom was far superior to what was available in Linux at the time (pipes and whatnot) because you were able to work with C structs. It was not strictly type safe (as is the case with FoundationDB’s library), but for the 1990s it was pretty great.

The strangest thing about Flow is that its compiler is implemented in C#. So if you decide to use it in your C++ codebase, you now have a C#/.Net dependency, at least at build time.

At first glance, it looks like Rust's channels with a polymorphic type -- when you receive from a channel, you do match and write branches for each variant of the type.

But I wonder if this can be a better abstraction than async. (And whether I can build something like this in existing Rust.)

FoundationDB is awesome testing wise as they have deterministic simulation testing [1] that can simulate distributed and operating system failures.

> We wanted FoundationDB to survive failures of machines, networks, disks, clocks, racks, data centers, file systems, etc., so we created a simulation framework closely tied to Flow. By replacing physical interfaces with shims, replacing the main epoll-based run loop with a time-based simulation, and running multiple logical processes as concurrent Flow Actors, Simulation is able to conduct a deterministic simulation of an entire FoundationDB cluster within a single-thread! Even better, we are able to execute this simulation in a deterministic way, enabling us to reproduce problems and add instrumentation ex post facto. This incredible capability enabled us to build FoundationDB exclusively in simulation for the first 18 months and ensure exceptional fault tolerance long before it sent its first real network packet. For a database with as strong a contract as the FoundationDB, testing is crucial, and over the years we have run the equivalent of a trillion CPU-hours of simulated stress testing.

[1]https://pierrezemb.fr/posts/notes-about-foundationdb/#simula...

iirc there was a ticket/doc about FoundationDB deprecating usage of this and moving to C++ coroutines.