Would you choose the Microsoft stack today if starting greenfield?
Serious question.
Outside government or heavily regulated enterprise, what is Microsoft’s core value prop in 2026?
It feels like a lot of adoption is inherited — contracts, compliance, enterprise trust, existing org gravity. Not necessarily technical preference.
If you were starting from scratch today with no legacy, no E5 contracts, no sunk cost — how many teams would actually choose the full MS stack over best-of-breed tools?
Curious what people here have actually chosen in greenfield builds.
21 comments
[ 2.8 ms ] story [ 54.0 ms ] threadThat said, if I'm making something new, I never go with an MS stack. I just wish I had some Powershell type options in Linux from time to time.
Of course, some potential clients demand MS based solutions. I simply decline those contracts and ring them up 12-18 months later to see if the CTO/CIO has been replaced.
If talking about non-web desktop/mobile software, the big issue comes down to GUI framework. Maui is optimized for mobile, Avalonia is superior on desktop. But other than that, thanks to the baked-in runtime it is becoming trivial to build a single GUI program and have it just run anywhere without significant rework.
Plus, C# has become an absolute pleasure to work with, and makes Java look practically obsolete. Hell, Java had to roll back its own implementation of string interpolation in 2024 because they just couldn’t make it work. C#? Working beautifully since 2015, and improved several times to even greater effect.
And if C#’s functional programming rustles your jimmies, you can easily use F# in the same project without complaint.
Finally, while Blazor webassembly might not be entirely ready for world+dog prime time just yet, it works great in an intranet where thick pipes are guaranteed, allowing me to give a hearty middle finger to everything JavaScript.
Honestly, while I will always evaluate every project to ensure that the programming platform is the best one possible, and have chosen other languages for good reasoning plenty of times. But anything which falls in the “anything will work well enough, generally speaking” bin has me reaching for DotNet almost every time.
I would personally chose it over Java, and I think it is more "batteries included" than Go.
If you need to write a business/web application that is fairly easy to maintain and has good performance, yes I would pick C#.
Also, while functional programming etc is possible in C#, all the code I've seen has been very Object-Oriented. Classes for days. Dependency injection, factories, and other "Design Patterns" aplently.
Obviously with Python or Node.js you'll likely have an easier time getting off the ground but the performance will be worse (if that matters)
source: SWE manager at MSFT, mostly C# stuff. 10+ YOE with other languages prior to joining
In the enterprise world, dotnet with c# is one of the best choices, although recently I've been doing a lot of logic just with python running on serverless functions.
If your target users live in Microsoft 365 + Azure AD, the integration advantages of the MS stack are hard to ignore regardless of technical preference. Same goes for teams deep in the Google Workspace or Atlassian ecosystem.
For our greenfield project we went with Kotlin/Spring + Next.js on the basis that most of our target customers use Jira+Confluence, so Atlassian ecosystem familiarity mattered more than stack choice itself.
Generally, I'd avoid using legacy DotNet and Windows servers for anything I care about. But the reality is that you often can't, outside of the startup space.
I even occasionally use DotNet on Linux and it's very good. I get the sense that the tier 1 platform for DotNet (non-legacy) is Linux, as far as Microsoft engineers are concerned.
If you're deploying applications to desktop/laptop, Microsoft stack seems like the biggest market share by a lot.
Anything else, probably not. Microsoft may have advantages in servers, or at least they have had some in the past: my go to example is Receive Side Scaling [1] was originated at Microsoft and is amazing in some use cases. But those advantages most likely aren't big enough to justify the hassle of wrangling and paying for licenses. Running your servers on open source software makes everything easier.
[1] https://learn.microsoft.com/en-us/windows-hardware/drivers/n...
The more interesting question might be: how well does your architecture handle having both? Teams that go all-in on one stack often find themselves 3-5 years later integrating with a Java service they inherited through an acquisition, or needing a .NET library that doesn't have a JVM equivalent.
To actually answer the question though: C# and .NET in 2026 are genuinely excellent. The language has evolved faster than Java in many ways (records, pattern matching, LINQ). But Java 21+ has closed the gap significantly with virtual threads, sealed classes, and the continued investment in GraalVM. For a greenfield project, the honest answer is both are fine choices — your team's familiarity matters more than language features at this point.
What I wouldn't do is pick a stack purely based on cloud vendor lock-in. That's the one decision that actually limits your future options.
.NET 9's improvements to Native AOT, Dynamic PGO, and container support have made it a genuinely competitive backend choice on its own merits. But the strongest real-world argument for choosing .NET is when you already have Java in the mix and need both to coexist. The tooling for bridging the two ecosystems has matured significantly — shared memory bridges can do sub-millisecond cross-runtime calls, and both Java 21's virtual threads and .NET's async model handle high-concurrency integration well.
If you're truly greenfield with no constraints, pick whichever ecosystem your team knows best. The performance gap between .NET and JVM stacks is negligible in 2026. But if there's even a chance you'll need to integrate with Java libraries or services later, having .NET in the picture gives you options that Go/Rust/Node don't offer as smoothly.