Github would not have been the same in any of those. They really took to some of the Rails concepts - a lot better than most Rails companies - and it shows in their product (routing, object structures, etc)

So your claim is you could not create the same user experience in any language that is jitted or compiled?

I can't really take that seriously.

Sure, in retrospect you could create the same thing. It's just various text processing at the end of the day. What I'm claiming is that their choice of Rails led to certain choices which were really transparent throughout the product and are still there. It would've grown to be something totally different on another technology, so I don't think it's fair to just look at cost and performance. They did many things "the Rails way"

If they'd used Java they would still be working on the prototype.

I've seen quite a few attempts to measure productivity differences between different languages and there is not a consistent win being shown by dynamic languages in general. Perhaps ruby on rails is especially productive for the web, and maybe especially so when github.com launched, but there are lots of options now with similar productivity and 1 or 2 orders of magnitude better performance.

Rails is optimized for small teams to ship code to multiple platforms. When I visit indiehackers and see people posting about their struggles creating a page to update user profiles and the associated back end code - it's not hard to see why it's more productive. There is very little in the way of boilerplate or BS.

There is nothing out there that has anything close to the productivity of rails. Not that there can't be; it's just not a mindset/approach the industry has embraced.

I agree. Something seemingly comparable like Python/Django for instance cannot compare with Rails with regards to productivity. There was (and still is) Meteor.js though, but adpotion stagnated for several reasons.

Java is very verbouse, that's why I picked on it. You would simply have to write a lot more LOC, which would take more time, be more code to maintain, and so on. It's not a matter of static vs. dynamic, Haskell for instance is probably at least as succinct as Ruby (though I doubt you'll find a Hasekll web framework as productive as Rails).

As a Java dev I would say you'll spent more time on restarting and redeploying your app, especially if it's quite big.

I never get this argument. With current state of IDEs, there is maybe more LOC in the end but many of those lines are written for you and if you know your way around, it is actually very fast to write Java.

It's not the time it takes to write the code I'm concerned about. With more LOC per feature there is more code to maintain, there are probably more bugs, and there is more code one has to comprehend to understand what the system does. That has a significant cost.

Imagine having a state of the art IDE and a succinct language! Something like Smalltalk.

Isn’t Ruby Jitted now?

Ruby 2.6, which will be released in December (there are release candidates out now), contains method based jit infrastructure, but at least as of a few months ago the optimizations were still fairly limited and had not yet overcome the overhead of jitting.