While I don't agree with the way he spoke, was C# one of the de facto or explicit in-house languages of the company, and Ruby was not? If so, he may have been r

While I don't agree with the way he spoke, was C# one of the de facto or explicit in-house languages of the company, and Ruby was not? If so, he may have been referring to the fact that the company already had many libraries in C# that you could use. Plus, if C# was one of their areas of expertise, it's typically best to use that as opposed to a new, unfamiliar language unless you're explicitly testing out a new approach. Also, in general, for programming in the large, many experienced programmers, having worked on multiple large-scale software projects, tend to prefer statically-typed languages. We've found by experience that in such large-scale systems, major refactorings are much, much smoother and feasible in statically-typed languages (although unit and integration tests are certainly still needed). And a whole class of errors are eliminated. I don't think RoR is trash, but if you were starting a large program that would be used across multiple departments whose in-house language was C#, it was probably the right call to suggest switching to C#. Please note: I'm not a C# programmer, and have never done any work in C# (although I've worked many dynamically-typed and statically-typed languages, and have a clear preference for the latter for large-scale software projects). So this isn't something I have any personal investment in. Finally, I do get it, working for these types of companies is misery for most programmers. I've worked in such companies. But in this case, the senior may have had a good point.