3 ms·

Are we talking about Rust or async/await syntax in the abstract? Async/await syntax is needed if you want to have a `with` block that managed resources across

Are we talking about Rust or async/await syntax in the abstract? Async/await syntax is needed if you want to have a `with` block that managed resources across co-routine boundaries. Consider Python's `async with` which will create a resource that is freed when the co-routine leaves the execution context. This is distinct from Java's try-with-resources which doesn't work with async code. So anytime you use `try (TelemetrySpan.start()) { blah.read().andThen(x->send(url);}` it doesn't do what anyone would ever want. Hopefully Loom fixes it. So the async and sync distinction is needed/useful if you have both.

bheadmaster 4y ago
> Async/await syntax is needed if you want to have a `with` block that managed resources across co-routine boundaries. I don't see what is the connection between async/await syntax and managing resources. The `with` block is just another mechanism for managing resources - Go has the `defer` statement which runs the deferred function at the end of currently executing function block, providing the equivalent functionality without need for async/await syntax. The `with` blocks could easily be implemented in Go, but Go doesn't like duplicating functionality in the language. > Consider Python's `async with` Python is a traditionally synchronous language, so the async/await syntax in Python is necessary if you want to use the async runtime, while still having compatible syntax with the traditional sync runtime. > So the async and sync distinction is needed/useful if you have both. Every sync call can be trivially modeled as an async call that is always awaited. If you want to bolt-on async runtime onto a sync runtime, you need async/await syntax. Other than that, I don't see the value it brings to a language at all.
- fnord123 4y ago
  Ok, I thought you were saying callback hell is cool. But I think you're saying async-first is the way it should be and the runtime should handle it. Which is a good idea in most cases. I think Go is pretty awesome for this approach.
gpderetta 4y ago
That's an advantage of async vs manual CPS. Green threads/coroutines allow stack based resource handling without the syntactic complexity of async.

bheadmaster 4y ago

> Async/await syntax is needed if you want to have a `with` block that managed resources across co-routine boundaries. I don't see what is the connection between async/await syntax and managing resources. The `with` block is just another mechanism for managing resources - Go has the `defer` statement which runs the deferred function at the end of currently executing function block, providing the equivalent functionality without need for async/await syntax. The `with` blocks could easily be implemented in Go, but Go doesn't like duplicating functionality in the language. > Consider Python's `async with` Python is a traditionally synchronous language, so the async/await syntax in Python is necessary if you want to use the async runtime, while still having compatible syntax with the traditional sync runtime. > So the async and sync distinction is needed/useful if you have both. Every sync call can be trivially modeled as an async call that is always awaited. If you want to bolt-on async runtime onto a sync runtime, you need async/await syntax. Other than that, I don't see the value it brings to a language at all.

fnord123 4y ago
Ok, I thought you were saying callback hell is cool. But I think you're saying async-first is the way it should be and the runtime should handle it. Which is a good idea in most cases. I think Go is pretty awesome for this approach.

gpderetta 4y ago

That's an advantage of async vs manual CPS. Green threads/coroutines allow stack based resource handling without the syntactic complexity of async.