`Executors.newVirtualThreadPerTaskExecutor()`.
Java verbosity is alive and well.
Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
201–210 of 555 posts
Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#202So 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 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.).
Java methods support type arguments. Go methods do not leading to convoluted gymnastics for straightforward behaviour.
> Java's type system is not unified, it does not have a top type
Neither does Go for that matter.
Go's lack of visibility modifiers and package scope namespace cause very common gotchas mentioned in https://itnext.io/we-need-to-talk-about-the-bad-sides-of-go-....
There is a Manning book about Go: https://www.manning.com/books/100-go-mistakes-and-how-to-avo... . And these are not rare mistakes. Everyone makes them and some of those mistakes are repeated again and again in every Go project. (Esp the for-loop ones). I have found programming in Go needing the kind of alert, defensive mindset I adopt for C++ which is quite exhausting. Not so much for Java.
However, to be honest, Rust is probably the only the language where you can relax your "defect-analysis" mind thread while coding - with the exception of async Rust.
Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#203Earlier quoted context omitted.
Well, yeah. Haskell is a research language, while Java's stated design philosophy from day one has been to be conservative with adding new features, and judiciously add new features after they've proven useful in other languages.
So how does that make a difference to my point? The title is literally false as multiple other languages have already done it, Haskell in fact has even rewritten the underpinnings at least once the feature has been there so long.
The fact that X exists doesn't mean the "era of X" has started yet, you have to have the exponential adoption curve. The "Internet Age" started several years after the Internet was created
And clearly, adding this feature to Java is going to be like putting a web browser in Windows 95
Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#204Earlier quoted context omitted.
It’s not hard to find people who want to write Java. I do it all the time. We have been hiring and writing Java code for fifteen years and have not seen a decline in the interest.
It’s hard to find quality people who want to write Java.
You are talking about more people than there are people in my country (around 10 millions java devs are out there)
Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#205Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#206So 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…
`com.lol.myapp.factory.UserFactoryImpl.java` would like to have a word about its clear superiority
Never wrote one. Couldn't care less.
Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#207So 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…
> I still frequently encounter situations which seem to only get resolved by throwing away my .m2 folder.
I have my own issues with Maven, but never in my 16 years doing Java have I done that. What the heck leads you to believe doing that may fix something at all? .m2 is just a cache, it has pretty much zero impact on whether your stuff will build unless you had installed things there that are not available on a configured repository or something similar, which would of course be your mistake not the tool's.
Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#208Earlier quoted context omitted.
`com.lol.myapp.factory.UserFactoryImpl.java` would like to have a word about its clear superiority
that's a culture issue that is changing rapidly to avoid that. Also that was common due to previous limitations in the language. regarding the "com.lol.myapp", i actually think this is a good think for package management, it avoids naming issues with packages for different vendors and forks. On the code itself you should only see these on the import lines on top of the file, which isn't really a big deal. I think mos…
> that's a culture issue that is changing rapidly to avoid that.
Define rapidly. It's now been two decades since I was first told "yes, that's a culture thing, but everyone knows it's crazy, and it's on the way out".
E.g., this masterpiece from Benji Smith [0], originally on the old "Joel On Software" forum, is from 2005.
[0] https://gwern.net/doc/cs/2005-09-30-smith-whyihateframeworks...
Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#209While this is definitely a good new, we need to be very careful. Why? Those new fancy threads are stored on heap and need to be garbage collected. If you buy into ads and believe that you can create for free millions of threads, then, well, it is not gonna work on production. Because of this server based on new threads does not need to be more performant, Jetty server guys tested this and they were not that happy: ht…
Million thread shouldn't be an issue (million times 2k bytes per thread = 2gb)
Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#210Well it's not really ushering it in, given that this is what Haskell has had for a decade at least.
What's haskell? \s