Better is server bills that are 1/5 the cost, response times that are 3x faster and reduced complexity (no need for cache or background job servers). Don't get me wrong, I still really like and cut my teeth on Ruby, but there are better options for new projects now.

That's better performance, not better. Server bills is a pretty ridiculous metric to judge by; most of our server bills are due to the development kubernetes cluster (!), e.g our developers cost more in servers than our whole production setup. So what - should we go back to a monolith running locally then? Why use Elixir and not Go or Rust then if it's only performance you care about, Go has great concurrency and better general performance.

...and let's not forget that performance could be improved in newer versions so it's a bit tricky to say that A is faster than B, period. Particularly, in this new 3.1 version there is a new JIT (YJIT from Shopify guys) that shows up to 22% on railsbench, 39% on liquid-render. And there are alternative implementations like JRuby or GraalVM with diff. in performance.

That's why I said "other alternatives like Elixir". Go is one. Elixir syntax is comfortable (and productive) for Ruby devs and Phoenix for Rails folks. Use what you like.

> Use what you like

May I? Thanks!

I agree. I love ruby, it's my first love. I'd probably reach for Elixir/Phoenix for any new web app projects though.

At TuneCore we've already replaced a lot of our micro-services with Elixir/Phoenix/Broadway or Go and we've saved quite a bit of cash of server costs.

Wow at TuneCore, really? This is big.

We process billions of dollars a year, with 100s of billions of payments where the average payment is under a dollar.

Right tool for the right job and all that jazz.