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…
Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
11–20 of 555 posts
Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#12Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#13So 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…
Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#14So 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…
Project Valhalla, and the foreign function and memory APIs in particular.
Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#15So 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…
while Java originated the billion dollar mistake
By the "billion dollar mistake", are you referring to null references [1]? But null references were introduced in 1965 in Algol, by Tony Hoare. They long predate Java.[1]: https://www.infoq.com/presentations/Null-References-The-Bill...
Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#16So 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…
ALGOL originated null
Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#17Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#18Well it's not really ushering it in, given that this is what Haskell has had for a decade at least.
Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#19So 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…
No. Go does containerized microservices better because of its lower memory footprint. If you can use GraalVM then that might not matter.
Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#20Earlier quoted context omitted.
ALGOL originated null
In ALGOL it was more like a thousand dollar mistake. It didn't become a billion dollars until Java caused NPEs on 3 billion devices