Yeah I guess also depends on the problem space. For example, dedicated threads doing something versus a bunch of short-lived asynchronous tasks that need scheduling anyhow.
If a bunch of tasks need to be schedule best not to have to reinvent the wheel on that if possible.
The management to handle Threading and IO and not get it wrong is pretty high unless you’re using something like Rust because it guarantees you’re safe, vs letting the routine runtime management handle everything for you for free
Agree that the code examples look like communicating sequential processes (CSP) and/or async/await-style concurrency (i.e. co-routines in C++). To me this is not "Actors" at all. Actors don't "wait", they receive and send messages, and optionally specify the behavior for handling the next message.
There is no shared lineage here. Some of the people who worked on sender/receivers indeed also worked at Nvidia on Thrust, which never had anything to do with coroutines.
Because it converts all normal DBA tasks into development tasks. If this fits your org (and at huge scale it is more likely) then that's fine, but for small/mid/growth places that can be a PITA.
There does seem to be more effort going into an SQL layer, but it's very hard to know what the state of layer dev and direction is these days, especially if you're not located near core devs.
Great Q--it's weird that Apple, Snowflake, and the other big contributors have put essentially zero calories into documentation/website/etc.
There has been some movement lately, though. I'm not sure who exactly to thank, but "the community" created a new unofficial resource for getting going with FoundationDB: https://foundationdb.vercel.app/7.3/
21 comments
[ 3.1 ms ] story [ 36.6 ms ] threadFlow: Actor-based language for C++, used by FoundationDB - https://news.ycombinator.com/item?id=46191763 - Dec 2025 (53 comments)
Also how is the supposed Swift rewrite going on?
Why would it be better? It’s pretty easy to set up threads in general.
If a bunch of tasks need to be schedule best not to have to reinvent the wheel on that if possible.
In any case a good concurrency library doesn't need more than C++14.
Naturally I haven't followed them that much, given how far away C++26 is from being usable for portable code.
Compilers are finally getting good enough with C++20 support for updating the default version.
Is Apple responsible for preventing its wider uptake? Or alternative databases stronger?
There does seem to be more effort going into an SQL layer, but it's very hard to know what the state of layer dev and direction is these days, especially if you're not located near core devs.
There has been some movement lately, though. I'm not sure who exactly to thank, but "the community" created a new unofficial resource for getting going with FoundationDB: https://foundationdb.vercel.app/7.3/