Here are my guesses (in addition to your points): - Until late in it's lifecycle, .net runtime performance was worse than JVM. - Also, the Windows TCP stack,

Here are my guesses (in addition to your points): - Until late in it's lifecycle, .net runtime performance was worse than JVM. - Also, the Windows TCP stack, re-architected with Vista, had severe latency issues, which probably led to wholesale abandonment of that platform for low-latency applications. Some of these problems were fixed in Windows 8, but it was probably too late by then. (These two points are based on my own experience with Windows/CLR/JVM in the mid/late 2000s and some anecdotes I heard second-hand. So I can't really cite any public sources for them) I'm sure the fact that you can customize Linux to the extreme and the lack of .Net on Linux in those days probably had a lot to do with the choice of Java, in addition to the above. However, based on my reading of blogs like Mechanical Sympathy [1] a while ago (~8-10 years), there does seem to have been some demand for .Net-based solutions in the HFT space. They had code for both Java and C# in their public code. [1]https://mechanical-sympathy.blogspot.com/ https://mechanical-sympathy.blogspot.com/