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

71–80 of 555 posts

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

#71

Post by kaba0 »

mseepgood wrote: post #40
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 has an obviously better type system How does Java have a better type system? Java's generics are unsound, while Go's generics are sound. Java's generics do type erasure, while Go does not. Java's type system is not unified, it does not have a top type (an int is not an Object, int vs. Integer etc.).

Haskell’s type system does type erasure, is it “worse” for that?

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

#72

Post by the_gipsy »

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…

What Go has going is that it's faster and more pleasant to develop in. Yet another bullet-point-feature bolted on only makes the Java ecosystem jungle worse in that aspect.

I find your other points a bit dubious. Java's type system suffers from extreme verbosity and little soundness, and exceptions have not been a successful error-handling story. I don't think you can call a jar that needs a system installation of some specific jre portable - at all. The ecosystem may be huge, but also nightmare in terms of interoperability and support of newer features. IDE click-driven-development is a crutch for the extreme verbosity and complexity of patterns in Java. Compile times are much worse in my limited experience.

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

#73

Post by kjto »

> Virtual threads offer a more efficient alternative to platform threads, allowing developers to handle a large number of tasks with significantly lower overhead.

they should have just called them "Tasks" leaving the already overloaded term "virtual" out of the conversation.

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

#74

Post by surfsvammel »

Every time something show up about anything related to Java, the discussions turn to this flame war about what language are better or worse than Java. Why can’t we just discuss the article at hand?

In this case, I’d love to hear more from experienced Java developers, with existing code-bases, who have tested these new virtual threads out.

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

#75

Post by Dinux »

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…

Are you kidding me? If it wasn't for large enterprise corporations Java would be long dead by now. Ever since Oracle took over Java has seen almost no improvements. The logical comparison is Java to C#, and C# has seen _a lot_ of improvement over the last 7 years or so. It just so happens that Java is sometimes unavoidable for Android development were Kotlin is not (yet) possible.

Java is, like its large corporate users, stuck in the past.

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

#76

Post by pjmlp »

impulser_ wrote: post #58
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 started with Java and I will most likely never go back. I mainly use Go now. People want to learn/write Go. It's hard to find anyone that wants to learn/write Java. People probably prefer Kotlin over Java today. It's a much better language and you can keep using JVM libraries. Go is very simple language that is just as powerful as Java, if not more powerful due to not having to rely on the JVM. That's why it's so p…

What people?!? That is a very special bubble over there.

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

#77

Post by Cthulhu_ »

TurboHaskal wrote: post #39
jpgvm wrote: post #22

Earlier quoted context omitted.

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

It's not the language that gave me PTSD but the userbase, "best practices" and culture around it. Java itself is great these days.

I was going to say, Java is fine, it's the architectures and mountains of code spread across loosely coupled architectures that does it for me. I wouldn't mind a modern day Java project, as long as it's free of the 20+ year old dogmatic practices. I'd have to unlearn a lot of those myself, probably.

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

#78

Post by pjmlp »

Dinux wrote: post #75
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…

Are you kidding me? If it wasn't for large enterprise corporations Java would be long dead by now. Ever since Oracle took over Java has seen almost no improvements. The logical comparison is Java to C#, and C# has seen _a lot_ of improvement over the last 7 years or so. It just so happens that Java is sometimes unavoidable for Android development were Kotlin is not (yet) possible. Java is, like its large corporate us…

We are at Java 20, when Sun died we were stuck in Java 6.

No improvements, what a joke.

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

#79

Post by kaba0 »

samuell wrote: post #42
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…

Will they provide automatic M:N multiplexing on OS threads, or is that something that needs to be handled by the user somehow? Also, what about channels, and select semantics etc? I think before those are in place, with good library support, it won't be very close to competing with Go. Not to mention compilation to fully self-contained binaries.

> Will they provide automatic M:N multiplexing on OS threads

Yes, you can set the number of OS threads they can use.

Channels and alia have been implemented in Java’s standard library for many many years, it doesn’t need additional language features.

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

#80

Post by re-thc »

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…

> Jetty server guys tested this and they were not that happy

This was in 2021. Hopefully things have and will improve in the final version. We have to start somewhere.

> No silver bullet, again.

More like progressive improvement. If you always need things to be a 100% better we'll never have new toys :)

Post reply on HN