There is little information in this interview about why they chose Haskell except the general notion that they liked it and maybe that it was faster than Python for their particular task. (I say "maybe", because rewrites generally tend to be faster, since you understand the domain much better.) Needless to say, there are many languages out there that are faster than Python. An obvious question should have been "why Haskell instead of C#/F#/Go/Rust, all of which can be made very performant and have better tooling". For that matter, why not Pharo? Or D? Or Factor? Again, the article hasn't really identified any specifics except "we like it" and "there is a university that teaches Haskell nearby".
I find such articles (and HN gets a lot of them) vaguely disturbing. They are PR pieces rather than engineering material written to influence rather than inform.
Check out the hyperlink in that paragraph to the original blogpost for some more background. But I don't think it will be more satisfying as it was still a rather arbitrary choice I will admit (https://www.channable.com/tech/how-we-secretly-introduced-ha...)
The answer mostly is: Because I liked Haskell and knew it well; and I and a colleague wanted wanted to rewrite the job scheduling system and just picked it. But as soon as we started on the project we were extremely productive and were able to launch a proof of concept within days. That really got us excited and showed us a lot of potential in continuing with this approach. Especially things like QuickCheck and testing of pure functions allowed us to write code quickly and correctly with ease.
Also most developers (and also leadership) in our team at the time already followed 1 or maybe even multiple university courses involving Haskell so we had quite a bit of 'hidden' expertise.
For the next project; the API gateway; I honestly felt it was an even better fit. Haskell's Web Application Interface and its ecosystem of middleware is top notch and makes it really easy to write very performant web proxies and servers. Though if I'd have to make the same decision today I'd probably pick Go over Haskell given Go has an even wider ecosystem of middleware; and has a way stronger story surrounding cryptography in which Haskell is severely lacking
Working on that API gateway with you was a lot of fun :)
To be fair, we did run into some issues with the GHC garbage collector performance initially. That took some time to figure out and wasn't the easiest thing ever. Like all tools, there are rough edges sometimes.
I still maintain that the Haskell we wrote at the time was pretty cheap in terms of operational load / bugs to fix (especially compared to the systems that they replaced). When I was back at the office for a reunion, I heard that things were still pretty nice in this respect, but maybe someone still at Channable can chime in with more recent stories! (Or complain to me about the code I wrote back then)
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.
Choice of language is never purely technical because almost all popular ones are good enough for most use cases. So the choice becomes down to preference and experience on behalf of the engineers.
All tech choices are in reality based on the whims of the developers who make the decision. I see developers make so called “rational” decisions all the time but other developers in the same situation would make very different “rational” decisions. The reason is because different developers value things differently and no amount of “rational” decision making can change that. It’s exactly the same reason why we have politics. People value different things and no “rational” algorithm can fix that.
I find such articles (and HN gets a lot of them) vaguely disturbing. They are PR pieces rather than engineering material written to influence rather than inform.