4 ms·

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 threa

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.

samus 3y ago
Fortunately Virtual Threads have landed, so when the ecosystem finally comes around to adopt it, many things might become faster.
pjmlp 3y ago
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.
- doliveira 3y ago
  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.
  - pjmlp 3y ago
    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.
    - intelVISA 3y ago
      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.
- weinzierl 3y ago
  "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.
  - pjmlp 3y ago
    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/blob/master/AsyncGuidance.md 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.
    - ptx 3y ago
      This seems to be the relevant part of the Q&A: https://youtu.be/H5jI76Fq420?t=2396 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.
the8472 3y ago
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.
cutler 3y ago
Green threads are coming to Java this September so all this will be moot.
- weinzierl 3y ago
  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.

samus 3y ago

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

pjmlp 3y ago

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.

doliveira 3y ago
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.
- pjmlp 3y ago
  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.
  - intelVISA 3y ago
    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.
weinzierl 3y ago
"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.
- pjmlp 3y ago
  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/blob/master/AsyncGuidance.md 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.
  - ptx 3y ago
    This seems to be the relevant part of the Q&A: https://youtu.be/H5jI76Fq420?t=2396 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.

the8472 3y ago

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.

cutler 3y ago

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

weinzierl 3y ago
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.