> Don't Do That. That's exactly what dirty schedulers were made for - run longer blocking C code but without having to do the extra thread + queue bits yoursel

> Don't Do That. That's exactly what dirty schedulers were made for - run longer blocking C code but without having to do the extra thread + queue bits yourself. > is not possible to just make up for slow code by bringing in a lot of CPUs. It entirely depends on what you are doing. So number crunching could be a small part amongst lots of protocol parsing and binary matching and sending to different backends and so on. Rarely it is just purely a simple executable that runs and multiplies a matrix and exits. In that context it could make sense to start with Erlang and then do dirty scheduler or an drivers or such for number crunching.