Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

infoq.com

Post reply on HN
Print view View original

411–420 of 555 posts

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#411

Post by remon »

Patrol8394 wrote: post #401

I really hope this is the end of complicated reactive frameworks! I love the old blocking spring controller paradigm, thread local and so on. It makes things much easier. Never liked webflux, so complicated and hard to debug. Simple things become a project! Virtual threads to the rescue!

I could not agree more. And that's coming from someone that converted to almost completely async/reactive/flux-y code. Reactive frameworks, almost by necessity, force developers to write less maintainable and readable code (objective fact, not an opinion). Lightweight threading is a significantly better approach to the same problem space.

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#412

Post by isbvhodnvemrwvn »

kasperni wrote: post #173
piokoch wrote: post #70

While this is definitely a good new, we need to be very careful. Why? Those new fancy threads are stored on heap and need to be garbage collected. If you buy into ads and believe that you can create for free millions of threads, then, well, it is not gonna work on production. Because of this server based on new threads does not need to be more performant, Jetty server guys tested this and they were not that happy: ht…

> Those new fancy threads are stored on heap and need to be garbage collected. If you buy into ads and believe that you can create for free millions of threads, then, well, it is not gonna work on production. A typical request easily creates 100's of objects that needs to be garbage collected. Adding a single thread object on top of that means absolutely nothing. And how much garbage to you think reactive frameworks…

How does loom address backpressure?

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#413

Post by hombre_fatal »

doctor_eval wrote: post #347
tsss wrote: post #193

Earlier quoted context omitted.

The younger generation chose Go because they're dumb and fell for the Google marketing hype. Most of them have never even used Java outside of school.

I’m older generation, choose Go because it’s almost universally better for my use cases. But what would I know? I only worked in Java for 20+ years…

This is really some shameful discourse. It's somehow worse than the usual fare of "nobody but beginners/idiots would choose Javascript if they had other options."

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#415

Post by grishka »

jayd16 wrote: post #356
kosolam wrote: post #304

The biggest win by far IMHO is a performant alternative for io intensive applications for async frameworks. Not using an async framework tremendously simplifies your code. Code complexity has an enormous projection on everything else, especially when talking on the business level. First and foremost the cost of development and time to market rises. And then comes the cost of maintenance.

If you want to run concurrent io requests, don't you still need to use an async framework and all the fork/join logic? I suppose the slow and naive way is now easier to let limp along as you won't run out of threads?

JVM itself would do async I/O as needed using whatever API the underlying OS provides. Your own I/O code would be straightforward and synchronous. Nothing will run out of threads.

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#416

Post by plumarr »

DeathArrow wrote: post #374

How are Java virtual threads compared to C# tasks? To me, they seem very similar.

The main benefit of virtual threads it that they release their carrier thread when they call (non native) blocking code, so that other virtual threads can be executed by the same carrier.

I don't think that it's the case for C# task, which also appear to be an higher level construct.

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#417

Post by gschrader »

doctor_eval wrote: post #336
jeroenhd wrote: post #43

Earlier quoted context omitted.

I think Java is an ugly language riddled with roundabout ways of implementing modern features, but I can't fathom why anyone would pick Go over Java. It's slightly worse in almost every way other than writing shell scripts or massively parallel workloads from scratch. In my experience, Java's problem is the same as C++'s when Java began to take over: you usually encounter it in projects stuck at ancient runtime versi…

I wrote Java code for 20+ years and I can tell you exactly why I prefer Go: it produces native binaries. I mean, it’s also less verbose, easier to start a new project, faster to startup, has far fewer configuration knobs, has native dependency management, is far easier to build CI/CD for, compiles more quickly, has very few NPEs gotchas, has value types, and avoids idiomatic boilerplate. Go is far from perfect, but i…

That was one reason I liked Go as well, it's no longer the case though, you can produce native binaries with GraalVM.

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#418

Post by rakoo »

jayd16 wrote: post #384
rakoo wrote: post #212

Earlier quoted context omitted.

> So with this, the last thing Go had going for it over Java is gone, right? Go still has composition over inheritance, which is vastly more flexible. Go favors explicit (verbose copy-paste, redundancy, use stdlib first, libraries second) over implicit (magic annotations, frameworks everywhere) and I like when I can understand what's happening without holding 10 files in my brain context. Go's memory usage doesn't tr…

How does a language favor copy/pasting? Do you mean it makes code reuse harder?

It's not so much part of the language but it's an idiom that is said by one of its authors (https://youtube.com/watch?v=PAAkCSZUG1c&t=9m28s). "Code reuse" always has some non-compressible context: another import with a line in go.mod, another repo and dependency, which doc is going to be on another page/site, etc... It makes sense for big dependencies but not for small ones; the threshold where "small" becomes "big" being of course subjective.

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#419

Post by datadeft »

lenkite wrote: post #346
datadeft wrote: post #334

Earlier quoted context omitted.

I understand that you mastered producing a single binary with your favorite build tool. In my experience if a language does not have an official way to build projects it does end well. Go, Rust and Zig are the prime example that a language should not be separated from its build system. How to produce a single binary: go build cargo build zig build ... org.apache.maven.plugins maven-shade-plugin 3.4.1 package shade cl…

I would like to point out that the language compiler in Rust (rustc) is certainly separated from its modular build system (cargo). Also, how so wonderfully and utterly balanced of you to give an old-school Maven pom.xml file with the maven-shade-plugin and exclusion lists, but omit the Cargo.toml and go.mod files. Also, its as simple in Java as: Gradlefile: apply plugin: 'java' command: gradle build Can you spot the…

> utterly balanced of you to give an old-school Maven pom.xml Sorry I started to use Java a long time ago, not sure what is the "recommended" way of doing things today.

I guess I just need to know which random Github project is the new hotness today that does something that the other languages do out of the box. Thanks for supporting my point of view.

Again, to produce a single binary you need to know/care much less with Zig, Go and Rust than with Java.

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#420

Post by wiseowise »

remon wrote: post #411
Patrol8394 wrote: post #401

I really hope this is the end of complicated reactive frameworks! I love the old blocking spring controller paradigm, thread local and so on. It makes things much easier. Never liked webflux, so complicated and hard to debug. Simple things become a project! Virtual threads to the rescue!

I could not agree more. And that's coming from someone that converted to almost completely async/reactive/flux-y code. Reactive frameworks, almost by necessity, force developers to write less maintainable and readable code (objective fact, not an opinion). Lightweight threading is a significantly better approach to the same problem space.

> objective fact, not an opinion

Got any links where I can read about it?

Post reply on HN