6 ms·

I don't think anyone would enjoy going back to goroutines (threads) after async/await. Multithreaded code is actually much harder to write and deal with. Go is

I don't think anyone would enjoy going back to goroutines (threads) after async/await. Multithreaded code is actually much harder to write and deal with. Go is inappropriate example here.

WoodenChair 8y ago
Goroutines are not threads: https://rcoh.me/posts/why-you-can-have-a-million-go-routines-but-only-1000-java-threads/ https://rcoh.me/posts/why-you-can-have-a-million-go-routines...
- zzzcpan 8y ago
  https://en.wikipedia.org/wiki/Thread_(computing)#M:N_(hybrid_threading) https://en.wikipedia.org/wiki/Thread_(computing)#M:N_(hybrid...
  - giancarlostoro 8y ago
    Goroutines are probably closer to Fibers which D also has: https://en.wikipedia.org/wiki/Fiber_(computer_science) https://en.wikipedia.org/wiki/Fiber_(computer_science)
    - zzzcpan 8y ago
      They used to be closer to fibers years ago, when they were running on a single thread by default. Now they behave exactly like normal threads with the same problems. And fibers are threads anyway.
      - giancarlostoro 8y ago
        Care to share a reference to them no longer being lightweight?
        zzzcpan 8y ago
        They still start with tiny stacks, if that's what you are asking. I believe it's somewhere around 2 KB nowadays.
      - hu3 8y ago
        goroutines are anything but threads. Here's a 40min talk explaining how Go's scheduler works: https://youtu.be/YHRO5WQGh0k https://youtu.be/YHRO5WQGh0k
        zzzcpan 8y ago
        No, they are threads. It doesn't matter if they start with tiny growing stacks and whether blocking syscall wrappers call into the scheduler. Those are just implementation details.
- Groxx 8y ago
  I mean, sure, but they have all the same problems as threads for most / application-level developers. They're indeed quite different when you get into calling out to C or other kinds of FFI, but relatively few developers need to do so directly. For everyone else, they come with very nearly exactly the same semantics as threads.
tiuPapa 8y ago
I have used both and its hard to argue that goroutines and channels are as easy to use as async/await.
- weberc2 8y ago
  On the surface, perhaps, but when you factor in the gotchas of both approaches and the debugging difficulty, I much prefer goroutines. In particular, I’ve never witnessed someone DOS a fleet of servers in Go by scheduling a task was making a sync call under the covers, by doing an intensive computation in the event loop, or by scheduling tens of thousands of tiny events. We also have a lot of bugs involving accidentally putting the task/coroutine into a variable instead of the result of the task because the programmer forgot the “await” keyword, but that’s a dynamic typing problem.
tigershark 8y ago
Goroutines are not threads. Async await behind the scenes uses threads.
- wallstop 8y ago
  Does it? https://blog.stephencleary.com/2013/11/there-is-no-thread.html https://blog.stephencleary.com/2013/11/there-is-no-thread.ht...
  - tigershark 8y ago
    In that case and in some others it doesn’t, but in general it does: https://stackoverflow.com/questions/17661428/async-stay-on-the-current-thread https://stackoverflow.com/questions/17661428/async-stay-on-t... Probably it makes sense to say that async await can try to use a continuation passing style or run on a different thread because there is no actual guarantee that it will use one or the other.

I don't think anyone would enjoy going back to goroutines (threads) after async/await. Multithreaded code is actually much harder to write and deal with. Go is inappropriate example here.

WoodenChair 8y ago

Goroutines are not threads: https://rcoh.me/posts/why-you-can-have-a-million-go-routines-but-only-1000-java-threads/ https://rcoh.me/posts/why-you-can-have-a-million-go-routines...

zzzcpan 8y ago
https://en.wikipedia.org/wiki/Thread_(computing)#M:N_(hybrid_threading) https://en.wikipedia.org/wiki/Thread_(computing)#M:N_(hybrid...
- giancarlostoro 8y ago
  Goroutines are probably closer to Fibers which D also has: https://en.wikipedia.org/wiki/Fiber_(computer_science) https://en.wikipedia.org/wiki/Fiber_(computer_science)
  - zzzcpan 8y ago
    They used to be closer to fibers years ago, when they were running on a single thread by default. Now they behave exactly like normal threads with the same problems. And fibers are threads anyway.
    - giancarlostoro 8y ago
      Care to share a reference to them no longer being lightweight?
      - zzzcpan 8y ago
        They still start with tiny stacks, if that's what you are asking. I believe it's somewhere around 2 KB nowadays.
    - hu3 8y ago
      goroutines are anything but threads. Here's a 40min talk explaining how Go's scheduler works: https://youtu.be/YHRO5WQGh0k https://youtu.be/YHRO5WQGh0k
      - zzzcpan 8y ago
        No, they are threads. It doesn't matter if they start with tiny growing stacks and whether blocking syscall wrappers call into the scheduler. Those are just implementation details.
Groxx 8y ago
I mean, sure, but they have all the same problems as threads for most / application-level developers. They're indeed quite different when you get into calling out to C or other kinds of FFI, but relatively few developers need to do so directly. For everyone else, they come with very nearly exactly the same semantics as threads.

tiuPapa 8y ago

I have used both and its hard to argue that goroutines and channels are as easy to use as async/await.

weberc2 8y ago
On the surface, perhaps, but when you factor in the gotchas of both approaches and the debugging difficulty, I much prefer goroutines. In particular, I’ve never witnessed someone DOS a fleet of servers in Go by scheduling a task was making a sync call under the covers, by doing an intensive computation in the event loop, or by scheduling tens of thousands of tiny events. We also have a lot of bugs involving accidentally putting the task/coroutine into a variable instead of the result of the task because the programmer forgot the “await” keyword, but that’s a dynamic typing problem.

tigershark 8y ago

Goroutines are not threads. Async await behind the scenes uses threads.

wallstop 8y ago
Does it? https://blog.stephencleary.com/2013/11/there-is-no-thread.html https://blog.stephencleary.com/2013/11/there-is-no-thread.ht...
- tigershark 8y ago
  In that case and in some others it doesn’t, but in general it does: https://stackoverflow.com/questions/17661428/async-stay-on-the-current-thread https://stackoverflow.com/questions/17661428/async-stay-on-t... Probably it makes sense to say that async await can try to use a continuation passing style or run on a different thread because there is no actual guarantee that it will use one or the other.