6 ms·

Do you think by now C# has left Java behind in features and performance?

by kensai 5mo ago

gfody 5mo ago
more than 10 years ago, yes
- paavohtl 5mo ago
  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.
  - pjmlp 5mo ago
    The difference is BDFL or design by committee, a big difference between both ecosystems.
    - stevefan1999 4mo ago
      Well, what's the difference between a (benefactory or not) dictator or an oligarch?
  - joe_mwangi 5mo ago
    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#.
    - mrsmrtss 5mo ago
      So you try to say that Java gets to be more semantically sound by making bad choices early on? That does not make sense. Those choices are very difficult fix today and many of them can't be fixed. Say what you want but semantically more sound Java won't be. And the boxing with C# unions can and will be addressed later, this was a deliberate choice by the team to bring unions earlier.
      - lostmsu 5mo ago
        > and many of them can't be fixed... And the boxing with C# unions can and will be addressed later No, they won't. C# already got itself into a corner with 32 bit arrays and 32 bit spans. And if unions are introduced as reference only that will never be fixed due to binary compatibility requirement.
        longor1996 5mo ago
        The new C# unions are not reference-only. The attribute/interface allows implementing custom union types by writing `TryGetValue`-methods instead of a single `object? Value {get;}`. The compiler handles this transparently.
deleted 5mo ago
[deleted]
brikym 5mo ago
It always has.
- pjmlp 5mo ago
  Only if we ignore that nowadays JVM does a better job at being the CLR, while Microsoft has forgotten what the C means.
goto11 5mo ago
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.
- littlecranky67 5mo ago
  Java wasn’t open source at all from the beginning.
  - hackerqwe 5mo ago
    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.
  - pjmlp 5mo ago
    No, but it was free/gratis distributed on almost every developer magazine shipping with CDs. One of the reasons why it took off.
- pjmlp 5mo ago
  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.
- pregnenolone 5mo ago
  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.
lenkite 5mo ago
Java Virtual Threads are a superior paradigm to C#'s async/await and function coloring.
- hackerqwe 5mo ago
  Clearly legacy heavy weight threads, virtual or not, are not superior. That’s why Swift, Rust and Typescript all chose async/await for concurrency.
  - lenkite 5mo ago
    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-performance-virtual-threads-and-beyond/ https://javapro.io/2026/03/05/java-25-and-the-new-age-of-per... https://docs.oracle.com/en/java/javase/26/core/virtual-threads.html https://docs.oracle.com/en/java/javase/26/core/virtual-threa...
  - pjmlp 5mo ago
    Except one of the milestones for .NET 11 is to offer similar mechanisms for async/await.
    - biglyburrito 5mo ago
      Link?
      - pjmlp 5mo ago
        It starts with the experiment, https://github.com/dotnet/runtimelab/issues/2398 https://github.com/dotnet/runtimelab/issues/2398 Which ended with, > We have chosen to place the green threads experiment on hold and instead keep improving the existing (async/await) model for developing asynchronous code in .NET. This decision is primarily due to concerns about introducing a new programming model. We can likely provide more value to our users by improving the async model we already have. We will continue to monitor industry trends in this field. Now three years later we have, https://github.com/dotnet/core/blob/main/release-notes/11.0/preview/preview1/runtime.md#runtime-async https://github.com/dotnet/core/blob/main/release-notes/11.0/... > Runtime async is a major runtime feature in .NET 11 that introduces new runtime-level infrastructure for async methods. The goal is to improve tooling and performance for async-heavy codepaths. For more details and to track progress, see the Runtime Async epic issue.
biglyburrito 5mo ago
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.
- joe_mwangi 5mo ago
  Damn. You're old school. Java’s answer is virtual threads, not async/await. The idea is that most server-side IO can stay in direct style enabling blocking-looking code, cheap virtual threads underneath. So you don’t split the whole codebase into sync vs async functions just to avoid blocking OS threads. CompletableFuture and reactive APIs still exist, but Loom reduces the need to use them as the default application model. You can now launch millions of virtual threads to do IO.
  - biglyburrito 4mo ago
    Not so much old school as I was new to JDK, there was no prior art anywhere in our codebase that implemented async (somehow, in 2022), and we started off with JDK 8 (I helped upgrade everything to JDK 17). I REALLY TRIED, OK!? Even when I was building stuff in Kotlin, I couldn't figure out how to make async -- coroutines? RX? I forget already -- work, either. But that was all in the last few months before I left & moved back to the .NET stack.
torginus 5mo ago
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.
- mrsmrtss 5mo ago
  > 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.

Do you think by now C# has left Java behind in features and performance?

by kensai 5mo ago

Do you think by now C# has left Java behind in features and performance?

gfody 5mo ago

more than 10 years ago, yes

paavohtl 5mo ago
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.
- pjmlp 5mo ago
  The difference is BDFL or design by committee, a big difference between both ecosystems.
  - stevefan1999 4mo ago
    Well, what's the difference between a (benefactory or not) dictator or an oligarch?
- joe_mwangi 5mo ago
  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#.
  - mrsmrtss 5mo ago
    So you try to say that Java gets to be more semantically sound by making bad choices early on? That does not make sense. Those choices are very difficult fix today and many of them can't be fixed. Say what you want but semantically more sound Java won't be. And the boxing with C# unions can and will be addressed later, this was a deliberate choice by the team to bring unions earlier.
    - lostmsu 5mo ago
      > and many of them can't be fixed... And the boxing with C# unions can and will be addressed later No, they won't. C# already got itself into a corner with 32 bit arrays and 32 bit spans. And if unions are introduced as reference only that will never be fixed due to binary compatibility requirement.
      - longor1996 5mo ago
        The new C# unions are not reference-only. The attribute/interface allows implementing custom union types by writing `TryGetValue`-methods instead of a single `object? Value {get;}`. The compiler handles this transparently.

deleted 5mo ago

[deleted]

brikym 5mo ago

It always has.

pjmlp 5mo ago
Only if we ignore that nowadays JVM does a better job at being the CLR, while Microsoft has forgotten what the C means.

goto11 5mo ago

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.

littlecranky67 5mo ago
Java wasn’t open source at all from the beginning.
- hackerqwe 5mo ago
  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.
- pjmlp 5mo ago
  No, but it was free/gratis distributed on almost every developer magazine shipping with CDs. One of the reasons why it took off.
pjmlp 5mo ago
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.
pregnenolone 5mo ago
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.

lenkite 5mo ago

Java Virtual Threads are a superior paradigm to C#'s async/await and function coloring.

hackerqwe 5mo ago
Clearly legacy heavy weight threads, virtual or not, are not superior. That’s why Swift, Rust and Typescript all chose async/await for concurrency.
- lenkite 5mo ago
  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-performance-virtual-threads-and-beyond/ https://javapro.io/2026/03/05/java-25-and-the-new-age-of-per... https://docs.oracle.com/en/java/javase/26/core/virtual-threads.html https://docs.oracle.com/en/java/javase/26/core/virtual-threa...
- pjmlp 5mo ago
  Except one of the milestones for .NET 11 is to offer similar mechanisms for async/await.
  - biglyburrito 5mo ago
    Link?
    - pjmlp 5mo ago
      It starts with the experiment, https://github.com/dotnet/runtimelab/issues/2398 https://github.com/dotnet/runtimelab/issues/2398 Which ended with, > We have chosen to place the green threads experiment on hold and instead keep improving the existing (async/await) model for developing asynchronous code in .NET. This decision is primarily due to concerns about introducing a new programming model. We can likely provide more value to our users by improving the async model we already have. We will continue to monitor industry trends in this field. Now three years later we have, https://github.com/dotnet/core/blob/main/release-notes/11.0/preview/preview1/runtime.md#runtime-async https://github.com/dotnet/core/blob/main/release-notes/11.0/... > Runtime async is a major runtime feature in .NET 11 that introduces new runtime-level infrastructure for async methods. The goal is to improve tooling and performance for async-heavy codepaths. For more details and to track progress, see the Runtime Async epic issue.

biglyburrito 5mo ago

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.

joe_mwangi 5mo ago
Damn. You're old school. Java’s answer is virtual threads, not async/await. The idea is that most server-side IO can stay in direct style enabling blocking-looking code, cheap virtual threads underneath. So you don’t split the whole codebase into sync vs async functions just to avoid blocking OS threads. CompletableFuture and reactive APIs still exist, but Loom reduces the need to use them as the default application model. You can now launch millions of virtual threads to do IO.
- biglyburrito 4mo ago
  Not so much old school as I was new to JDK, there was no prior art anywhere in our codebase that implemented async (somehow, in 2022), and we started off with JDK 8 (I helped upgrade everything to JDK 17). I REALLY TRIED, OK!? Even when I was building stuff in Kotlin, I couldn't figure out how to make async -- coroutines? RX? I forget already -- work, either. But that was all in the last few months before I left & moved back to the .NET stack.

torginus 5mo ago

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.

mrsmrtss 5mo ago
> 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.