[fyfy18]

Right, but that's just because those companies have grown to a certain point where it's hard to remain productive with a monolith. If you are starting to have scalability issues it makes sense to rewrite key hot code paths in a language faster than Ruby. That doesn't mean using Rails when they started out was the wrong choice though.

[lmm]

True as far as it goes, but does Rails offer a compelling advantage over higher-performance languages these days, even when starting out? Modern compiled languages have closed the expressiveness gap with Ruby a lot in the last decade or two. E.g. I find I'm just as productive in Scala as in Ruby - if anything more so - so I'd sooner work in Scala/Wicket from day 1 (for use cases where server-side rendering makes sense at all).

(I still have the problem of services growing too large and needing splitting up - though the better isolation of a typed language means that point comes later than it would in Ruby - but it's still nice to be able to split out a module and keep the existing logic implementation rather than having to reimplement entirely)

[joelbluminator]

That's quite hard to measure, how do you measure expressiveness? Or easiness to grasp and get into? Take a CS graduate and have them build an app either with Rails or with Scala, in which stack will they be more productive? That to me will say a lot about a stack's productivity - because quality of documentation, community, stackoverflow questions, 3rd party libraries, general framework architecture etc etc etc..all those things are crucial for productivity.

[lmm]

> That's quite hard to measure, how do you measure expressiveness?

How much code it takes to express a given idea. I was just talking about my subjective impressions, but I'm sure one could count lines of code.

> That to me will say a lot about a stack's productivity - because quality of documentation, community, stackoverflow questions, 3rd party libraries, general framework architecture etc etc etc..all those things are crucial for productivity.

Depends on what kind of organisation you're in; in the kind of environment I'm working in, how easy it is to get up and running for a quick prototype has surprisingly little to do with longer-term productivity. To the extent that you're actually doing novel programming work, how familiar the syntax is and how available libraries are is actually much less important than how clearly you can think about the problem you're actually solving, and I'd far rather be using a cleaner language with fewer frameworks available. Of course in other cases you're doing things that can mostly be solved by frameworks (indeed that's the original idea behind Rails - it started out as a tool to make stamping out repetitive crud apps easier, and it's very good at that) and in that case the availability of those frameworks is the higher priority.