[dvogel]

One of the biggest issues ruby faces is performance. The productivity of the language is undeniable. That is a big reason start-ups so often choose ruby. Eventually Salesforce or Microsoft acquires these ruby start-ups though that the apps run up against enterprise managers who have traditional baroque "cost optimization" incentives. Very few people, especially managers, are comfortable making the argument that paying for more machines is better than paying for more cheaper devs so you see these successful apps rewritten in java, C#, etc. Someone shows execs a chart with costs per user plummeting (usually with a deceptive Y axis), everyone pats each other on the back, and then they lament not being able to find ruby devs when they acquire the next company. I'm hopeful that ruby can close the perf gap enough to slow/stop this weird cycle.

[kigster]

Ruby's performance as a function of infrastructure cost was largely fixed back with Ruby 2.2. Today it's even faster and uses less memory.

The performance problems were 99% invalid database usage, poor or overly aggressive pre-emptive indexing, or bad active record usage.

Developers lacked education in basic database design, and given rails made it do easy, yes that resulted in a lot of slow code and overloaded RDS instances.

But it was entirely possible to build highly scaling rails apps back in 2012. When I ran Wanelo's engineering team we squeezed 300K+ rpm's on a relatively small cloud foot print. It has since been migrated to Heroku.

[joelbluminator]

> One of the biggest issues ruby faces is performance

You can follow along Shopify's progress with the JIT https://speed.yjit.org/. Seems promising.

[metaltyphoon]

You are saying this as if C# is not a ridiculous productive language.