Are these like javascript promises or goroutines?
More like goroutines. They remind me of Guile's fibers: https://github.com/wingo/fibers
Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
41–50 of 555 posts
Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#42So 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…
Will they provide automatic M:N multiplexing on OS threads, or is that something that needs to be handled by the user somehow?
Also, what about channels, and select semantics etc?
I think before those are in place, with good library support, it won't be very close to competing with Go.
Not to mention compilation to fully self-contained binaries.
Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#43So 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 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 versions, with ancient libraries, full of code nobody dares to touch in case something collapses. The same will happen to Go, and it'll happen to whatever popular language will displace Go as the trendy language to learn; it's just a consequence of keeping around legacy code and not spending the time and money on migrating as soon as possible.
Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#44Earlier 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. Java programmers I've seen don't use the latest idioms; they use pre-8.0 Enterprise Edition-ware because that's what they've been taught. It's a hideous sight and it has a lot of inertia. That's why I prefer kotlin.
Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#45So 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.
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.
Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#46So 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…
The linked article has zero references to golang, so it's unclear if the java community has other golang features they're planning on buying into.
This change improves Java/JVM capabilities and that's great. Java is a great language and it's nice that it is shaking off the stagnation/perception of stagnation it has acquired over the years. Golang also has really great capabilities and use cases. Having written tons of code in dozens of languages it seems to be folly to expect one language to rule them all. The features that you don't have are almost as important as the features you do have.
If Java is looking for additional golang cherrypicks I would love to see their start times improve (shortlived java processes are painful, Graal doesn't cover all uses). FFI even in Panama is much more boilerplate then CGO. Go's deployment story is so much cleaner and straightforward then Java. The amount of engineering hours saved through language/toolchain standardized formatting is just monumental. Those are just 3 things at random, their are a bunch of other great ideas to steal.
I also wouldn't throw any shade at Golang's vibrant library ecosystem. There are just so many great active projects written in pure go that make spinning up new services a joy.
Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#47So 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.
C# GC, MS and external libraries, build, docs, tools support (especially for Linux) are all worse than Java.
Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#48Well it's not really ushering it in, given that this is what Haskell has had for a decade at least.
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.)
Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#49So 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.
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.
Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#50Earlier 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.
I am not sure there is fear against Java as much as there are better alternatives for many use cases.