we have some cost efficient way to get license on Microsoft's software like Windows/SQL Server so the cost on software is not an issue, so is there any other concern with Windows-based solution? you mentioned scalability, why this can be an concern? (I assume windows should be able to do whatever linux is able to provide?)
My comment on scalability and Windows is mostly based upon cost as well as most distributed software solutions that are designed to scale are primarily done not on Windows Server but on Linux of some flavor. I am also biased here as I started my career in Unix, although I spent ~8 years doing primarily Microsoft development, and am dedicated to non-microsoft environments now. In some cases when clients have demanded we deploy on Windows some of the software vendors would tell us to significantly increase the number of nodes when running on Microsoft as they found their failure rates were higher, not to mention less resource efficient. Hence cost goes up more and maintenance increases as well. And no, I wouldn't necessarily say Windows is as capable as Linux, but that may just be some bias sneaking in.
If you use windows first tools(IIS, MSSQL), windows is a high performer.
But when you get into distributed software solutions which is mainly what I am working on, it is hard to get the same scalability and functionality out of Windows and Windows native products. For example, a decent messaging system like RabbitMQ either has numerous Windows specific quirks or just won't scale the same requiring more servers to maintain throughput and reliability. Not that it can't be done though, just it really changes the cost factor and the architecture. I can even use SQL Server Broker which is pretty good but again, now the costs go up pretty significantly both in terms of hardware and licensing as you can't just run it on a bunch of commodity/virtual servers full or Ram.
I made a great living off Uncle Bill and the entire Microsoft ecosystem, and I am not a Windows hater (I really like C#), I just recognize for most solutions of scale it doesn't work out without significant cost and tradeoffs.
IMO, Java and the JVM haven't kept up with the pace of change in managed languages/environments. Frankly when .NET was released it was worse than Java and the JVM by far but that is one place Microsoft didn't miss the train and they really turned .NET into a power house. Not saying .NET is perfect, but performance issues, predictability, overhead etc all seem superior to me over the JVM. So in general I avoid writing my own code based upon a JVM centered language as I just don't feel it is nearly as resource efficient or stable. I'll say that the JVM is quite tunable to help mitigate a lot of my complaints but the complexity to do it right exceeds the benefits to me when other languages can do what I want without that extra step needed.
I will say though, that I rely on products that are JVM based and I am open to learning some of the newer languages that also depend on the JVM.
FWIW as well, my core language is C++, has been for my entire career. I still use C/C++ but most code I write is node.js with some growing golang mixed in replacing some of the C++ components we have.
Also, in the end, you will likely change your structure more than once from the first MVP, so I would just make a decision and move forward fast.
As for my opinion. C# is still primarily a Windows environment solution (although its getting better), Golang is a little bit more agnostic but I wouldn't use it anywhere but in a linux environment. My choice would be golang if those were my only two options, mostly because I feel the ecosystem, scaling and cost is better not to be in the Microsoft environment for a startup. However, if you are planning for a Windows based environment, then nothing beats C# IMO.
There are completely valid options that are neither of these languages, nodejs, python or some JVM based languages. I generally avoid the JVM, but that is a personal preference based on my experiences and I recognize plenty of amazing systems are built on JVM based languages all the time.