Live data from Hacker News

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

infoq.com

61–70 of 555 posts

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

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

On a $50/mo Azure VM running Windows Server I’m able to run a jar via java.exe that prints a string to stdout and exits - in about 160ms end-to-end in a warm-ish environment (Prefetch, IO caching, etc)

Edit: Now it’s down to 80ms - I guess at this scale it’s hard to pin down.

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

#62

Earlier quoted context omitted.

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.

C# doesn’t really have an equivalent for Go’s channels syntax though. Also, Go doesn’t have inheritance, but does have interface forwarding and structural (as opposed to nominative) type-system - those both very significant factors that influence final program design.

.NET has channels as part of the standard library.

In C# you must write explicit async/await keywords whereas in Go it is implicit, but the code reads almost the same.

I would argue against using implementation inheritance generally and interfaces sparingly in C# anyways.

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

#63

Earlier quoted context omitted.

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.

C# doesn’t really have an equivalent for Go’s channels syntax though. Also, Go doesn’t have inheritance, but does have interface forwarding and structural (as opposed to nominative) type-system - those both very significant factors that influence final program design.

Being not super familiar with Go, I think C#'s async/await is similar, isn't it? If you want more complex operations, you might want to look into System.IO.Pipelines.

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

#64
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 p…

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.

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

#65
post #47

Earlier quoted context omitted.

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.

C# GC, MS and external libraries, build, docs, tools support (especially for Linux) are all worse than Java.

How so? Linux is a first class citizen in .NET these days.

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

#66
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 p…

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

Uh, you don't...?

https://docs.oracle.com/en/java/javase/14/docs/specs/man/jpa...

> you don't need many libraries to begin with.

This really depends on what you're doing. Having many libraries creates a lot of weird potential. You can absolutely subsist on less, but you can do more with more.

A while back I found myself wanting to render MathML into an image. So I dug up jeuclid which is absolutely antique and as far as I can tell not actively maintained. My project flat out would have ended there if I had to build my own math rendering engine to proceed.

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

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

Yes, there is in fact not even a JRE for quite some years now.

Also, Oracle being a minefield is just bullshit - they are the ones that open-sourced the platform completely to the point that their paid version is only marginally different, but OpenJDK is the reference implemented. They are surprisingly good stewards of the language.

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

#68
post #22

Earlier quoted context omitted.

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

I am not sure there is fear against Java as much as there are better alternatives for many use cases.

I would argue the “many”, especially when we talk about regular old CRUD apps most startups are.

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

#69
post #60

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

Have you seen the two languages, like.. ever? I’m sorry for the harsh language, but Go is literally much much more verbose than java, and not just recent Java that has since improved, even Java 8.

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

#70
While 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: https://webtide.com/do-looms-claims-stack-up-part-1/

Before getting too excited I advise to watch Tomasz Nurkiewicz lecture on the subject - https://www.youtube.com/watch?v=n_XRUljffu0, it explains what are the trade-offs here.

No silver bullet, again.

Post reply on HN