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

31–40 of 555 posts

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

#31

Post by pharmakom »

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…

C# already had all the advantages of Go (more or less) and more, yet Go is still growing. This has nothing to do with the technical capabilities of the languages.

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

#32

Post by Kwpolska »

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 features (properties and operator overloading, for example). It often suffers from design-by-committee (e.g. https://openjdk.org/jeps/430 ).

And then you get to the web frameworks. The most popular one is Spring, and it's a pain, with abuse of reflection and magic, bad docs, and other issues.

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

#33

Post by PlutoIsAPlanet »

threeseed wrote: post #23
the-smug-one wrote: post #19

Earlier quoted context omitted.

> So with this, the last thing Go had going for it over Java is gone, right? No. Go does containerized microservices better because of its lower memory footprint. If you can use GraalVM then that might not matter.

This is based on outdated advice. Java stacks like Quarkus [1] have memory as low as 12MB and JVMs like OpenJ9 natively support CRIU for instant startup. [1] https://quarkus.io [2] https://blog.openj9.org/2022/10/14/openj9-criu-support-a-loo...

Yet with Go you don't need to worry about comparing Java Stacks, changing your tooling, testing them etc, the binaries "just work" out the box in a near perfect condition.

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

#34

Post by Un1corn »

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…

This is a pretty terrible comparison, suitable for those X-vs-Y websites. While on paper Go and Java have a lot in common, in practice their philosophies differs enough to produce different enough languages.

I've used both Java and Go and I can tell you, there is no right or wrong but they differ a lot in their ecosystem, tooling and in design patterns. I don't see myself going back to Java because of the virtual threads.

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

#35

Post by junon »

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.

Yeah. Java isn't particularly sexy. But it gets the job done. I'd even settle for Java 7 still, it was more than enough to get the job done, especially when you are a startup trying to get an MVP out the door that can still be refactored and maintained somewhat easily when you bring in more skilled developers.

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

#36

Post by junon »

PlutoIsAPlanet wrote: post #33
threeseed wrote: post #23

Earlier quoted context omitted.

This is based on outdated advice. Java stacks like Quarkus [1] have memory as low as 12MB and JVMs like OpenJ9 natively support CRIU for instant startup. [1] https://quarkus.io [2] https://blog.openj9.org/2022/10/14/openj9-criu-support-a-loo...

Yet with Go you don't need to worry about comparing Java Stacks, changing your tooling, testing them etc, the binaries "just work" out the box in a near perfect condition.

Not really. We saw overall performance speed up when we limited the number of system threads for goroutines to 1. This was with Docker and Kubernetes (albeit several years ago). This was configured, if memory serves, by an environment variable.

So no, it's not as simple and perfect in my opinion.

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

#37

Post by jbverschoor »

darthrupert wrote: post #24
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 will always have Java syntax, though. And its runtime will remain rather heavy compared to language implementations that compile down to machine code. Go's benefit's will probably always be there. Java can be taught to 2-year olds so Go seems to have a slight disadvantage there. ;)

Java Card on smart cards?

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

#38

Post by datadeft »

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…

It would be great to have a language that is a love child of Erlang and Rust. All I need is: repl, message passing, actor model, lightweight-threads and strong types. :)

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

#39

Post by TurboHaskal »

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.

It's not the language that gave me PTSD but the userbase, "best practices" and culture around it.

Java itself is great these days.

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

#40

Post by mseepgood »

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.).

Post reply on HN