> if you get far enough and need to scale
Alright -- I'll bite.
Rarely anyone "needs to scale." Plenty of $1B businesses can succeed on a fistful of c4.large's running Ruby on Rails. The same Ruby on Rails that ran their MVP. Scaling via language change isn't the path to victory, unless you picked a language that was poorly suited to your domain to begin with.
Too many companies end up following this cargo-cult advice, and spend more time grappling with their tools than innovating. Because "concurrency." Someday.
Optimizing your choice of language for anything other than a linear relationship between Real Complexity and Implementation Time is a fool's errand and a fiduciary travesty.
In all fairness, Elixir/Phoenix could become as well-learned as Ruby on Rails. We'll end up in a best-of-both-worlds scenario. And at that point, I'll happily eat my words.
But in the meantime, solve your "scaling" problems by measuring and optimizing, instead of re-writing your app in the flavor-of-the-week.
Alright -- I'll bite.
Rarely anyone "needs to scale." Plenty of $1B businesses can succeed on a fistful of c4.large's running Ruby on Rails. The same Ruby on Rails that ran their MVP. Scaling via language change isn't the path to victory, unless you picked a language that was poorly suited to your domain to begin with.
Too many companies end up following this cargo-cult advice, and spend more time grappling with their tools than innovating. Because "concurrency." Someday.
Optimizing your choice of language for anything other than a linear relationship between Real Complexity and Implementation Time is a fool's errand and a fiduciary travesty.
In all fairness, Elixir/Phoenix could become as well-learned as Ruby on Rails. We'll end up in a best-of-both-worlds scenario. And at that point, I'll happily eat my words.
But in the meantime, solve your "scaling" problems by measuring and optimizing, instead of re-writing your app in the flavor-of-the-week.