Semantics

Over a decade ago I started using Erlang because it could do things nothing else could do.

Sure the Prolog-ugly-as-hell code is something only its creators could love (and me in fact) but its 'brain', i.e. its semantics, operated in an orthogonal way to everything else I had used before.

Java, C# and Python baked up fresh cupcakes with different syntactical sugars, while Erlang served up spicy curry.

If semantics boils down to what a piece of code actually does. Elixir's compiles down into the Erlang virtual machine (EVM). EVM bytecode courses through Elixir's veins and gives it weird and wonderful powers.

Massively Parallel

Elixir's processes use about 1-1.5 KB of memory each.

Which means you can do up to 64 things at the same time on a Commodore 64!

Just kidding. But seriously, that means up to one million concurrent tasks per GB of memory!

Want to keep track of a large portfolio of stocks? Easy. Want to keep track of the whole market? No sweat.

Stable

Elixir systems can achieve nine nines stability. Five nines is about 5 minutes of downtime per year and would be considered extremely good to anyone in the finance industry, right? Nine nines is 31 milliseconds!

How? Massive parallelism also results in massive redundancy.

Think about backing up your desktop. Make one backup, two hard disks have to go down in order to lose your data. How about backing up 10 times and geographically distributing your data?

Redundancy lowers risks.

Distributed

Modern

After reading every book I could get my hands on, Elixir is evidently built by developers and consultants who have seen the good and bad of current in vogue languages and frameworks like Ruby, Python, Rails and Django.

Moreover, whereas Erlang was built to run on telecom networks, Elixir is built to run websites, phone apps and web services. New and exciting stuff.

Elixir comes without all the cruft but with all the experience.

Efficiency

Benchmarking is a minefield, but two aspects give Elixir the edge.

Garbage collection (i.e. sweeping up unused memory) in most languages operates on a program level, because they have shared state.

In Elixir garbage collection works on a process level. Upshot?

When garbage collection kicks off the whole program doesn't get paused.

Also, the ease of concurrency encourages getting the most out of your hardware. Hardware utilisation is one of the biggest topics in large financial deployments.

Software people are continually demanding more hardware as their programs get more computationally intensive.

Yet, when management glance at utilisation of each server the charts invariably show lots of computing power going to waste.

Why? Because utilising multicore systems is surprisingly tricky for C# or Java developers.

Future Proof

When you moved from a single core to dual core and then onto a quad core desktop did you see exponential jumps in performance?

Nope?

Elixir spreads out its millions of processes across every core like soft butter on fresh bread. Multicore is the future and Elixir's natural environment.

One of the few things that's inevitable in financial computing is that some wise guy will need your system to process more data or ask for something more complex.

Rather than re-engineering, Elixir gives us a get out.

Add more hardware, and Elixir's performance will increase almost linearly along with it.