I never liked the C#/Java comparison - Java was designed as a much higher level language, and allows reasoning about low level abstractions a lot less, while doing a ton more optimization in the JIT.
For example, GC escape analysis, automatic lock elision, devirtualization, tiered compilation are fairly recent features in C#, and likely not as mature/powerful.
Or C# has generic specialization, so if your generic param is a stuct, you get a separate implementation, while Java generics work via type deletion.
But in C# you have a ton more synchronization primitives, value types, methods are non-virtual by default etc.
This usually means that expertly crafted C# code can be faster than Java (and more importantly, you can trust the compiler to do the right thing), while if you wrote it exactly like Java, you'd probably end up with slower code.
> while if you wrote it exactly like Java, you'd probably end up with slower code.
That's not the case for some time already, at worst you get similar performance with Java and with a little effort you can get significantly better performance.
That used to be the case, but I would argue that C#'s ecosystem is just as competitive now. For our backend tech stack at work, all of our libraries used are open source nugets. Back 15 years ago, paid nugets were definitely more standard.
Language design isn't just about adding every possible feature. For example, someone mentioned operator overloading. As someone who has written a lot of Scala, I think operator overloading would be a very bad feature for an enterprise language like Java which needs to be consistent above all else.
I never understood the obsession some people have with the C# vs Java debate anyway. Generally, both languages are very good at what they do, each having its own set of advantages and disadvantages. Regardless, a developer can pick up the other language with basically no effort.
To the point that after all the drama with J++ that lead to .NET and C# development, Microsoft nowadays is also an OpenJDK contributor with their own distributions, and official developer advocacy channels on YouTube, conferences and devblogs.
Turns out they really want to have plenty of Java development on Azure as well.
And the binaries, the default sdk when using java, i.e. oracle jdk, is still not open source, encumbered with a mine field of legalese. For a long time it also included malware as ask toolbar. Stay away.
I don't get what the big problem is with function coloring. You basically only need async when doing IO, and you had better know when a function does it, or you may have a bad surprise at some point in the future.
That! Okay, in 2026 this could be a LSP feature with some editor fanciness but this is a real benefit. My nitpick is that we do not have a depreciation on the non async ones
Agreed, async function coloring makes for better structured code because it incentivizes keeping IO code near the edges while having a synchronous core.
We are not taking about legacy heavy weight OS/platform threads. But "green" threads managed by the language runtime like Go. Java went the Go/Erlang way.
> Clearly legacy heavy weight threads, virtual or not, are not superior.
Associating virtual threads with "legacy heavy weight threads" is a fundamental misunderstanding
> That’s why Swift, Rust and Typescript all chose async/await for concurrency.
And Java chose to join Team Go/Erlang. At the end of the day, async/await is just syntactic sugar for futures/promises, which are essentially a way out of callback hell.
Besides, Rust and Typescript aren't good examples here: a green-thread scheduler (a runtime component) contradicts Rust's philosophy, while Typescript is inherently constrained by Javascript.
More like 25. C# 1.0 already had capabilities Java developers are still dreaming of, like structs / value types, properties and operator overloading. C# 2.0 in 2005 introduced generics, implemented far more competently than Java ever did.
Notice you point out features that were easy to add during the beginning where there was no concern of backward compatibility? Now that java is porting value classes to mainline and we might have them soon, and planned operator overloading through type class, I believe java approach is making careful design choices that are semantically sound, rather than adding features that create edge cases such as boxing invariants in unions like C#.
Speaking as somebody that spent 2yrs as a full-time Java dev before returning to the Microsoft stack: yes.
Java’s Optional sucks compared to how C# (and Kotlin) implement support for nullable types. C#’s async/await syntax is better than… however the hell Java says to implement asynchronous calls now (Thread? CompletableFuture? idk, I never figured it out). ffs, Java doesn’t even have support for string templates yet — they added it as a JDK preview feature (JDK 21?) and then removed it before final release.
I never liked the C#/Java comparison - Java was designed as a much higher level language, and allows reasoning about low level abstractions a lot less, while doing a ton more optimization in the JIT.
For example, GC escape analysis, automatic lock elision, devirtualization, tiered compilation are fairly recent features in C#, and likely not as mature/powerful.
Or C# has generic specialization, so if your generic param is a stuct, you get a separate implementation, while Java generics work via type deletion.
But in C# you have a ton more synchronization primitives, value types, methods are non-virtual by default etc.
This usually means that expertly crafted C# code can be faster than Java (and more importantly, you can trust the compiler to do the right thing), while if you wrote it exactly like Java, you'd probably end up with slower code.
> while if you wrote it exactly like Java, you'd probably end up with slower code.
That's not the case for some time already, at worst you get similar performance with Java and with a little effort you can get significantly better performance.
C# was always better than Java as a language. The strength of Java is the ecosystem, and Java being open source and cross-platform from the beginning.
That used to be the case, but I would argue that C#'s ecosystem is just as competitive now. For our backend tech stack at work, all of our libraries used are open source nugets. Back 15 years ago, paid nugets were definitely more standard.
Language design isn't just about adding every possible feature. For example, someone mentioned operator overloading. As someone who has written a lot of Scala, I think operator overloading would be a very bad feature for an enterprise language like Java which needs to be consistent above all else. I never understood the obsession some people have with the C# vs Java debate anyway. Generally, both languages are very good at what they do, each having its own set of advantages and disadvantages. Regardless, a developer can pick up the other language with basically no effort.
> I think operator overloading would be a very bad feature for an enterprise language like Java which needs to be consistent above all else.
Operator overloading increases consistency. Instead of having
you have
4 replies →
To the point that after all the drama with J++ that lead to .NET and C# development, Microsoft nowadays is also an OpenJDK contributor with their own distributions, and official developer advocacy channels on YouTube, conferences and devblogs.
Turns out they really want to have plenty of Java development on Azure as well.
Java wasn’t open source at all from the beginning.
And the binaries, the default sdk when using java, i.e. oracle jdk, is still not open source, encumbered with a mine field of legalese. For a long time it also included malware as ask toolbar. Stay away.
No, but it was free/gratis distributed on almost every developer magazine shipping with CDs.
One of the reasons why it took off.
It always has.
Only if we ignore that nowadays JVM does a better job at being the CLR, while Microsoft has forgotten what the C means.
Java Virtual Threads are a superior paradigm to C#'s async/await and function coloring.
I don't get what the big problem is with function coloring. You basically only need async when doing IO, and you had better know when a function does it, or you may have a bad surprise at some point in the future.
That! Okay, in 2026 this could be a LSP feature with some editor fanciness but this is a real benefit. My nitpick is that we do not have a depreciation on the non async ones
Agreed, async function coloring makes for better structured code because it incentivizes keeping IO code near the edges while having a synchronous core.
Clearly legacy heavy weight threads, virtual or not, are not superior. That’s why Swift, Rust and Typescript all chose async/await for concurrency.
We are not taking about legacy heavy weight OS/platform threads. But "green" threads managed by the language runtime like Go. Java went the Go/Erlang way.
https://javapro.io/2026/03/05/java-25-and-the-new-age-of-per...
https://docs.oracle.com/en/java/javase/26/core/virtual-threa...
> Clearly legacy heavy weight threads, virtual or not, are not superior.
Associating virtual threads with "legacy heavy weight threads" is a fundamental misunderstanding
> That’s why Swift, Rust and Typescript all chose async/await for concurrency.
And Java chose to join Team Go/Erlang. At the end of the day, async/await is just syntactic sugar for futures/promises, which are essentially a way out of callback hell.
Besides, Rust and Typescript aren't good examples here: a green-thread scheduler (a runtime component) contradicts Rust's philosophy, while Typescript is inherently constrained by Javascript.
Except one of the milestones for .NET 11 is to offer similar mechanisms for async/await.
2 replies →
Hahahha no. lol just no.
more than 10 years ago, yes
More like 25. C# 1.0 already had capabilities Java developers are still dreaming of, like structs / value types, properties and operator overloading. C# 2.0 in 2005 introduced generics, implemented far more competently than Java ever did.
Notice you point out features that were easy to add during the beginning where there was no concern of backward compatibility? Now that java is porting value classes to mainline and we might have them soon, and planned operator overloading through type class, I believe java approach is making careful design choices that are semantically sound, rather than adding features that create edge cases such as boxing invariants in unions like C#.
2 replies →
The difference is BDFL or design by committee, a big difference between both ecosystems.
Speaking as somebody that spent 2yrs as a full-time Java dev before returning to the Microsoft stack: yes.
Java’s Optional sucks compared to how C# (and Kotlin) implement support for nullable types. C#’s async/await syntax is better than… however the hell Java says to implement asynchronous calls now (Thread? CompletableFuture? idk, I never figured it out). ffs, Java doesn’t even have support for string templates yet — they added it as a JDK preview feature (JDK 21?) and then removed it before final release.