WingNews logo WingNews
top | item 44006859

(no title)

PathOfEclipse | 9 months ago

I've been working in .NET/C# for the past few years, and while I'm happy with it, I still think the JVM/Java are the best ecosystem overall I've worked in. It's amazing how many things the Java ecosystem gets right that .NET gets wrong.

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.

discuss

order

MarkSweep|9 months ago

The thread pool starvation problem in .NET is annoying when you encounter it. Personally I have not bumped into since the .NET framework days.

The thread pool implementation has been tweaked over the years to reduce the impact of this problem. The latest tweak that will be in .NET 10:

https://github.com/dotnet/runtime/pull/112796

I’m not sure a thread pool implementation can immune to misuse (many tasks that synchronously block on the completion of other tasks in the pool). All you can do is add more threads or try to be smarter about the order tasks are run. I’m not a thread pool expert, so I might have no idea what I’m talking about.

deepsun|9 months ago

Interesting. I'm not a .Net programmer, but I always thought .Net takes winning approach from Java ecosystem and adopts it. Java approaches/frameworks are kinda pioneering and competing, while .Net follows and grabs the best. So instead of competing approaches/frameworks (like ORMs for example) .Net has only one, the best one, well adopted and used by everyone there.

But reading your message it doesn't sound like it.

neonsunset|9 months ago

[deleted]

andyjohnson0|9 months ago

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.

PathOfEclipse|9 months ago

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.