[deepsun]

IMO, Kotlin coroutines are better of Go's goroutines, although they are a little different beasts to compare honestly (apples and oranges). Go inits goroutines on stack, but min size is 4KiB, so it's not trivial to grow them. Also you need to watch over and destruct goroutines manually to prevent memory leaks (using

   var wg = sync.WaitGroup
   defer wg.wait()

   wg.Add(1)
   go func() {
      defer wg.Done()
   }

)

And create a separate channel to return errors from a goroutine. Definitely more work.

[HendrikHensen]

Kotlin coroutines don't really exist. They're a (very neat) programming trick to support coroutine-like behavior on the JVM which doesn't support coroutines. If you look at the bytecode it produces, it honestly is a mess. And it colours your functions too: now you have be ever careful that if your function is running in a coroutine, there are certain things you should absolutely avoid doing in that function, or any function called by that function (like spinning the CPU on loop without yielding). In Go, you don't have to worry about any of this because the concurrency is built-in from the start.

Also I don't understand "it's not trivial to grow them". It is trivial to grow them, and that's why Go went this way. Maybe only 0.1% or fewer of use-cases will ever find any issues with the resizing stack (in fact probably the majority of uses are fine within the default starting stack size).

[gf000]

> Kotlin coroutines don't really exist. They're a (very neat) programming trick to support coroutine-like behavior on the JVM

Well, guess how coroutines are implemented in Rust/C++/everywhere else!

Nonetheless, I do think that java virtual threads are superior for the vast majority of use cases and they are a good default to reach for for "async" like code.

[Ternari]

>you need to watch over and destruct goroutines manually to prevent memory leaks

No, you don’t. Any stack-allocated resources are freed when the function returns. WaitGroup is just there for synchronization.

[zadikian]

It is, but your typical backend code isn't dealing with that most of the time. You can just use blocking I/O in handlers.