This is a really excellent post. I love love love the sociology of technology. Maintainers of a language implementation would like to have maximum flexibility

This is a really excellent post. I love love love the sociology of technology. Maintainers of a language implementation would like to have maximum flexibility in designing and shipping new features that benefit their users. They don't want to be hamstrung by having to get multiple implementations to agree before they can get a feature out the door. As a case study, look at how glacially slow JavaScript evolution was for many years. And look at how comparatively fast TypeScript evolves. At the same time, alternate implementations can be a signal of the robustness of your language ecosystem, so there is an upside too. And if the alternate implementation is really good (even if just for some subset of users with niche requirements), it can be a real value add for your ecosystem. So if you're a language designer/maintainer, you might not be actively hostile to alternate implementations, but there are downsides. And, for the most part, the feedback you'll get from users will be towards encouraging you to ship new features and evolve the language. You won't get too many people asking you to slow down so that PyPy/IronRuby/LuaJIT/etc. can keep up. For a language consumer, choosing which implementation to build on is often a choice where the biggest priority is safety and stability. No one wants to find themselves sitting on a million-line codebase that happens to subtlely rely on the behavioral quirks of some languishing alternate implementation created by a very bright PhD student who has since moved onto other projects. So there's a very strong positive feedback loop where users tend to go to the most-used implementation, which then encourages other users to go to that implementation, which encourages... The network effects are quite strong. The end result is that unless there are quite strong forces pushing in the other direction, most languages tend towards a single canonical implementation. There's a good argument that that's a good thing: it means that almost all engineering effort put into implementing the language benefits all users instead of it being divided among a number of separate implementations. The downside, of course, is that the implementation can get stuck in a local maximum.