Hacker News Reader

Comment by weinzierl | Hacker News Reader

That Java had concurrency built in from the start is a blessing mostly, but also a bit of a curse. Most of the Java ecosystem is still in the mindset that threads are cheap and firing up a couple more cannot hurt. So we end up with apps that run thousands of threads and this disease is hard to contain.

View on HN

Threads are cheap compared to the process-per-request model that came before. And they're easy to code for, you don't have to worry about blocking code or awaiting your futures in the correct way or things like that. They're not optimal if you want to squeeze lots of concurrent requests into some memory-limited box. But on the other hand even dumb threading offers more throughput than python or node.

Like not everyone toy app isn't going to be the next FAANG, there are plenty of workloads where it hardly matters, while 30 years later it is still a mess in C and C++.

And between C++ and Rust coroutines, still not sure which one I like less.

"And between C++ and Rust coroutines, still not sure which one I like less."

I, myself, am not a Go guy, but I feel it has to be mentioned here. Go's approach might not be as universal as C++'s or Rust's but I think for a large number of use cases it makes sense.

Many that praise async/await in C#, kind of forget it took about 10 years to spread across all the layer of the language and runtime, since it was done via IL rewriting, it caused several issues with F# async tasks, due to the age of the ecosystem plenty of code isn't async/await friendly and needs to be wrapped into Task.Run() or similar.

There is a best practices guideline from one of the ASP.NET architects, https://github.com/davidfowl/AspNetCoreDiagnosticScenarios/b...

During last year they researched adding Go/Java's approach to .NET, but now it is too late. See the ASP.NET Q&A session at BUILD 2023.

This seems to be the relevant part of the Q&A: https://youtu.be/H5jI76Fq420?t=2396

Aside from being too late (already having two models and not wanting to add a third) they also mention that the Go/Java approach adds a performance penalty when calling native APIs.

I thought so too until I got to interact with databases and Big Data tools written in Java. God, what a mess that requires so much upkeeping, more dependency problems than I remember from C++ and probably some orders of magnitude more resources than they should.

Doing code review for C++ code delivered by most well know offshoring companies, versus what they deliver in Java, will help get another point of view.

Thankfully LLMs are becoming a viable, cost-effective, option for stuffing your favorite offshored codebase with even more unmaintainable spaghetti. What a time to be alive.

Fortunately Virtual Threads have landed, so when the ecosystem finally comes around to adopt it, many things might become faster.

Green threads are coming to Java this September so all this will be moot.

I wish, but I'm skeptical. It's not that we don't already have the means to be reasonable with threads. The issue in my opinion is more a mixture of path dependency and a mindset that changes too slowly.

Reply on news.ycombinator.com