It's an invalid argument because not all projects are alike. Facebook and Wikipedia are indeed very successful projects but they have a massive advantage over

It's an invalid argument because not all projects are alike. Facebook and Wikipedia are indeed very successful projects but they have a massive advantage over the types of projects I deal with in enterprise environments. For instance: - technical environment: the Facebook/Wikipedia/generally-any-web-startup architects get to choose their technical environment 100%; in most corporates you need to integrate with legacy applications and databases in a specific environment, often enforced by IT policy, and this imposes significant constraints on which languages will be feasible options - interoperability: for large, modular systems developed by disparate teams over decades with little or no standards or co-ordination, a statically typed language can be absolutely invaluable for ensuring interoperability and discovering usage (documentation is typically non-existent in these environments, as are tests, and the latter is seldom - often impossible - to retrofit); even for new systems, static typing can save a lot of time when developing and integrating new work across large teams, in my opinion - resistance: business and technical knowledge lives in developers who are part of an ancient stack, e.g. Microsoft or Oracle or Borland; switching to PHP or Python or Ruby etc. means convincing these people to learn very different new technologies (good luck - won't happen), figuring out how to interface with legacy stuff using a language outside of the stack, introducing new tool chains, etc.j - time & budget: even if the existing developers are keen to learn, it's tough convincing the project manager you need an extra month to go through the upskilling process and that you need to spend time researching interoperability options, and that inevitably you will run into future issues, etc.; the problem is most projects are run and budgeted for on a local cost benefit analysis and very rarely would the benefit of switching languages for one project be worth it (even though, in the big picture across multiple projects, it may very well be) An observation: whenever this debate comes up on the HN, the proponents of modern, dynamic languages are invariably people working in closed environments where they have the freedom to set standards, do things right from the beginning (coding standards & reviews, tests, documentation) and the ability to make technology selections across the board. Often this freedom is not a characteristic of other environments, and consequently the language used in a one environment may be unsuitable in another.