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

301–310 of 555 posts

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

#301

Post by giancarlostoro »

bullen wrote: post #295

NIO solved the problems with threads on the network in Java 1.5 (seminal cornerstone API that also had the concurrency package and rewrote the entire JVM memory model), but only in 1.7 the epoll solution became stable. 2004 -> 2011, 7 years! Now they hopefully can work around the kernel for file descriptors (network and disk) saving 30% CPU globally on all Java servers. Many nuclear power plants wasted on the kernel.

> Many nuclear power plants wasted on the kernel.

iTunes could have reached greater heights had they allowed nuclear plants.

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

#302

Post by threeseed »

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.

But that's because Go has a significantly worse ecosystem.

And those Go binaries aren't runnable across a wide range of platforms like JVM apps are.

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

#303

Post by andix »

francasso wrote: post #299
andix wrote: post #290

Is this the equivalent for the .NET TPL (task parallel library), which exists for over a decade now?

Not familiar with .NET, virtual threads in Java are an alternative to async await in other languages. The approach Java took is similar to green threads in go.

TPL is a library to create Tasks and run them. They can be scheduled in different ways, on (native) thread pools for example. They are commonly used together with async/await. They are very similar to promises in JavaScript.

I read about the approach without async/await, but honestly I don’t really get it. Seems to be very dangerous to me, if you give up control about scheduling. But sure, async/await is completely viral and it is everywhere now. Most functions tend to be async.

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

#304

Post by kosolam »

The biggest win by far IMHO is a performant alternative for io intensive applications for async frameworks. Not using an async framework tremendously simplifies your code. Code complexity has an enormous projection on everything else, especially when talking on the business level. First and foremost the cost of development and time to market rises. And then comes the cost of maintenance.

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

#305

Post by yarg »

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?

Erasure's not the end of the world, but it'd be nice to have access to the generic class without having to pass it in.

    Collection values = ...
    Foo[] array = values.toArray(Foo[]::new);
Not the worst, but not the best either.

There are many situations where the code I implemented could have been far cleaner with reified generics.

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

#306

Post by ahtihn »

francasso wrote: post #299
andix wrote: post #290

Is this the equivalent for the .NET TPL (task parallel library), which exists for over a decade now?

Not familiar with .NET, virtual threads in Java are an alternative to async await in other languages. The approach Java took is similar to green threads in go.

> virtual threads in Java are an alternative to async await in other languages

Not really. Async/Await is mostly about syntax. Transform callback-hell into something that looks like linear code. The underlying threading model doesn't really matter for that.

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

#307

Post by marginalia_nu »

kaba0 wrote: post #218
marginalia_nu wrote: post #137

Earlier quoted context omitted.

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.

Sure, but not with another managed language like Go.

I'm not sure what you mean. Why should I settle for less performance than my hardware can deliver?

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

#308

Post by segfaltnh »

threeseed wrote: post #302
PlutoIsAPlanet wrote: post #33

Earlier quoted context omitted.

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.

But that's because Go has a significantly worse ecosystem. And those Go binaries aren't runnable across a wide range of platforms like JVM apps are.

I suppose it depends on what you're writing. When I read "wide range of platforms" I involuntarily said "who cares" out loud. For those of us (fortunately or unfortunately) working in distributed systems, there is one target environment and maybe a different local environment depending on your setup.

Likewise for "worse" ecosystem. It really depends on your context.

Edit: A closing thought: One thing I find enjoyable about working with Go is that it is tuned for my particular context. I also enjoy writing Java (and more specifically Kotlin) when that context changes (e.g. a desktop application).

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

#309

Post by i386 »

hamburglar wrote: post #288
i386 wrote: post #235

Earlier quoted context omitted.

Having worked with maven for about 15 years… it’s largely not a problem anymore. Unless you publish snapshots and depend on them.

If “it’s just a cache,” you should never be able to fix a build problem by nuking your cache. But I frequently can.

Might want to enable strict checksumming on. I think that’s still a thing. Or are you depending on release artifacts that change?

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

#310

Post by Thaxll »

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 mean having a nice feature does not remove all the other pain points. On your last point go mod is way better than anything available in Java. There're still printing out 600 pages book about Maven.

Java will always be a mess of layer of abstraction and magical / heavy framework.

Post reply on HN