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

501–510 of 555 posts

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

#501

Post by kaba0 »

Rapzid wrote: post #477
avodonosov wrote: post #390

Earlier quoted context omitted.

It's not about feature / promise return types. Consider: int someFunc() { doA(); doB(); byte data[] = readFromSocket(); return doC(data); } int callerFunc() { doX(); System.out.println(someFunc()); doY(); } when we invoke the callerFunc() in a virtual thread, it executes till the potentially blocking socket reading, creates a callback or future -like object containing doC(), System.out.println(), doY() - such object…

Your examples are not functionally equivalent. In the first example the callers of both functions are blocked, in the second the callers are not blocked.

That's the point of Java's virtual threads, basically nothing* will block. The JVM can simply replace a blocking user IO call to an async one under the hood, and in the meanwhile schedule another virtual thread to work. When the IO is ready the suspended thread might get continued.

* FFI has to be pinned, so it will block

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

#502

Post by erik_seaberg »

throwaway74567 wrote: post #146
jpgvm wrote: post #22

Earlier quoted context omitted.

Irrational Fear of Java is one of the most confusing things among startup stage companies.

I see Java/Kotlin as a secret weapon for startups. Too often I read about startups that struggle with immature libraries, smaller eco systems and reinventing basic functionality. Problems that they would not have if they chose a mature technology. These blog posts mentions a company that has to write their own database library, auth services or other basic functionality. Sometimes they fix so many issues with the cor…

I’m reminded of “Fire and Motion:”

> Think of the history of data access strategies to come out of Microsoft. ODBC, RDO, DAO, ADO, OLEDB, now ADO.NET—All New! Are these technological imperatives? The result of an incompetent design group that needs to reinvent data access every goddamn year? (That’s probably it, actually.) But the end result is just cover fire. The competition has no choice but to spend all their time porting and keeping up, time that they can’t spend writing new features.

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

#503

Post by [deleted] »

seti0Cha wrote: post #380
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.

The younger generations of coders are indeed more susceptible to hype, but if you go around dismissing things that are hyped, you're going to miss out on a lot of good things. I've got 15+ years of Java experience, and I think Go is a nice language and has some real strengths. From what I can see, the primary difference with Java isn't the build system or the binaries, it's the decision to strongly favor simplicity a…

[deleted]

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

#504

Post by grishka »

jayd16 wrote: post #478
grishka wrote: post #415

Earlier quoted context omitted.

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.

The key point is concurrent calls. If you're calling out to multiple microservices or what have you (the case where you would actually hit 1M threads in the first place) you'll want to do that in a concurrent way with futures or fork/join and not in a synchronous style. One could argue that automatic promise wrapping and an await keyword ends up giving you cleaner, more simple code (despite the coloring).

The reason I dislike async/await is that the code doesn't clearly express what it actually does. I also dislike asynchronicity built directly into the language. It's just one more piece of context you have to keep track of, and the more context you need in your head to understand the code, the greater the potential for bugs, imo. It is good that Java forces one to explicitly write out their intentions.

I really like the approach Java has chosen: keep the language itself as dumb as possible, but add all the niceties to the standard library and runtime.

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

#505

Post by seti0Cha »

kaba0 wrote: post #426
seti0Cha wrote: post #391

Earlier quoted context omitted.

That's a feature not a bug. Go intentionally forgoes abstractions of that sort. I personally prefer well written Java exception handling, but often Java exception handling code is a bolted on afterthought. Go's approach is to make error handling something you have to think about for virtually every line of code, rather than a superstructure built around the code. This can feel slow and painful to write, but it guides…

> Go's approach is to make error handling something you have to think about for virtually every line of code But that doesn’t work, and you can’t handle every error at the place of its origin.

Seems to me like it does work, based on many successful projects using it. There's nothing that forces you to handle the error at the place of origin, you can pass it on like you do with exceptions. You just can't bubble it up multiple levels.

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

#506

Post by seti0Cha »

kaba0 wrote: post #378
seti0Cha wrote: post #362

Earlier quoted context omitted.

I dislike it because of the ultra-complex build system that over-ambitious devops engineers ended up building in my shop. Our build system was the hardest part of our code base to reason about, which is pretty screwed up.

Well, that’s on them — were they developers in any language they could have also made a mess there. I have seen my fair share of random custom maven plugins as well, which have more bugs than features.

Perl programmers have been making that same argument for literally decades.

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

#507

Post by seti0Cha »

tsss wrote: post #490
seti0Cha wrote: post #380

Earlier quoted context omitted.

The younger generations of coders are indeed more susceptible to hype, but if you go around dismissing things that are hyped, you're going to miss out on a lot of good things. I've got 15+ years of Java experience, and I think Go is a nice language and has some real strengths. From what I can see, the primary difference with Java isn't the build system or the binaries, it's the decision to strongly favor simplicity a…

I'm dismissing it because it's dumb, not because it's hyped. Rust also has a lot of hype and is a much better language. You don't have to like Clojure or Algol or APL or Haskell but these languages at least have some intellectual merit. Golang on the other hand... I'm at a loss for words for how deliberately bad it is.

Intellectual merit turns out not to have much merit when it comes to software ecosystems. "Worse is better" remains in effect.

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

#508

Post by Rapzid »

kaba0 wrote: post #501
Rapzid wrote: post #477

Earlier quoted context omitted.

Your examples are not functionally equivalent. In the first example the callers of both functions are blocked, in the second the callers are not blocked.

That's the point of Java's virtual threads, basically nothing* will block. The JVM can simply replace a blocking user IO call to an async one under the hood, and in the meanwhile schedule another virtual thread to work. When the IO is ready the suspended thread might get continued. * FFI has to be pinned, so it will block

In your example the thread is not blocked but the callers are blocked.

There is more to async/await than simply keeping os threads unblocked, they also provide a mechanism for keeping callers unblocked and synchronizing async contexts(parallel or concurrent).

Is Loom addressing this need? Otherwise it's Goroutines(or any green threading solution) without channels and select. The ecosystem will fracture around solutions to address the boiler and future chaining pains.

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

#509

Post by vips7L »

kaba0 wrote: post #498
vips7L wrote: post #474

Earlier quoted context omitted.

JavaFX is not really a part of Java and isn’t actually shipped with most builds of OpenJdk. Azul Zulu is the only build that I know of that you can get FX built in.

"Fun" fact, there might just come official JDKs that do include javafx.

Is Oracle planning on reinvesting in it? It’s just never appealed to me.

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

#510

Post by pjmlp »

Kwpolska wrote: post #399
pjmlp wrote: post #296

Earlier quoted context omitted.

Workarounds, and still doesn't fix the issues lacking from the company that owns .NET.

What does the company that owns Java offer? Their Java IDE is https://en.wikipedia.org/wiki/JDeveloper and nobody uses that. The latest release came out in 2019. Everyone is using IntelliJ IDEA or perhaps Eclipse. What does the Python core community offer? IDLE is ugly, is barely an IDE, and didn’t have line numbers until a few years ago. Everyone is using PyCharm or VSCode.

IBM also makes Java, it offers Eclipse.

Sun made Java, it offered Netbeans.

As for the Python community, no one expects great tooling from FOSS languages, as you mention everyone is using tooling from two big corporations.

Post reply on HN