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

101–110 of 555 posts

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

#101

Post by Kelteseth »

kaba0 wrote: post #67
jve wrote: post #56

Earlier quoted context omitted.

Can you compile so that JRE is bundled with the program? I'm a C# developer and I also have a kind of resistance of java - having to install JRE and now the minefield Oracle made with the JRE, I'm hoping not only that I don't have to code in it, but that I don't have to use ANY Java program just to avoid the runtime or have to choose between different versions of it. And then the .jar files and how you execute them i…

Yes, there is in fact not even a JRE for quite some years now. Also, Oracle being a minefield is just bullshit - they are the ones that open-sourced the platform completely to the point that their paid version is only marginally different, but OpenJDK is the reference implemented. They are surprisingly good stewards of the language.

This is just the public perception. Being a full time Qt dev feels more and more like using Oracle software, where the software itself is FOSS and free to use, but the company behind it makes it look like it is not, with all the negative press.

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

#102

Post by Cthulhu_ »

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 would say that Go's error handling is a billion dollar mistake as well.

I think you'll need to substantiate that one with some solid evidence. I don't see anything wrong with Go's error handling that cannot be explained by developer choice.

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

#103

Post by re-thc »

esafak wrote: post #44
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. Java programmers I've seen don't use the latest idioms; they use pre-8.0 Enterprise Edition-ware because that's what they've been taught. It's a hideous sight and it has a lot of inertia. That's why I prefer kotlin.

What does this have to do with Java? As in there are no Javascript developers that use Promises instead of async/await?

There's always legacy and people that live with it.

It's a feature that there's no history now?

And soon we're going to cry about Kotlin developers that don't use the latest idioms... oh give it a few years...

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

#104

Post by kaba0 »

Cthulhu_ wrote: post #89
kaba0 wrote: post #69

Earlier quoted context omitted.

Have you seen the two languages, like.. ever? I’m sorry for the harsh language, but Go is literally much much more verbose than java, and not just recent Java that has since improved, even Java 8.

Citation needed; first off, verbosity is not the problem, verbosity is NEVER the problem; any significant codebase will end up with millions of LOC (and tokens) regardless of language choice. Second, Java's infamous for having VeryLongClassNameFactoryBeans on the one hand, and deep class hierarchies on the other, with new classes being declared for everything. Third, it depends. You can set up a HTTP server in two or…

We were talking about PL features, and now you bring up a style of writing said language (which by the way comes from very different times and is no longer the norm)?

Composition over inheritance has been a mantra in Java circles for a very long time now. The important difference is for example that Go can’t have proper error handling no matter how good the developer is, due to the language not having a proper abstraction over that.

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

#105

Post by tpxl »

jve wrote: post #87
kaba0 wrote: post #67

Earlier quoted context omitted.

Yes, there is in fact not even a JRE for quite some years now. Also, Oracle being a minefield is just bullshit - they are the ones that open-sourced the platform completely to the point that their paid version is only marginally different, but OpenJDK is the reference implemented. They are surprisingly good stewards of the language.

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…

The vast majority of Java is open source (Open JDK). You can get builds from Amazon (coretto), Microsoft, Red Hat, SAP, ... that do not stupid licensing requirements of Oracle.

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

#106

Post by kaba0 »

the_gipsy wrote: post #72
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 so…

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

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

#107

Post by pdpi »

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 brings runtime support for virtual threads, at the VM and standard library level, but there is no real language support, whereas Go has actual support with syntactic sugar around goroutines, channels, and select statements.

Tooling and the sheer number of libraries are definitely Java's biggest draws, but it's not enough to justify choosing Java over Go across the board.

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

#108

Post by sorokod »

Cthulhu_ wrote: post #89
kaba0 wrote: post #69

Earlier quoted context omitted.

Have you seen the two languages, like.. ever? I’m sorry for the harsh language, but Go is literally much much more verbose than java, and not just recent Java that has since improved, even Java 8.

Citation needed; first off, verbosity is not the problem, verbosity is NEVER the problem; any significant codebase will end up with millions of LOC (and tokens) regardless of language choice. Second, Java's infamous for having VeryLongClassNameFactoryBeans on the one hand, and deep class hierarchies on the other, with new classes being declared for everything. Third, it depends. You can set up a HTTP server in two or…

Looks like four lines of main() code, the rest is a specific hadler that would be needed regardless of language.

What part do you find magical?

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

#109

Post by commandersaki »

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?

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

#110

Post by [deleted] »

FooBarWidget wrote: post #25
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…

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…

[deleted]
Post reply on HN