> why Haskell instead of C#/F#/Go/Rust
Keep in mind that this was 2016. Rust was a lot more niche back then, much of the tooling that we have today didn’t exist yet, and nobody was seriously using it in production; encoding_rs landed in Firefox in September 2017. Go only gained generics this year, and as for C#/F#, Channable runs and develops on Linux. .NET Core was only a few months old back then. The more serious contender was Scala, which is what the feed processing system was written in at the time.
A big reason for Haskell was that Arian is very skilled in it and we both liked it. But Haskell genuinely was a good choice for a domain-specific scheduler, because you can really concisely and almost declaratively express the core logic. Also, testing with QuickCheck is great (and Hspec, and testing pure functions in general). The application is written with a pure event loop at the core (it doesn’t do any IO inside the loop), which is something that is very natural in Haskell, but difficult to do in other languages unless you are extremely disciplined about it. That in turn makes it possible to very easily and quickly test all kinds of rare corner cases by just writing down a state value, listing events, and an expected final state. We also had QuickCheck synthesize events and test our invariants. Also, what is really nice to do in a GC’d language with persistent data structures where you need an http API, is to have one event loop that publishes a new state to an MVar after every iteration, and make the http handler sample the current value and work with that. That way you can avoid locks so reads from the API never block, and readers don’t block state updates. STM in Haskell makes this a breeze. It is possible to apply this approach in Rust (and I often do because it’s much easier to reason about than locks), but you end up cloning most things, with persistent data structures you get sharing.