Flow: Actor-based language for C++, used by FoundationDB
Posted by SchwKatze 1 day ago
Comments
Comment by SoKamil 1 day ago
> 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...
Comment by gioazzi 1 day ago
Comment by menaerus 1 day ago
Comment by ttul 1 day ago
Comment by mrbnprck 1 day ago
Comment by IshKebab 1 day ago
The best system for this I've ever used was Thrift, which properly abstracts data formats, transports and so on.
https://thrift.apache.org/docs/Languages.html
Unfortunately Thrift is a dead (AKA "Apache") project and it doesn't seem like anyone since has tried to do this. It probably didn't help that there are so many gaps in that support matrix. I think "Google have made a thing! Let's blindly use it!" also helped contribute to its downfall, despite Thrift being better than Protobuf (it even supports required fields!).
Actually I just took a look at the Thrift repo and there are a surprising number of commits from a couple of people consistently, so maybe it's not quite as dead as I thought. You never hear about people picking it for new projects though.
Comment by computably 1 day ago
As an interesting historical note, Thrift was inspired by Protobuf.
Comment by mrbnprck 1 day ago
actually never heard of thrift until today, thanks for the insight :)
Comment by p_l 1 day ago
Wanted to do unspeakable and evil things to people responsible to choosing it as well as its authors last time I worked on a project that used Thrift extensively.
Comment by IshKebab 1 day ago
Comment by p_l 23 hours ago
I recall threatening I'll rewrite everything with ONC-RPC out of pure pettiness and wish to see the network stack not go crazy.
Comment by CyberDildonics 19 hours ago
Comment by websiteapi 1 day ago
Comment by CharlesW 1 day ago
Tigris uses it: https://www.tigrisdata.com/blog/building-a-database-using-fo...
A good collection of papers, blog posts, talks, etc.: https://github.com/FoundationDB/awesome-foundationdb
Comment by preetamjinka 1 day ago
This "Who is hiring" post for Tesla mentions FoundationDB [0].
Firebolt [1] uses it.
FoundationDB is used at Datadog [2].
[0] https://news.ycombinator.com/item?id=26306170
[1] https://www.firebolt.io/blog/decomposing-firebolt-transactio...
Comment by adammarples 1 day ago
Comment by p_l 1 day ago
Comment by throwawaydbb 1 day ago
Comment by dpedu 1 day ago
1: https://apple.github.io/foundationdb/configuration.html#choo...
Comment by quettabit 1 day ago
Comment by adobrawy 1 day ago
Comment by ghc 1 day ago
I've never spent less time thinking about a data store that I use daily.
Comment by arohner 1 day ago
Comment by nish__ 1 day ago
Comment by mannyv 1 day ago
Comment by otabdeveloper4 1 day ago
Comment by jjtheblunt 1 day ago
Comment by otabdeveloper4 1 day ago
("Legacy" products have a negative growth rate.)
Comment by boris 1 day ago
Comment by boxfire 1 day ago
Comment by whizzter 1 day ago
Comment by jermaustin1 1 day ago
Comment by atn34 1 day ago
Comment by rdtsc 1 day ago
Comment by jeffbee 1 day ago
Comment by culebron21 1 day ago
But I wonder if this can be a better abstraction than async. (And whether I can build something like this in existing Rust.)
Comment by pmarreck 1 day ago
Comment by yetihehe 1 day ago
This is more node.js-like communication than erlang.
Comment by jacquesm 1 day ago
Comment by voidmain 1 day ago
Comment by junon 1 day ago
Comment by thesz 1 day ago
BTW, Erlang does not implement CSP fully. Its' interprocess communication is TCP based in general case and because of this is faulty.
Comment by yetihehe 1 day ago
> Its' interprocess communication is TCP based in general case and because of this is faulty.
What? It's faulty because of TCP? No, in Erlang it is assumed that communication can be faulty for a lot of reasons, so you have to program to deal with that and the standard library gives you tools to deal with this.
Comment by hawk_ 1 day ago
Comment by srinikhilr 1 day ago
Comment by maxmcd 1 day ago
Comment by thisisauserid 1 day ago
Comment by Hayvok 1 day ago