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

311–320 of 555 posts

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

#311

Post by jve »

papercrane wrote: post #270
jve wrote: post #231

Earlier quoted context omitted.

Please help me understand. > To run your Java 8 application, a user needs the Java SE 8 Runtime Environment, which is available from Oracle under the Oracle Technology Network License Agreement for Oracle Java SE, which is free for personal use, development, testing, prototyping and some other important use cases covered in this FAQ https://www.oracle.com/java/technologies/javase/jre8-readme.... Straight from oracle.…

If you want to use the Oracle runtime you need to pay Oracle. But the code itself is open source and you can instead use the Azul, Amazon, Red Hat, BellSoft, etc.. runtimes.

Finally got to the answer. So it IS paid from one particular vendor. I understand there are free options. But that makes it a mine in a field if you are not knowledgable enough. It went this deep into threading to really get an ack that there is a big red O' mine in there.

And there is one piece that wont run without big red O... :(

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

#312

Post by Thaxll »

tsss wrote: post #193
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.

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.

Or maybe they had to use spring / hibernate and ran away.

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

#313

Post by gigatexal »

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…

Can I get a tiny static binary with Java? Nope. Then Go still has legs.

Edit: nvm. You can get static muslc binaries with graal https://www.graalvm.org/22.2/reference-manual/native-image/g...

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

#314

Post by theandrewbailey »

> Platform threads are a one-to-one wrapper over operating system threads, while virtual threads are lightweight implementations provided by the JDK that can run many virtual threads on the same OS thread. Virtual threads offer a more efficient alternative to platform threads, allowing developers to handle a large number of tasks with significantly lower overhead.

> The JDK can now run up to 10,000 concurrent virtual threads on a small number of operating system (OS) threads, as little as one

OK, but why bother with virtual threads if the JVM could just magically decide to run all my virtual threads on one thread? I guess "efficient" in this context doesn't mean "fast". I want my code to run on all available cores, and not be hobbled by a JVM that decided to hate me today.

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

#315

Post by kaba0 »

zapnuk wrote: post #225
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…

A few counterpoints: - Modern Java requires heavy use of Decorators - JSON handling is tiresome - As soon as you are using Spring you aren't actually coding Java anymore - Many mature libraries have dated APIs - Similar functionality is often implemented multiple times in multiple different libraries. Can be confusing if you start out. - Java requires a well configure IDE - However, IDE Support won't matter in a year…

> For the use cases I work on I'd prefer Go for its simplicity

Why don’t “enjoy” the simplicity of assembly then? (Not trying to be sarcastic, just I always felt that this logic is flawed. Especially that java is a very simple language, with very few concepts. If you don’t like, you absolutely don’t have to use metaprogramming like Spring)

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

#317

Post by layer8 »

> However, due to the large number of virtual threads that can be created, developers should use thread-local variables with caution.

What is the problem here? Just the per-virtual-thread memory consumption by the variable when it is used (which would be expected)?

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

#318

Post by kaba0 »

can3p wrote: post #264
kaba0 wrote: post #94

Earlier quoted context omitted.

> Go is very simple language that is just as powerful as Java I don’t think so, Go is very low on expressivity. Generics help, but I don’t see anything like JOOQ for go, just as an example. Also, no real alternative to Java’s stream api, which can at times make code much more readable than the 4 nested for loops with 4 different exits.

https://github.com/volatiletech/sqlboiler

Having looked at the docs, it seems to be full of stringly-typed parameters.

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

#319

Post by jononomo »

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 use an async framework without sacrificing simplicity, look into Elixir/Erlang and the BEAM.

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

#320

Post by kaba0 »

impulser_ wrote: post #227
surfsvammel wrote: post #64

Earlier quoted context omitted.

It’s not hard to find people who want to write Java. I do it all the time. We have been hiring and writing Java code for fifteen years and have not seen a decline in the interest.

I'm not talking about people that have been writing Java for years. I'm talking about new programmers. If you asked a new programmer out of college which job they would rather have I job programming Go applications or Java. I would bet 90% of them would pick Go.

And they will agains say the current hyped language a year later. It’s almost like we shouldn’t really cater to “new programmers out of college”.
Post reply on HN