That is, each part is cut up into a small program, and these are controlled by the Erlang system so it acts like a supervisor of the programs. They are run under some kind of "visor" so their resources are limited to sane values etc.
When the C/C++ program does something bad, the Erlang system is notified of this. It can then take action in order to keep the processing pipeline running.
You could argue that in the current context of containers, this is easy to achieve with them. But I claim writing all of this in a programming language is far more manageable than trying to handle the rate at which the whole container-context is evolving.
Switching to Erlang won't inherently make those issues disappear. Erlang could definitely save you some C/C++ boilerplate code, but if your business logic is still stateful, it's not necessarily going to be easier to implement any of that with Erlang.
Erlang is probably more forgiving on the developers than C/C++ are, but that can be said of many other languages (ie. Python, Java).
If you're looking to pass messages around between processes/threads, there are plenty of libraries you can use today to start refactoring that C/C++ code:
https://www.rabbitmq.com/ (most likely an overkill for the specific use-case you described, will be more relevant in a distributed computing scenario)
Consider a functional programming language with immutability and pattern matching, which should help a lot.
So Erlang then
It doesn't have something like OTP (there are libraries like LWT for concurrency and IPC tho) but allegedly should have good math performances, from what I recall the last time I've played with the "big languages shootout" game...
Erlang itself shield you from actually doing stupid thing and follow the assumptions that BEAM have while running programs.
You're better off choosing a different language. Have Erlang deal with concurrency but don't have it do number crunching.
The language is not designed for number crunching.
 - https://signalvnoise.com/posts/2440-we-all-know-the-saying-i...