We've banned this account for repeatedly abusing the site guidelines and ignoring our many requests to stop.

https://news.ycombinator.com/item?id=43009383 (Feb 2025)

https://news.ycombinator.com/item?id=43009374 (Feb 2025)

https://news.ycombinator.com/item?id=41121266 (July 2024)

https://news.ycombinator.com/item?id=40979059 (July 2024)

https://news.ycombinator.com/item?id=38623345 (Dec 2023)

HN only works because people are generally respectful and assume good faith. Your post is rather the opposite. I hope that you'll maybe reflect on that.

That's a very harsh reply with zero evidence behind it. Based on your response, I am willing to bet I understand the platform better than you do. And the deadlocks I'm referring to are happening in apps written by other people who've been in the .NET ecosystem exclusively for more than a decade, or even two decades.

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.