4 ms·

Yes, the idea is that the thread that is executing this piece of code can "steal" other work when it is awaiting on either of those methods. Frankly, in the ca

Yes, the idea is that the thread that is executing this piece of code can "steal" other work when it is awaiting on either of those methods. Frankly, in the case of sequential flow like the above, I would rather write result = server.getStuff() second = server.getMoreStuff(result+1) print(result) and have the runtime automatically perform work-stealing for me. No need for awaits. They just litter the code. This is what Go does.

pjmlp 7y ago
Thus the FFI impact on Go when going over language boundary and workarounds like runtime.LockThread().
littlestymaar 7y ago
In Go you need to manually tell the runtime to spawn a goroutine with the `go` keyword, which also «litter» the code…
- bsaul 7y ago
  Except in practice, go keyword is used much more coarsly and sparingly because you can group all the block of function calls under one big go call. With async, every single function has to be flagged as beeing asynchronous and be called differently ( although maybe some modern languages have a way to group all the await calls ?)
  - littlestymaar 7y ago
    That's funny how gophers can at the same time defend the «explicitness» of the if-based error handling, and be annoyed to have syntactic annotations for the yield points for coroutines (because that's exactly what `await` is, versus the yield points silently added by the go compiler everywhere so the runtime can perform its scheduling).
    - bsaul 7y ago
      not sure who you're refering to.. i certainly don't like many aspects of the go language. goroutines and the "go" keyword isn't one of them.
d0mine 7y ago
Go does not do that implicitly, there is an explicit "go" syntax. Gevent in Python does something similar [implicit switching] using a dirty monkeypatching. It is great while it works. Sooner or later the explicit cooperative concurrency such as provided by async/await syntax wins (e.g., asyncio, trio, curio Python libraries)

pjmlp 7y ago

Thus the FFI impact on Go when going over language boundary and workarounds like runtime.LockThread().

littlestymaar 7y ago

In Go you need to manually tell the runtime to spawn a goroutine with the `go` keyword, which also «litter» the code…

bsaul 7y ago
Except in practice, go keyword is used much more coarsly and sparingly because you can group all the block of function calls under one big go call. With async, every single function has to be flagged as beeing asynchronous and be called differently ( although maybe some modern languages have a way to group all the await calls ?)
- littlestymaar 7y ago
  That's funny how gophers can at the same time defend the «explicitness» of the if-based error handling, and be annoyed to have syntactic annotations for the yield points for coroutines (because that's exactly what `await` is, versus the yield points silently added by the go compiler everywhere so the runtime can perform its scheduling).
  - bsaul 7y ago
    not sure who you're refering to.. i certainly don't like many aspects of the go language. goroutines and the "go" keyword isn't one of them.

d0mine 7y ago

Go does not do that implicitly, there is an explicit "go" syntax. Gevent in Python does something similar [implicit switching] using a dirty monkeypatching. It is great while it works. Sooner or later the explicit cooperative concurrency such as provided by async/await syntax wins (e.g., asyncio, trio, curio Python libraries)