Well, that's the best part; in a very wide gamut of cases, they don't, and since both play nice with compiled languages a scaling up can benefit from both worlds.
I would argue that "engineering" and "scale" are different concerns.
Engineering is about building and maintaining things fit for their purpose.
A bridge that only needs to last for one year is designed very differently than a bridge intended to be used for twenty years.
In the case of software, that means (a) building what your users and business need; (b) designing software that is easy to change; and (c) delivering enough scale to meet your expected needs for the current business cycle.
For a new startup, you can probably get by with a Rails app on a single Digital Ocean droplet, with plans to scale horizontally. For an established business, you might have a large data warehousing operation running custom C++ code across multiple datacenters, of which the web frontend is a tiny (but important) part.
Good software engineering makes the steps between "New Startup" and "Established Business" as painless as possible, with a minimum of additional overhead.
> A bridge that only needs to last for one year is designed very differently than a bridge intended to be used for twenty years.
Yes, but in software, the usual case ends up that the 1 year bridge actually has to become an interstellar spaceship and has to last basically forever.
This happens in other disciplines as well but I have not seen it as extreme as many software projects I saw.
Ruby as a language doesn't. It's more about the ecosystem and the popularity of Ruby comes from the popularity of Ruby on Rails, that is what makes Ruby have an advantage of getting started quickly.