I don't know if Rails scales to that sort of development, to be honest Waaay off topic, but i wouldn't use the expression "scales to." Asking how to scale Rail

I don't know if Rails scales to that sort of development, to be honest Waaay off topic, but i wouldn't use the expression "scales to." Asking how to scale Rails up to 100 programmers is asking the wrong question. Asking how to maintain the same application with just one team on one continent is the question and Rails might be the answer. Then again, it might not be the answer for your specific company. But that is the question to ask. If you do not quickly clue into the fact that Array#pack was redefined in a file you've never seen before that was committed last Tuesday by your most junior developer in the Seoul office, enjoy spending the next several days going over code you swear looks right looking for the error. Again, you have my sympathies. But Rails is not the answer to this problem and neither is Java. One answer to that question that has worked for others in this situation could be continuous integration. Why didn't your automated tests fail when the dev in Seoul checked his code in? I am not saying Rails is for you, or for anyone with 100 devs on multiple continents. But I do have a little experience with multiple developers on separate continents building C++ and Java applications, and the problem of stopping developers from breaking code was always solved with processes like continuous integration and code reviews and not because of some special property of Java. I like Rails for certain things and not for others. I am not arguing you should use it. But I do feel that the issues you raise are not Java vs. Rails issues but process issues. Java won't solve them for you and neither will Rails.