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

141–150 of 555 posts

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

#141

Post by killerstorm »

pdpi wrote: post #107
TheDong wrote: post #10

So with this, the last thing Go had going for it over Java is gone, right? Java has an obviously better type system, while Java originated the billion dollar mistake, Java also at this point has much better practices around handling nulls than Go, Java's jars are more portable than go's binaries, Java's GC performs better, Java has a more mature ecosystem and more libraries... Java has better IDE support and comparab…

Java's GC has better throughput, because Go's GC specifically optimises for latency. This may or may not be the right tradeoff for you specifically, but it is a perfectly reasonable tradeoff. Jars are more portable at the cost of requiring a JVM installed on the target, whereas Go's statically linked binaries and great cross-compilation make portability mostly moot for server applications. Also, with Java 21, the JVM…

JVM has many different GC implementations, some of them are optimized for low latency, and, in fact, come with guarantees.

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

#142

Post by ilamparithi »

Kwpolska wrote: post #32
TheDong wrote: post #10

So with this, the last thing Go had going for it over Java is gone, right? Java has an obviously better type system, while Java originated the billion dollar mistake, Java also at this point has much better practices around handling nulls than Go, Java's jars are more portable than go's binaries, Java's GC performs better, Java has a more mature ecosystem and more libraries... Java has better IDE support and comparab…

I would say that Go's error handling is a billion dollar mistake as well. The JVM is very impressive and a great thing to build upon. The Java standard library is vast and the developers actually care about it (unlike the Python folks, who gave up on having a sane HTTP client library built-in and instead defer to the third-party requests library). The Java language is not as great, lacking some quality-of-life featur…

when it comes to full stack frameworks, Micronaut(https://micronaut.io/) is actually good and pleasant to work with.

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

#143

Post by miohtama »

hintymad wrote: post #13
TheDong wrote: post #10

So with this, the last thing Go had going for it over Java is gone, right? Java has an obviously better type system, while Java originated the billion dollar mistake, Java also at this point has much better practices around handling nulls than Go, Java's jars are more portable than go's binaries, Java's GC performs better, Java has a more mature ecosystem and more libraries... Java has better IDE support and comparab…

My experience in small companies told me that younger generation didn’t choose Go because Go is objectively better than Java, but because they actively hate Java for it being out of fashion.

It's also older generation, those who worked with Java in 00s and 10s and got experienced with Java.

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

#145

Post by jve »

kaba0 wrote: post #98
jve wrote: post #87

Earlier quoted context omitted.

Our employer actively tracks runtime usage and makes sure we have no O in it. > The quantity of licenses is determined by the total number of employees, not the number of employees using the programs https://www.infoworld.com/article/3686611/oracle-per-employe... > Employee for Java SE Universal Subscription: is defined as (i) all of Your full-time, part-time, temporary employees, and (ii) all of the full-time employ…

Are you using Photoshop without a license as well or how is that relevant? This is about Oracle’s JDK you specifically have to install and have a paid license to (actually, they also provide a free version if you stay on the latest LTS release at all times), and is meant mostly for governments and such. Will you uninstal linux because Red Hat has a paid support version as well?

So if i have JDK (Which I must) I do have to buy those licenses.. for all our employees?

> The Java Platform, Standard Edition (Java SE) and Java SE Universal Subscription from Oracle include the Java Development Kit (JDK), and Java Runtime Environment (JRE) https://www.oracle.com/java/technologies/faqs-jsp.html#:~:te....

Do I not need the Java SE subscription to use JRE? Do I not need the Java SE subscription to use JDK?

I have so much questions and because there is even place for questions, I better avoid this thing.

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

#146

Post by throwaway74567 »

jpgvm wrote: post #22
hintymad wrote: post #13

Earlier quoted context omitted.

My experience in small companies told me that younger generation didn’t choose Go because Go is objectively better than Java, but because they actively hate Java for it being out of fashion.

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 core language that they become close partners with the core developers of the programming language. I can't help wonder if the competition also reads the post and just smiles before they go back to actually solving a business problem. To me it's a symptom of choosing the wrong stack, even though working on non-business related problems may be more rewarding to the individual.

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

#147

Post by jillesvangurp »

alkonaut wrote: post #121

How is a system of virtual threads different from typical "a pool of tasks and a pool of threads to perform them on" systems like e.g. the .NET TPL?

Conceptually, these are all variations of the same thing. The difference is in how you use them and how much boiler plate you need to use them.

Funnily enough, the first versions of Java did not support OS threads and only had green threads for a while. Supporting real threads was a big deal at the time as it allowed you to use more than 1 processor. Of course, processors were single core at the time and most computers only had one of those anyway. Java 1.1 laid the foundations for proper multi threading and green thread support was eventually removed with Java 1.3. With Java 1.5 we got the java.concurrent package which enabled doing more complicated things with locks and other synchronization primitives that were a bit less primitive & brittle than using the synchronized & volatile keywords. That includes implementing green threads on top of real threads. Which is what frameworks like vert.x and others have been doing for ages.

So, in a way we're coming full circle here with virtual threads re-using the thread API, which in turn reused the original green thread APIs in Java 1.0.

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

#148

Post by kjto »

spuz wrote: post #130
kjto wrote: post #90

Earlier quoted context omitted.

.net has had this feature for a decade++

What is the virtual thread feature in .NET called? I can't find any information about it.

Tasks, simple intro here https://code-maze.com/csharp-tasks-vs-threads/

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

#149

Post by Kwpolska »

vincnetas wrote: post #138
Kwpolska wrote: post #32

Earlier quoted context omitted.

I would say that Go's error handling is a billion dollar mistake as well. The JVM is very impressive and a great thing to build upon. The Java standard library is vast and the developers actually care about it (unlike the Python folks, who gave up on having a sane HTTP client library built-in and instead defer to the third-party requests library). The Java language is not as great, lacking some quality-of-life featur…

I have my complaints about Spring, but bad docs is definitely not among them. What do you consider a good docs?

Django's docs are great. For Spring, Google tends to bring up random sites with dubious quality content.

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

#150

Post by killerstorm »

alkonaut wrote: post #121

How is a system of virtual threads different from typical "a pool of tasks and a pool of threads to perform them on" systems like e.g. the .NET TPL?

I guess the idea is that you don't have to write tasks explicitly - if you have a sequence of actions you can just write it as a regular code, and the runtime will automatically insert points where your code might be suspended waiting for IO or other threads.
Post reply on HN