[quaunaut]

Honestly? I'd still encourage you to do it. The thing that's nice about Elixir, is that it gives you the tools to screw up and make good on it.

This isn't to say you'll write great Elixir from the beginning. I'm on a codebase now that was from back before the semantics of good Elixir were really well known(2016). It's not uncommon for me every week or two to rewrite a portion of it to look cleaner, and be more performant.

The crazy thing though? Holy shit did it scale. We're doing event processing for an application that is processing nearly 100m events per week. At times, it needs to process 1500 per second. These events need to check the DB multiple times, fan out to multiple services, and make discreet HTTP calls of their own to external servers.

We're still on one box. We still have plenty of the old, harder-to-read, less-performant code. And it still takes under 10 minutes to understand the deepest inner workings of any one feature in the system.

I think you'd be pleasantly surprised.

[jashmatthews]

> The crazy thing though? Holy shit did it scale. We're doing event processing for an application that is processing nearly 100m events per week. At times, it needs to process 1500 per second. These events need to check the DB multiple times, fan out to multiple services, and make discreet HTTP calls of their own to external servers.

Frameworks make a huge difference here rather than language. Phoenix and Ecto have done a really great job with performance.

Ruby will deliver the same performance on a similarly light framework like Sinatra/Roda + Sequel but definitely not Rails.

Once you get a high performance service running on Phoenix + Ecto or Sinatra + Sequel, the gains from moving to compiled languages are a lot smaller unless you invest a huge amount of time in optimisation.