Broad proscriptions such as this almost always set my teeth in edge. Sure, meta programming can be a foot gun. But it can also be a way to cleanly achieve specific goals. Metaprogramming should by no means be the first tool reached for, but throwing out the baby with the bath water is an overcorrection.
It also means you are losing out on a significant portion of what makes Ruby Ruby.
If you're going to give rails the credit for the successes, you should probably give it the blame for the failures, too.
I've worked for large companies and startups, and seen rails several times, along with .net, java, scala, php, node and other backbends.
The only thing that mattered in any of their technical successes was the quality of the engineers working on them.
There were certainly minor differences- irritations like compile times or dynamic typing- but the trade offs were 90% of the time personal preference, when compared to the difference made by the strengths of the actual people writing code.
That >75% value created by companies which used Ruby did not create an equivalent debt in another column.
If Ruby-first companies that aren't AirBnb (for example) fail, it's not because AirBnb succeeded. (Perhaps unless your company was called Couch Surfing.)
To protest on the grounds that for some teams, Ruby might be the wrong choice is to willfully ignore the key detail about the whole outlier-degree success thing.
Broad proscriptions such as this almost always set my teeth in edge. Sure, meta programming can be a foot gun. But it can also be a way to cleanly achieve specific goals. Metaprogramming should by no means be the first tool reached for, but throwing out the baby with the bath water is an overcorrection.
It also means you are losing out on a significant portion of what makes Ruby Ruby.