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

291–300 of 555 posts

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

#291

Post by re-thc »

afavour wrote: post #237
re-thc wrote: post #103

Earlier quoted context omitted.

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

It’s all relative, though. One of the biggest complaints people have about the JS ecosystem is the lack of legacy: people do move from Promises to async quickly, when React switches to hooks everyone switches quickly, etc etc. For better or worse you can’t say the same about Java.

> people do move from Promises to async quickly, when React switches to hooks everyone switches quickly, etc etc

On Reddit or HN? Definitely in not the real world. Plenty of projects and even recently created 1s don't always use these new ways of working. Even on Reddit when I see a new project getting posted it doesn't have this trait you mention.

And lots of companies are still on Node 14/16 or even older :( only forced to move by e.g. AWS lambda runtime requirements...

And Node developers are still using ExpressJs and promote it all the time. Guess when Express 4 was released? 5 has been in beta forever with no updates. Yet, most promote it and ignore the other options. Lack of legacy? This thing is 10+ years old. It's barely maintained... what's the difference?

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

#292

Post by [deleted] »

marginalia_nu wrote: post #276
vrnvu wrote: post #187

Earlier quoted context omitted.

Completely agree with you. I stopped working with Java not because the language or the ecosystem. I stopped working with Java because Java developers and their culture of over-engineering everything defending it as "clean code" and "good practice". But this seems a taboo topic in a culture infested with "good practice gurus".

This seems pretty uncontroversial in the Java space. I think most Java developers will wince at clean code. Clean Code made sense in contrast to the pervading gang-of-four norms that preceded it, but I don't think many people would recommend the style today.

[deleted]

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

#293

Post by BenoitP »

philonoist wrote: post #199

Anyone familiar with Java and Kotlin, please expand on how close is Java in feature parity with Kotlin?

Kotlin's are stackless (as in emulated by the compiler), Java's are stackful (as in a chunk of stack is copied into the heap along with a program resume point)

This means Kotlin's functions can become colored [1] which is a problem.

This said, I'm fully expecting Kotlin to react and pass on this feature to the users. Maybe after figuring out how to deal with Android.

[1] https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...

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

#294

Post by birdfood »

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

https://gleam.run is a statically typed language on the BEAM

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

#295

Post by bullen »

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.

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

#296

Post by pjmlp »

Kwpolska wrote: post #236
pjmlp wrote: post #85

Earlier quoted context omitted.

A first class citzen would have support for MAUI, and something better than VSCode like macOS gets VS4Mac.

JetBrains Rider is available for Windows, Linux, and macOS, and it's much better than VS, VS for Mac, and VSCode. It's not free, but VS isn't either for any serious commercial usage, and Rider is certainly worth the money.

Workarounds, and still doesn't fix the issues lacking from the company that owns .NET.

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

#297

Post by pjmlp »

Kwpolska wrote: post #271
pjmlp wrote: post #78

Earlier quoted context omitted.

We are at Java 20, when Sun died we were stuck in Java 6. No improvements, what a joke.

Version numbers are extremely arbitrary, and Java has a new number every 6 months. If you compare Java 6 (2006) and Java 20 (2023), and then look at C# 3.0 (2007) versus C# 11 (2022), C# has gained many more features and improvements than Java did over the years.

Including copying Java features like tiered compilation, default interface methods, compiler plugins, AOT compilation, being able to run UNIX systems, failing on having phone OS written in C#.

Anyone that misses C# on the JVM can use Kotlin or Scala.

And best of all, due to Microsoft's lack of investment on VS4Mac and VSCode versus VS proper, the best .NET IDE outside Windows runs on Java/Kotlin.

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

#298

Post by equalsione »

kabes wrote: post #176
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 a language java's not that bad at this point. But it still has cultural issues. Every java project I encounter tends to be overengineered, has tons of useless boilerplate code and ends up throwing mile-long stack traces as a result. Also, somehow maven manages to be even more unreliable than npm as a package manager. I still frequently encounter situations which seem to only get resolved by throwing away my .m2 fo…

Pre-java 8 (Java.old) and post-Java.8 (Java++) are philosophically two different languages.

Now, 21 is coming and while the changes aren't quite as in your face, the change in philosophy is just as radical.

Java would be better regarded if less time was spent on "look at this cool new feature" and more spent on "this is how you should use Java now". Or even, "here's how to safely modernise your codebase".

Venkat Subramaniam does some good talks on this but I would prefer if the Java language team were leading it.

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

#299

Post by francasso »

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.

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

#300

Post by [deleted] »

vrnvu wrote: post #187
kabes wrote: post #176

Earlier quoted context omitted.

As a language java's not that bad at this point. But it still has cultural issues. Every java project I encounter tends to be overengineered, has tons of useless boilerplate code and ends up throwing mile-long stack traces as a result. Also, somehow maven manages to be even more unreliable than npm as a package manager. I still frequently encounter situations which seem to only get resolved by throwing away my .m2 fo…

Completely agree with you. I stopped working with Java not because the language or the ecosystem. I stopped working with Java because Java developers and their culture of over-engineering everything defending it as "clean code" and "good practice". But this seems a taboo topic in a culture infested with "good practice gurus".

[deleted]
Post reply on HN