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

191–200 of 555 posts

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

#191

Post by lenkite »

datadeft wrote: post #45
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.

There are legitimate reasons to chose Go over Java, starting with the build system and the amount of effort needed to produce a single binary. I use Java for 20 years and Go for ~2. I am not actively hating Java but I value my time, specially that was wasted on maven + co.

"..and the amount of effort needed to produce a single binary."

A couple of minutes ? Even timed this with another HN Java disbeliever who said its too much effort.

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

#192

Post by kaba0 »

josefx wrote: post #164
kaba0 wrote: post #67

Earlier quoted context omitted.

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.

> they are the ones that open-sourced the platform completely While I agree with the bullshit claim, Sun was the company to open source Java. Which itself goes back to IBM blocking the community process in order to force an Apache licensed Java implementation, Sun releasing the OpenJDK made most people happy without killing its embedded cash cow.

completely is the important word — there were plenty of paid-only tools back then that were part of OracleJDK but not OpenJDK. Oracle made them open-source.

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

#193

Post by tsss »

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.

The younger generation chose Go because they're dumb and fell for the Google marketing hype. Most of them have never even used Java outside of school.

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

#194

Post by Rapzid »

kaba0 wrote: post #129
pharmakom wrote: post #65

Earlier quoted context omitted.

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

You don’t become a first class citizen overnight. Also, last time I checked .NET lacks something as trivial as an open-source debugger.

It's been many moons, also there is an OSS debugger produced by Samsung.

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

#195

Post by kaba0 »

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…

Gradle is a better build tool from a purely architectural point of view (though it is quite disliked, I believe mostly due to the ultra-complex android build system being built on top and giving it a bad name), but the Maven repo system is absolutely better than most contemporary repositories, proved by its comparably rare side-chain attacks.

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

#196

Post by mahmoudimus »

impulser_ wrote: post #58
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 p…

In 2010, I think arguing that relying on the JVM would be an acceptable gripe. However, it is 2023, almost all of your stated issues have been (IMHO quite elegantly) addressed WITH the added benefit (or maybe detriment?) of backwards compatibility in modern versions of Java and the _incredible_ engineering behind the JVM.

I would actually argue the inverse. Between the two languages, Go would be my second choice precisely because it does NOT have the JVM. Even though I have used GraalVM for AOT, with Docker / containerd, I would take the JVM any day. It's just night & day when operating something in production.

That being said, Go still has a lighter resource footprint but I found Go to be a better Python alternative than Java.

Here are some IMHO acceptable gripes with Java:

- Java represents strings using UTF-16 (although there are optimizations introduced in Java9+ already to use LATIN1 / ascii encoding if you don't need to use Unicode)

- Java makes it difficult to have steady state memory consumption (by design)

- Java's escape analysis is primitive

- Java is missing value types (coming soon!)

I think Go is great, but IMHO modern Java is just better at building backend systems.

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

#197

Post by hugofirth »

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

I wish Swift wasn’t so tied to the Apple ecosystem, as it has (IMO) a good mix of these

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

#198

Post by kaba0 »

Quekid5 wrote: post #190
gpderetta wrote: post #151

Earlier quoted context omitted.

No. Both type erasure and monomorphization have always been legitimate ways to compile generic code. IIRC, the issue with Java is that type erasure is sometimes a leaky abstraction.

What exactly do you mean by "leaky" here? Can you give an example? My main issue with non-erased generics is that they actually break reasoning wrt. parametric polymorphism as soon as you allow for pattern matching or even just .isInstanceOf on type parameters. Suddenly a function which takes a List can do entirely different things depending on what A is... and that takes away a powerful reasoning tool.

It’s leaky due to reflection, but type erasure is not a problem in itself. .NET did away with type erasure, but it had a cost in terms of language ecosystem of the platform - not erasing List into List will bake the variance of List into the runtime, and thus other languages have to use the same model.

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

#200

Post by [deleted] »

Cthulhu_ wrote: post #89
kaba0 wrote: post #69

Earlier quoted context omitted.

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.

Citation needed; first off, verbosity is not the problem, verbosity is NEVER the problem; any significant codebase will end up with millions of LOC (and tokens) regardless of language choice. Second, Java's infamous for having VeryLongClassNameFactoryBeans on the one hand, and deep class hierarchies on the other, with new classes being declared for everything. Third, it depends. You can set up a HTTP server in two or…

[deleted]
Post reply on HN