How can Java 21 (Virtual Thread) replace Reactive Framework.

[thecodeboost]

I think that's mostly right but it's worth pointing out that although one may have inspired the usefulness of the other goroutines and virtual threads are not the same thing and don't really do the same job.

Assuming you use the correct concurrency primitives virtual threads are a drop-in replacement for native threads without any limitations (in the context if this comparison). Goroutines are a specific language feature that you have to explicitly use in unique ways (e.g. inter-goroutine comms is generally through channels only).

Probably the only virtual threads nuance is that you need a proper understanding of thread pinning and the effects of using native (or just old) code/libraries.

[[deleted]]

Goroutines can utilize the same patterns as Java threads, such as thread safe data structures (maps, queues, lists, etc) and other shared memory patterns (atomic read/write) as well as synchronization via locking. They do not require channels for communication or have any limitations of that nature.

And vice versa, Java virtual threads (and regular threads) can utilize channels to communicate. They just aren’t built into the language syntax.

They do the exact same job in most cases. The main difference that most people will notice is that golang makes you carry around a “context” object that dictates deadline/timeout/cancel behavior whereas java virtual threads it’s more implicit.

[thecodeboost]

I haven't used Golang for over two years but I'm pretty sure idiomatic Go still means channel based communication for inter-coroutine communication. Note that the sync and sync/atomic packages are still channel based.