OpenJDK Java 22 Rolls Into GA With New Features

[Saljack]

- System-starving memory requirements due to huge object size

- 8 bytes + value for any object ( I don't remember exactly )
- 34 bytes + content for any string

There is the project Lilliput https://openjdk.org/projects/lilliput/

[piotrj3]

Sorry, this isn't remotely true. Go's concurrency/async model is light-years beyond .NET

Except that Go's goroutines can work on different machines I don't see a part of Go that is superior to C#'s Tasks.

And in case of Async/await, Go doesn't have them. You can do it a bit more ugly way but in C# you just have keywords async/await and they exist since 2011. If that is best or not, it is up for debate, but according to Wiki, F# was literally first language to support async/awat in 2007, and later it was added to C#. Meanwhile Yield/Tasks are things even way older in C#. And people do like it, only issue i heard from C# corporate programmers with it (I am not C# programmer myself, but worked with a ton of them), is sometimes they pollute call stack when you are using them.

I would say Go's channels is something quite excellent but C# also has fields were you can write what you want asynchronously/concurrent in simpler, shorter code.

[bug77]

that's my personal perception of fear, when it comes to concurrency:

Go: fearless to write / a bit less fearless when running (there's a lot of errors you can make that could explode at runtime)
Rust: definitely not fearless when writing (!!!) / absolutely fearless to run once you get it to compile 🙂
Java: a good balance of the two

You probably didn't give it much effort.

Go is as "fearless" as Rust, only the "do not alter a structure that you have sent over a channel "is a gentleman's agreement, it's not compiler-enforced like Rust. If you abide by that agreement, you're fine.
Rust is definitely not hard to write, it just takes some effort to shake off bad habits you might have picked up while using other languages.
Java can be seen as "a good balance" since by now it includes everything and the kitchen sink. But that makes it a tall order for someone new to the language: when should you use what? It offers neither the simplicity of Go nor the safety of Rust. So it can be seen as the worst of both worlds, too.

Edit: Just to be clear: multithreading is hard. Solutions like Go, that offer something straightforward to use only give the user just a facade to the multithreading problem as a whole. That in itself had pros and cons (but in the context of Go, it does precisely what it's intended to do). As usual: pick the right tool for the job you need to accomplish, don't blame the language.

[Amaranth]

Except that Go's goroutines can work on different machines I don't see a part of Go that is superior to C#'s Tasks.

And in case of Async/await, Go doesn't have them. You can do it a bit more ugly way but in C# you just have keywords async/await and they exist since 2011. If that is best or not, it is up for debate, but according to Wiki, F# was literally first language to support async/awat in 2007, and later it was added to C#. Meanwhile Yield/Tasks are things even way older in C#. And people do like it, only issue i heard from C# corporate programmers with it (I am not C# programmer myself, but worked with a ton of them), is sometimes they pollute call stack when you are using them.

I would say Go's channels is something quite excellent but C# also has fields were you can write what you want asynchronously/concurrent in simpler, shorter code.

The problem with async/await is famously described in What Color is Your Function? while Go and Java (via virtual threads) avoid this problem. On the other hand async/await is theoretically more performant and uses less memory because you only store the state that matters instead of a whole thread stack and you can more precisely schedule things. Using an async/await system also allows plugging in a custom runtime to manage this even if C# doesn't expose that. That's how in Rust some things are using async/await for interrupt handlers on microcontrollers and such. So really it's a trade off between ease of use/ease of adoption on one side (goroutines/virtual threads) and theoretical performance and flexibility on the other (async/await).

[mSparks]

bellsoft jre's work well.

https://bell-sw.com/pages/downloads/#jdk-21-lts

jlink is really a myth, last I checked it couldnt build a working modules file for windows, and there is a load of completely unnecessary garbage gets added.

OTOH, Java 17 was a solid upgrade from 8 (decent memory footprint decreases and perf inprovements), and looks like it continues to improve.

[partcyborg]

Except that Go's goroutines can work on different machines I don't see a part of Go that is superior to C#'s Tasks.

And in case of Async/await, Go doesn't have them. You can do it a bit more ugly way but in C# you just have keywords async/await and they exist since 2011. If that is best or not, it is up for debate, but according to Wiki, F# was literally first language to support async/awat in 2007, and later it was added to C#. Meanwhile Yield/Tasks are things even way older in C#. And people do like it, only issue i heard from C# corporate programmers with it (I am not C# programmer myself, but worked with a ton of them), is sometimes they pollute call stack when you are using them.

I would say Go's channels is something quite excellent but C# also has fields were you can write what you want asynchronously/concurrent in simpler, shorter code.

Go doesn't have those explicit keywords, but with goroutines and channels you can implement the exact same thing. There are tons of async libraries for go implemented this way. That is the beauty and superiority of go, you can do so much more with less

[bug77]

I’m a little unclear on modern Java. Why is it the JDK is rapidly developing through versions but JRE remains at v8. Is the JRE versioning just a compatibility thing and it can run code from the latest JDK?

While there isn't a JRE as such anymore, Linux distros usually offer openjdk-XX and openjdk-XX-devel packages. The former is akin to the old JRE, the latter is the actual JDK.
And I agree, jlink has little-to-no adoption right now.

[mSparks]

Go doesn't have those explicit keywords, but with goroutines and channels you can implement the exact same thing. There are tons of async libraries for go implemented this way. That is the beauty and superiority of go, you can do so much more with less

I really like the where GO seems to be going, I think its a big leap to suggest its as mature as Java yet, but the progress there is nothing short of phenominal.

OTOH

https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-ride

[bug77]

I really like the where GO seems to be going, I think its a big leap to suggest its as mature as Java yet, but the progress there is nothing short of phenominal.

OTOH
https://fasterthanli.me/articles/i-w...angs-wild-ride

"Go doesn't have generics"... How old is that article?
I agree it's not a perfect solution for everything, but for not-so-skilled developers, it's a Godsend. I was recently doing a presentation of Go, I wrote some code to show how to exercise concurrency and after I wrote it, it struck me: the code worked from the first try! That's where Go really shines.

[mSparks]

"Go doesn't have generics"... How old is that article?

Feb 28, 2020 with an April 2022 Update, its also not what it says.

I agree it's not a perfect solution for everything, but for not-so-skilled developers, it's a Godsend. I was recently doing a presentation of Go, I wrote some code to show how to exercise concurrency and after I wrote it, it struck me: the code worked from the first try! That's where Go really shines.

That wasn't really the key take aways, that would be:

"making the result "production-ready" is left as an exercise to the writer. Big companies that have adopted it have developed tons of tooling around it, use all available linters, do code generation, check the disassembly, and regularly pay the engineering cost of just using Go at all."
and
"Or rather, it's a half-truth that conveniently covers up the fact that, when you make something simple, you move complexity elsewhere."

Both of which are where java shines (you shift the complexity to a self contained jar), and are pretty much essential to getting software to the point it actually pays the bills (aka production ready).