Live data from Hacker News

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

infoq.com

211–220 of 555 posts

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

#211
post #82

Earlier quoted context omitted.

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…

> The most popular one is Spring, and it's a pain, with abuse of reflection and magic, bad docs, and other issues How is it any different from something like RoR or Django, both of which are well-liked?

Depends if they are talking about Spring the framework, or Spring Boot, the "conventions bootstrapper"

Both of them do not have bad docs, maybe some sub project might have, but compared to RoR (sorry never used Django), Spring's projects docs are magnificent. Their problem could be navigation for someone new to it, or in the case of Spring Framework, just too much concepts.

So, Spring Framework is basically "make everything configurable extensible etc", its code if full of old java patterns for generic stuff (the infamous "AbstractSingletonProxyBeanFactory" , ye, not great), to not only have a very feature full dependency injection, but to allow stuff like AOP and setting up via xml and many other things. This is the base of spring so you will have to kinda deal with its concepts if you hit an issue.

Ruby on Rails was a reaction to things like Spring, it's philosophy is "convention over configuration" in contrast to Spring's unparalleled configuration options. And so Spring Boot is born as a reaction to Rails.

Spring Boot is at its core 2 things

* an annotation engine for Spring configuration, instead of using all those hellish factories or XML

* Sane Defaults for Spring Framework There were also many other projects under its umbrella to streamline with those 2 things other components of the Spring ecosystems, from Http Apis to Repository patterns

Ok so reflection and magic:

* Both are full of reflection. That's how it keeps being very generic at its core.

* Magic is an issue of Boot, you just put some annotation and it would do who knows what. Still way less magic than Rails, as at least you see the annotations, and search for it in the docs. Framework isn't really "magic", as you would have to explicitly configure everything in either XML or through its classes. ( Spring Data does have weird magic, worse that Rails, generating full SQL queries from method names? C'mon)

Nowadays, modern java (server side) either uses Spring Boot (due to easily supporting most kind of infra you might use from persistence to messaging), something specific for their use case (quarkus makes it easy for small image and quick startup) or not use a DI framework at all, as most servers nowadays are fine, and language has plenty of features to not need some management of Injected. I actually see no value now to "minimal DI frameworks", because manually wiring is not actually hard except when you have a circular dependency, which you should not have anyway. (The codebases I had better time working with were either on Boot or had no managed DI)

Spring Boot and Framework new releases actually require Java17, with the objective of being able to start to clean up their codebase from old patterns that were kinda required in the old times.

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

#212
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…

> So with this, the last thing Go had going for it over Java is gone, right?

Go still has composition over inheritance, which is vastly more flexible. Go favors explicit (verbose copy-paste, redundancy, use stdlib first, libraries second) over implicit (magic annotations, frameworks everywhere) and I like when I can understand what's happening without holding 10 files in my brain context. Go's memory usage doesn't trigger the OOM killer every 10 minutes. Go favors copy-pasting because what you copy is short and understandable, and function names don't have 10 words in it.

It's always going to be a personal choice, and even though virtual threads bring java closer to where go is, it's still not there for me.

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

#213
post #107
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…

Java also has a low-lat GC which is also better than Go’s at the relevant metrics (ZGC).

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

#214

Every time something show up about anything related to Java, the discussions turn to this flame war about what language are better or worse than Java. Why can’t we just discuss the article at hand? In this case, I’d love to hear more from experienced Java developers, with existing code-bases, who have tested these new virtual threads out.

Indeed. It is the curse of the Stroustrup law.

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

#215
post #56
post #22

Earlier quoted context omitted.

Irrational Fear of Java is one of the most confusing things among startup stage companies.

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…

Single executable is useful for end-user. It is not very relevant on servers or for development.

On the other hand portability and debugging experience with jars are vastly better. Just consider a developer on Mac with Apple silicon cannot use the same executable as on Amd/Intel server, while jars are cpu-independent.

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

#216
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…

If you wish to avoid JRE, you can use Graal VM and compile to native AOT executables. Just takes a few minutes to download and play-around. (Even timed it with another Java disbeliever here on HN) https://www.graalvm.org/latest/reference-manual/native-image...

When I tried it the file size ended up way bigger than just packaging a JVM would be

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

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

The love child of Erlang and Rust exists already: Pony.

https://www.ponylang.io

It really is the best of both languages... unfortunately, the main supporter of Pony seems to have stopped using it in favour of Rust though :D.

But if that's really what you want, Pony is your language. It definitely deserves more love.

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

#218
post #119

Earlier quoted context omitted.

For non-trivial problems GC performance will be much more important, and Java will beat out go in that category with flying colors.

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.

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

#219

Earlier quoted context omitted.

If you wish to avoid JRE, you can use Graal VM and compile to native AOT executables. Just takes a few minutes to download and play-around. (Even timed it with another Java disbeliever here on HN) https://www.graalvm.org/latest/reference-manual/native-image...

When I tried it the file size ended up way bigger than just packaging a JVM would be

That isn't a general behaviour. You can get "Use GraalVM Dashboard to Optimize the Size of a Native Executable"

https://www.graalvm.org/latest/reference-manual/native-image...

Tutorial that shows reducing binary size from 17MB to 862KB!

https://docs.oracle.com/en/graalvm/enterprise/22/docs/refere...

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

#220
post #90

Earlier quoted context omitted.

My point is that they're on diametrically opposite ends of the language-philosophical spectrum.

.net has had this feature for a decade++

Are you sure? All the discussion I can find online makes it seem to me like TPL and friends are just executing tasks on thread pools until completion. (see e.g., https://github.com/dotnet/runtime/issues/50796 for some discussion)
Post reply on HN