| I'll provide the short version, and will encourage the exchange team to do a proper write-up once they feel ready for it. But to provide proper context, keep in mind that everything below is considered with a trading exchange in mind. Distilled down to bullet point material, the change is driven by: - language ecosystem; support libraries for Erlang are, regrettably, not that well maintained - familiarity; the team maintaining and improving the exchange stack are not Erlang experts but know C++ pretty well - hiring pool; finding good engineers who know Erlang is impressively hard. Intersection with engineers who have been exposed to financial exchanges is ... well. - performance; as I've been explained to, the underlying data structures in Erlang are designed for maximum concurrency and share-nothing model (the Actor pattern in its pure form). These impose constraints that happen to hit the hot paths pretty hard. And related to that... - memory model properties; exchanges rely on data structures whose critical paths cannot avoid invasive operations. Routinely working around your runtime's central assumptions is not exactly a best practice, regardless of the language used. I will let our exchange team tell the complete back story, in their own style and with their view from the trenches. Known interest probably helps. |