I am really confused by this comment. "Companies leveraging a quick to develop in, batteries included framework, with really poor performance, beat out companies using highly performant but less quick to develop in languages/frameworks, is reason why I'm suspect about a quick to develop in, batteries included framework that also prioritizes real time communication, with quite solid performance, and really predictable latencies".
I mean...the argument about "the hassle of training and hiring in a whole new language" applied just as much when Rails took off. While Ruby had been around since the mid-90s, it was definitely an esoteric language for the decade or so prior to Rails.
Will Phoenix penetrate as broadly as Rails? Probably not, since Rails already exists, and now benefits from having a lot of people who know it. But being able to reduce hardware costs by 90% while giving up little of the flexibility, and bundling in a lot of real time features can be quite compelling; we'll just have to see.
I mean...the argument about "the hassle of training and hiring in a whole new language" applied just as much when Rails took off. While Ruby had been around since the mid-90s, it was definitely an esoteric language for the decade or so prior to Rails.
Will Phoenix penetrate as broadly as Rails? Probably not, since Rails already exists, and now benefits from having a lot of people who know it. But being able to reduce hardware costs by 90% while giving up little of the flexibility, and bundling in a lot of real time features can be quite compelling; we'll just have to see.