Suitability of Elixir to math-oriented apps

Elixir, like Java and other systems, complies down to a byte code that runs on a virtual machine. As such low level operations like floating point math usually go through a level or two of indirection. My understanding is that Elixir, Erlang, and their peers may not be the most performant option for number-intensive calculations.

What Elixir and Erlang thrive at is parallelism. In the case of Big Data applications you typically see gains from that kind of parallelism. Running really intensive calculations may not be a forte, but running a bunch of them at the same time could be a win.

Thanks @easco. This is helpful.

I’m not sure if a Mint-like app is considered math intensive or not; but with multiple simultaneous users each viewing scenarios based on on their unique data sets, it’s possible that the app may benefit from Erlang’s multi-threaded/parallel processing capabilities.

I think the math can be characterized as mostly arithmetic and time value of money operations applied to tables/arrays of data up to 1000x1000.

I suspect there is a threshold of math/computation-intensivity where Erlang is not well suited. I’m trying to get a working sense of that threshold, and an appreciation of the classes of apps that fall beyond that threshold.

Thanks again for your comments!

For something like Mint Elixir is going to be totally fine the number crunching is least intensive of the tasks you will have to perform, polling all the APIs for transaction data and rendering out interfaces will be much higher % of your workload.

I don’t know what a mint-like app is. But concerning number-crunching: you can call modules written in languages suited for that from elixir. For example: I call R modules using Rserve (Rserve - Binary R server - RForge.net) using erlang libraries (GitHub - del/erserve: Erlang/Rserve communication interface · GitHub GitHub - del/erserve_pool: Connection pooling for erserve, the Erlang/Rserve interface. · GitHub). So you can combine the strengths of different languages.

Thanks @andre1sk. That’s what I thought; but needed validation absent any calibration of what math/computationally-intensive means in the Elixir context.

Thanks for the insight and example @StefanHoutzager.

Mint.com is a web based budgeting and personal finance tracking application that was acquired by Intuit a few years ago. Mint is the equivalent of Quicken on the web but better and more user friendly.

The target app I’m evaluating Elixr/Phoenix for is not as robust as Mint but does provide basic budgeting, personal finance tracking, analysis and heavy use of graphs to provide guidance.

My thinking is to use Elixr/Phoenix for the backend (database, analytics and preparation of graphing-ready results datasets, API, etc.) plus something like React for the front end (user interaction and reports rendering, etc.).

Thoughts?

When we say Elixir may not be suited to do number crunching, we are usually thinking a bit beyond analytics, averages, medians, etc. Because it is not necessarily the mathematical processing that hurts but rather the lack of support for large mutable data structures that would allow us to do implement things like image processing or support vector machines efficiently.

For example, think how you would implement a 100x100 matrix in Elixir and how much copying you would need to do to change a single {x,y} pair using immutable data structures. If you need performance, your best bet is ETS or falling back to C (which is what many languages do anyway).

If you are worried about analytics on something like Mint, Elixir/Phoenix should be fine.

Thanks Jose!

I really appreciate you taking the time to provide such an informative response. I am still learning Elixir syntax and features (before tackling Phoenix) and will add ETS and incorporating C libraries into Elixir/Erlang to my reading list. Can you suggest an Erlang/Elixir finance library or point me in a fruitful direction?

Thanks again!

For numerical computing f.e. R enables people to be more productive (higher level language) than C. R itself is written mostly in C iirc. Small sideremark.

Are you agreeing or disagreeing with what Jose said? By “fallback to C” I took Jose to simply mean that most languages end up using C anyway when needing to write optimal number crunching code. R is a good example of precisely that phenomenon.