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

151–160 of 555 posts

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

#151

Post by gpderetta »

kaba0 wrote: post #71
mseepgood wrote: post #40

Earlier quoted context omitted.

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

No. Both type erasure and monomorphization have always been legitimate ways to compile generic code. IIRC, the issue with Java is that type erasure is sometimes a leaky abstraction.

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

#152

Post by kjto »

marginalia_nu wrote: post #128
kjto wrote: post #90

Earlier quoted context omitted.

.net has had this feature for a decade++

Yeah, so has a lot of languages. See the previous comment.

you’re trying to support “judicious and conservative” but realistically java is on a lifeline like fortran, delphi and objectiveC

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

#153

Post by spion »

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…

Kind of, but not quite. There is also:

- compiling to a single binary (I guess jpackage fixes this)

- saner / less elaborate / more ergonomic interfaces to implement and use e.g. compare `io.Reader` (https://go.dev/tour/methods/21) to the Java equivalent

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

#154

Post by marginalia_nu »

kjto wrote: post #152
marginalia_nu wrote: post #128

Earlier quoted context omitted.

Yeah, so has a lot of languages. See the previous comment.

you’re trying to support “judicious and conservative” but realistically java is on a lifeline like fortran, delphi and objectiveC

What are you basing this sentiment on?

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

#155

Post by matsemann »

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…

> How are Jars more portable than Go binaries when you need Java installed to run Jars?

Your java knowledge is half a decade out of date.

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

#156

Post by TedDoesntTalk »

jve wrote: post #145
kaba0 wrote: post #98

Earlier quoted context omitted.

Are you using Photoshop without a license as well or how is that relevant? This is about Oracle’s JDK you specifically have to install and have a paid license to (actually, they also provide a free version if you stay on the latest LTS release at all times), and is meant mostly for governments and such. Will you uninstal linux because Red Hat has a paid support version as well?

So if i have JDK (Which I must) I do have to buy those licenses.. for all our employees? > The Java Platform, Standard Edition (Java SE) and Java SE Universal Subscription from Oracle include the Java Development Kit (JDK), and Java Runtime Environment (JRE) https://www.oracle.com/java/technologies/faqs-jsp.html#:~:te... . Do I not need the Java SE subscription to use JRE? Do I not need the Java SE subscription to us…

> So if i have JDK (Which I must) I do have to buy those licenses.. for all our employees?

No, use OpenJDK like the rest of the world. It’s free and open-source.

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

#157

Post by pjmlp »

spion wrote: post #153
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…

Kind of, but not quite. There is also: - compiling to a single binary (I guess jpackage fixes this) - saner / less elaborate / more ergonomic interfaces to implement and use e.g. compare `io.Reader` ( https://go.dev/tour/methods/21 ) to the Java equivalent

Several commercial JDK options have offered compiling to single binary for 20 years, even if out of reach for common folks. GraalVM and OpenJ9 now make it available as free beer as well.

https://docs.oracle.com/en/java/javase/20/docs/api/java.base...

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

#158

Post by alkonaut »

killerstorm wrote: post #150
alkonaut wrote: post #121

How is a system of virtual threads different from typical "a pool of tasks and a pool of threads to perform them on" systems like e.g. the .NET TPL?

I guess the idea is that you don't have to write tasks explicitly - if you have a sequence of actions you can just write it as a regular code, and the runtime will automatically insert points where your code might be suspended waiting for IO or other threads.

The only example in the article does an explicit task though (in the form of a closure) e.g. something.submit(() -> { task code });

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

#159

Post by pjmlp »

pdpi wrote: post #115
marginalia_nu wrote: post #66

Earlier quoted context omitted.

> How are Jars more portable than Go binaries when you need Java installed to run Jars? Uh, you don't...? https://docs.oracle.com/en/java/javase/14/docs/specs/man/jpa... > you don't need many libraries to begin with. This really depends on what you're doing. Having many libraries creates a lot of weird potential. You can absolutely subsist on less, but you can do more with more. A while back I found myself wanting to…

> Each format must be built on the platform it runs on, there is no cross-platform support. So now you're back to platform-specific packages, except you don't have Go's support for cross-compilation. Hardly much of an advantage.

Go only does cross-compilation when using the standard library and pure Go libraries, hardly any different.

Plus the target OS needs to exist on the toolchain anyway.

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

#160

Post by jsiepkes »

pjmlp wrote: post #157
spion wrote: post #153

Earlier quoted context omitted.

Kind of, but not quite. There is also: - compiling to a single binary (I guess jpackage fixes this) - saner / less elaborate / more ergonomic interfaces to implement and use e.g. compare `io.Reader` ( https://go.dev/tour/methods/21 ) to the Java equivalent

Several commercial JDK options have offered compiling to single binary for 20 years, even if out of reach for common folks. GraalVM and OpenJ9 now make it available as free beer as well. https://docs.oracle.com/en/java/javase/20/docs/api/java.base...

We used ExcelsiorJET to create (pre-compiled) executables for Java (Swing) applications back in 2009 if memory serves me right.
Post reply on HN