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.

Thanks! It seems Erlang was not a best choice in the first place, for your project. Yes, please share the complete story when it's written.

curious too