Java at 30: Interview with James Gosling

For instance, Java introduced the fork/join pool for work stealing and recommended it for short-lived tasks that decomposed into smaller tasks. .NET decided to simply add work-stealing to their global thread pool. The result: sync-over-async code, which is the only way to fold an asynchronous library into a synchronous codebase, frequently results in whole-application deadlocks on .NET, and this issue is well-documented: https://blog.stephencleary.com/2012/07/dont-block-on-async-c...

Notice the solution in this blog is "convert all your sync code to async", which can be infeasible for a large existing codebase.

There are so many other cases like this that I run into. While there have been many mistakes in the Java ecosystem they've mostly been in the library/framework level so it's easier to move on when people finally realize the dead end. However, when you mess up in the standard library, the runtime, or language, it's very hard to fix, and Java seems to have gotten it more right here than anywhere else.

Tell us you don't write any sort of .NET code without telling us so explicitly.

You should pick a platform you have better command of for back-handed comments.

Or at least you should try to do a better job than referencing a post from 13 years ago.

Here's an article from 5 years ago:

https://medium.com/criteo-engineering/net-threadpool-starvat...

But does citing a more-recent article matter to you? Probably not. A source being 13 years old only matters if something relevant has changed since then, and you certainly couldn't be bothered to point out any relevant change to support your otherwise fallacious and misleading comment.

What actually amazes me most about this is that people in .NET seem to want to blame the person writing sync-over-async code like they are doing something wrong, even going so far as to call it an "anti-pattern", when in reality it is the fault of poor decision-making from the .NET team to fold work-stealing into the global thread queue. The red-blue function coloring problem is real, and you can't make it go away by pretending everyone can just rewrite all their existing synchronous code and no other solution is needed.

If all you know is one ecosystem, then it seems you are susceptible to a form of Stockholm syndrome when that ecosystem abuses you.

We're seeing this issue entirely in .NET core. We started on .NET 6, are currently on .NET 8, and will likely migrate to 10 soon after it is released. It's again worth mentioning that you provide zero evidence that .NET 6 solves this problem in any way. Although, as we will see below, it seems like you don't even understand the problem!

> I'm certain you're basing this off of your personal experience from more than a decade ago of some forsaken codebase written in an especially sloppy way.

No, I'm referring to code written recently, at the job I work at now, at which I've been involved in discussions about, and implementations of, workarounds for the issue.

> Moreover, there isn't a single mention that the real way to get into actual deadlock situation is when dealing with applications enriched with synchronization context.

100% false. This deadlock issue has nothing to do with synchronization contexts. Please actually read the 2020 article I linked as it explains the issue much better.

> Pathetic attempt at strawman.

I realize responding to this is to just fight pettiness with more pettiness, but I can't resist. You should probably look up the definition of a strawman argument since you are using the word incorrectly.