Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency • Hacker News Board

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

#51

Post by re-thc » Wed, Apr 12, 2023, 8:03 AM UTC

jeroenhd wrote: post #43

hintymad wrote: post #13

Earlier quoted context omitted.

My experience in small companies told me that younger generation didn’t choose Go because Go is objectively better than Java, but because they actively hate Java for it being out of fashion.

I think Java is an ugly language riddled with roundabout ways of implementing modern features, but I can't fathom why anyone would pick Go over Java. It's slightly worse in almost every way other than writing shell scripts or massively parallel workloads from scratch. In my experience, Java's problem is the same as C++'s when Java began to take over: you usually encounter it in projects stuck at ancient runtime versi…

A lot of people don't know what's best e.g. beginners. A lot of the Go and Node crowd take it own as a mission to fame by stepping on Java. It's worse when a lot of these personalities don't even code except make youtubes videos or blogs.

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

#52

Post by marginalia_nu » Wed, Apr 12, 2023, 8:03 AM UTC

maxbond wrote: post #48

marginalia_nu wrote: post #18

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

To be fair though M:N threads aren't the provenance of research language, Go and Rust both have them, and I'm sure some other languages. (But it's awesome Java has them now too, other languages getting the feature earlier doesn't really devalue it.)

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

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

#53

Post by mike_hearn » Wed, Apr 12, 2023, 8:03 AM UTC

pizza234 wrote: post #30

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…

What's the modern startup time of JARs? I haven't used Java in a long time, but long ago, the relatively slow startup time was a dealbraker for using java to write small tools.

Depends what the JARs do of course. Some desirable libraries are unfortunately slow. PicoCLI for argument parsing is one. It's got every feature you might ever want, but, it adds a couple hundred msec to startup.

There is a HotSpot feature called AppCDS. It improves startup time by about 30% in my experiments. However you have to turn it on. Just running `java -jar` won't do it.

Then there is GraalVM Native Image. It can compile JARs to native code ahead of time. They start as fast or faster than the equivalent C program, so it's the big hammer for CLI tools. However, it can't cross compile so you have to compile for the target system on the target system. There can also be compatibility issues with some libraries, though that's getting better rapidly.

So those are the options. Still, even without those extra features, startup time is usually good enough.

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

#54

Post by vardump » Wed, Apr 12, 2023, 8:03 AM UTC

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…

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

You can deploy Go app with a single binary, no runtime required. No runtime configuration.

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

#55

Post by re-thc » Wed, Apr 12, 2023, 8:04 AM UTC

jpgvm wrote: post #22

hintymad wrote: post #13

Earlier quoted context omitted.

My experience in small companies told me that younger generation didn’t choose Go because Go is objectively better than Java, but because they actively hate Java for it being out of fashion.

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

It's not just startups where this happens. In older companies you have older "leaders" that claim to have been hit by Java 5-10 years ago so don't trust it. Yet they've never tried it again since.

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

#56

Post by jve » Wed, Apr 12, 2023, 8:04 AM UTC

jpgvm wrote: post #22

hintymad wrote: post #13

Earlier quoted context omitted.

My experience in small companies told me that younger generation didn’t choose Go because Go is objectively better than Java, but because they actively hate Java for it being out of fashion.

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 in command line is different (java -jar), maybe it is simple, but it is different than a plain executable file.

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

#57

Post by moring » Wed, Apr 12, 2023, 8:04 AM UTC

The top comment in this thread [1] highlights (potential) problems with virtual threads, referring to this PDF [2]. Does anyone know if these actually manifest in the way they are implemented?

[1] https://www.reddit.com/r/rust/comments/xrrjec/virtual_thread...

[2] https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2018/p13...

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

#58

Post by impulser_ » Wed, Apr 12, 2023, 8:04 AM UTC

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 popular as a replacement for Java.

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

Java obviously has a more mature ecosystem with more libraries due to age, but Go you don't need many libraries to begin with. The Go std lib will give you almost everything you need in most cases.

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

#59

Post by foepys » Wed, Apr 12, 2023, 8:04 AM UTC

pharmakom wrote: post #31

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…

C# already had all the advantages of Go (more or less) and more, yet Go is still growing. This has nothing to do with the technical capabilities of the languages.

To be fair, .NET only recently got AOT compilation and single binary (or self-contained) deployments as officially supported features.

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

#60

Post by yxhuvud » Wed, Apr 12, 2023, 8:04 AM UTC

hintymad wrote: post #13

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…

My experience in small companies told me that younger generation didn’t choose Go because Go is objectively better than Java, but because they actively hate Java for it being out of fashion.

I'd rather think they hate it for being a word salad with lots and lots of boilerplate. Go has its issues, but that isn't one of them.