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

131–140 of 555 posts

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

#131

Post by kaba0 »

datadeft wrote: post #38
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. :)

Scala? A good contender might be OCaml as well.

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

#132

Post by polotics »

Cthulhu_ wrote: post #77
TurboHaskal wrote: post #39

Earlier quoted context omitted.

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.

Also the culture of those that stuck to Java because they didn't have the curiosity to learn anything else...

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

#133

Post by jillesvangurp »

commandersaki wrote: post #109
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 jars are more portable than go's binaries Since when?

Well a go binary only runs on the platform it was compiled for. A jar file runs on any platform that has a working JVM. I.e. most commonly used operating systems and CPU architectures you can name.

Of course whether that matters to you is another thing. Most people package either of those up using docker and run them on generic linux hosts.

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

#134

Post by kaba0 »

mike_hearn wrote: post #100
FooBarWidget wrote: post #25

Earlier quoted context omitted.

As someone who recently developed in Java (for developing a Jenkins plugin) after not having done so for a long time (~15 years), I feel that Java nowadays is technologically quite interesting with many interesting libraries and tooling. IDE code navigation and debugging support is excellent. At the same time, the ecosystem can feel messy and overwhelming. There are multiple @Nonnull annotation libraries and it's not…

Hi there ;) Knowing you, I'm sure you've got it all figured out by now but for any others who are reading: - Nonnull annotations: you can pick any. Tooling doesn't care and tends to just accept any annotation with a name like @Nullable or @Nonnull regardless of namespace. There was an attempt to standardize this years ago which failed for reasons that are hard to understand from the outside, something to do with lack…

As for the JDKs, they are basically all just OpenJDK repackaged. Think of them more like debian’s chromium vs arch’s packaged chromium.

You can generally use any.

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

#135

Post by marginalia_nu »

kaba0 wrote: post #122
marginalia_nu wrote: post #117

Earlier quoted context omitted.

Big part of why native interop is rare because it's slow and awful and generally not worth it. I don't expect a lot of code to actually use these features, but the code that does will be the low level stuff that lets the higher level stuff really perform.

FFI makes cross-platform usage more questionable (have a look at python or node breaking a build on windows vs linux, this is very very rare in case of Java builds), and Java is more than fast enough for most use cases that it simply doesn’t need FFI for speed (like Python for example). Also, this is a huge advantage of the system, you don’t shallowly depend on a ton of C libraries, you can be confident that your who…

Eh, Java leaves quite a lot of performance on the table compared to C or Fortran. It's not as bad as Python, but if you really want to go fast, it's not quite able to compete with fine tuned native code. The Vector API might help a bit, but I don't think it will go all the way.

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

#136

Post by winrid »

the-smug-one wrote: post #19
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…

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

You can configure the GC to give the memory back to the OS after a short interval. We do this at FastComments with Shenandoah for our pubsub system.

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

#137

Post by marginalia_nu »

kaba0 wrote: post #119
marginalia_nu wrote: post #14

Earlier quoted context omitted.

I think there are still a few changes in the pipe before Java is quite what it could be in terms of performance. Project Valhalla, and the foreign function and memory APIs in particular.

For non-trivial problems GC performance will be much more important, and Java will beat out go in that category with flying colors.

It's definitely a factor, but it's not really enough. You can squeeze far more performance out of the hardware than idiomatic Java permits.

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

#138

Post by vincnetas »

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…

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

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

#139

Post by kaba0 »

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

Very subjective, but having Java syntax is an advantage compared to goddamn Go — like I have seen my fair share of languages and can generally “read” a new language’s code sample just fine, but go was honestly quite hard the first time with their stupid type, “receiver” etc notation. And I have honestly no problem with Haskell/Lisp/C/etc notation at allz

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

#140

Post by bborud »

kaba0 wrote: post #106
the_gipsy wrote: post #72

Earlier quoted context omitted.

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 so…

Based on your writing, your experience with Java is indeed very limited and not up-to-date at all.

When talking about languages a lot of people talk about languages as if all programmers deal with is starting new projects from scratch and being able to use the latest version of the language, using current practices. For most programmers this isn't the case. Most programmers work on projects that were not started by them, and have been around for a while. Or software that is built on, or has to be closely integrated with, legacy code.

Based on your writing, you sound like either a junior engineer, or someone who has had very little responsibility for making resource allocation and strategic decisions.

Post reply on HN