Earlier quoted context omitted.
Also true, but "use the decades old thread api" shouldn't count as a simplification, right?
It should when you can just block left and right.
Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
481–490 of 555 posts
Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#482Earlier quoted context omitted.
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.
I’m older generation, choose Go because it’s almost universally better for my use cases. But what would I know? I only worked in Java for 20+ years…
Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#483Earlier 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…
> I would say that Go's error handling is a billion dollar mistake as well. I think you'll need to substantiate that one with some solid evidence. I don't see anything wrong with Go's error handling that cannot be explained by developer choice.
Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#484So 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 has an obviously better type system How does Java have a better type system? Java's generics are unsound, while Go's generics are sound. Java's generics do type erasure, while Go does not. Java's type system is not unified, it does not have a top type (an int is not an Object, int vs. Integer etc.).
As of writing this comment, golang does not allow you to have generics on methods as far as I'm aware.
Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#485Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#486So 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 o…
Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#487Earlier quoted context omitted.
Also Groovy kinda sucks
They should just make the right decision and deprecate all Groovy in favor of Kotlin.
Unfortunately, Gradle is the best build tool I've used for complex systems. And it still fucking sucks.
Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#488What are these things? It sounds like it is a time-sliced sharing that offers only concurrency and not parallelism. In other words, it's a userland construct and not a kernel thread. Sounds more like GO coroutines but do we really need another name for them?
Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#489Earlier quoted context omitted.
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
#490Earlier quoted context omitted.
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.
The younger generations of coders are indeed more susceptible to hype, but if you go around dismissing things that are hyped, you're going to miss out on a lot of good things. I've got 15+ years of Java experience, and I think Go is a nice language and has some real strengths. From what I can see, the primary difference with Java isn't the build system or the binaries, it's the decision to strongly favor simplicity a…