Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Would you choose the Microsoft stack today if starting greenfield?

news.ycombinator.com

Post reply on HN
Print view View original

21–27 of 27 posts

Re: Would you choose the Microsoft stack today if starting greenfield?

#21

Post by toast0 »

What's the target?

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...

Re: Would you choose the Microsoft stack today if starting greenfield?

#22

Post by mattfrommars »

Tbh, the only thing that sucks about .NET is their package manager or the entire build process. It just feels more fun to write C# then Java but when it comes down to building the application and general work, its absolute pain. Nuget and all. Gradle just works better in comparison.

Re: Would you choose the Microsoft stack today if starting greenfield?

#23

Post by mrsmrtss »

mattfrommars wrote: post #22

Tbh, the only thing that sucks about .NET is their package manager or the entire build process. It just feels more fun to write C# then Java but when it comes down to building the application and general work, its absolute pain. Nuget and all. Gradle just works better in comparison.

Care to elaborate what problems you have with .NET package manager (Nuget) and build process? I think having a single way of doing things a is in itself a big bonus compared to the situation in Java (Maven vs Gradle).

Re: Would you choose the Microsoft stack today if starting greenfield?

#26

Post by jnbridge »

The framing assumes teams make a clean "pick one" choice, but in my experience the reality is messier. Most enterprises I've worked with end up running both .NET and Java — not because anyone planned it, but because acquisitions, third-party dependencies, and different team preferences make it inevitable.

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.

Re: Would you choose the Microsoft stack today if starting greenfield?

#27

Post by jnbridge »

One thing that's undervalued about the MS stack in 2026: the interop story. Many teams don't get to choose one stack — they inherit both Java and .NET from acquisitions, vendor integrations, or just different teams making independent choices over the years.

.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.

Post reply on HN