As a person with a lot of .NET experience but has been working on other tech since 6 years, the wow effect I had from using LINQ has never been repeated with anything else.

It felt like magic, maybe too much magic, but so useful nevertheless.

LINQ comes from FP, and was introduced into C# via Haskell, and actually the first version (.NET 3.5) was quite similar to Smalltalk or Common Lisp collections.

Java is getting that power in a different, more orthogonal way, IMO, through Project Babylon: https://openjdk.org/projects/babylon/

Nothing funny there. They shared their opinion as an example. Yes it differs from others, that’s what they was talking about.

Both languages/runtimes are decent, stable and good choices for running production systems.

They have different philosophies though, C# is mostly "give the developer a complex toolkit so they can do whatever they want, but keep the runtime simple", while Java is more like "keep the language as simple as possible, and put new features mostly into the runtime making it more complex, but benefiting even old code".

Async vs virtual threads is a clear example of that. The former makes the language much more complex, and has a huge surface area where it may clash with other features, so a developer has to remember all of these. But it's a simple machinery under the hood.

Meanwhile virtual threads don't change the language at all, it's the same as it was with Threads, but under the hood it is a very complex feature.

And in this particular instance I think it is quite clear cut that Java made the correct decision, for the most common use case of these languages having non-blocking IO "automatically" makes for significantly better user experience.

I do think Java is a fine language but I don't really agree that it looks more simple in any way shape or form.

For things like UI programming where you need a main thread or where you do need a cross language OS thread, I think Java is going to end up more complex. Under the hood it is very complex and that _will_ show itself.

So from my perspective it's not virtual threads, it's virtual threads with structured concurrency vs async/await. When you look at it that way, the comparison of complexity is certainly not seamless or simple.

.NET do what they do because they believe many people like it, and we do what we do because we believe many people like it. Because different developers like different things, we may both be right. The only explanation to why we do what we do is that we believe it works well for us, and we know what everyone should know, which is that what we do can't be universally liked because developers have different preferences.

But that doesn't mean the preferences are equally distributed. Some people liked Betamax's better picture quality while others liked VHS's better recording times, but they didn't do it in equal numbers. And that's what's funny, because there are two languages doing as well as Java or better (one of them is much more popular), and yet what's almost universal is that when people say "Java is worse than X", X is invariably a language that's doing much worse than Java.

I'm not saying that there isn't much to learn from less popular languages, but the claim "Java is consistently making the wrong decisions compared X" doesn't make sense when X is consistently losing to Java.

And I can even give you the secret to our strategy: Make Java the language that people who choose it regret less than people who choose other languages.

I like Java too but this is pure cope. By this logic Python's threading model is the best.

I think you misunderstood my point. I'm not claiming that the most successful products necessarily have all the best features. I am saying that the claim that "team X consistently makes worse decisions than team Y" is hard to support if team X is winning. At least some of their decisions are probably better, and those ones also probably matter more.