This--and by "this" I mean cultural or philosophical differences--is what I feel is ultimately behind the stark performance gulf described in the OP's article.

This--and by "this" I mean cultural or philosophical differences--is what I feel is ultimately behind the stark performance gulf described in the OP's article. I love Microsoft's technologies. I use Windows on my development environment (even though I don't do Windows development; I know, I am crazy). I own a Surface and a Nokia Lumia phone. Nevertheless, I also know that there's nothing absolutely fast about Microsoft's web stack [1]. I suspect what is at play here, instead, is one side being efficient with resources and the other being reckless. My opinion is that some platforms and frameworks come bundled with a set of philosophical characteristics that most practitioners adopt. Some popular open source web frameworks include a poster of Knuth's famous quote about premature optimization and adopters consider that quote to mean more than it does, thereby expressly avoiding spending time thinking about performance because doing so might lead to time spent on optimizing code and that is evil. Further, in our efforts to capture production-grade deployment instructions for many open source frameworks, we were left wanting, often having to turn to community opinion rather than specific instructions. Many frameworks' communities were Balkanized, leading to uncertainty about the best performing production-grade configuration. It's not surprising when systems get built and deployed without any performance benchmarking, let alone tuning. I have no idea what "Charm" was or if it suffered from this sort of thing, but I've seen the described situation before and suspect it's fairly common. Meanwhile, although I've not been a Windows developer, I suspect their culture comes bundled with a modest helping of being mindful of CPU and disk resources and preparation for production deployments. Microsoft is too friendly with corporate IT to leave production deployments a guessing game. Finally, perhaps the OP in particular is just especially careful about performance, perhaps without even consciously making it a priority. Certainly none of us think it should be especially difficult for an m1.large server to process hundreds of thousands of dynamic web requests per day. It's more instructive to me, frankly, that we have come to think that is noteworthy. [1] http://www.techempower.com/benchmarks/ http://www.techempower.com/benchmarks/