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.
bostik|8 years ago
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.
zura|8 years ago
blah_blah|8 years ago