4 ms·

I think the only place that happens is in programming languages where you actually can choose to do something using a thread-blocking operation? Specifically, I

I think the only place that happens is in programming languages where you actually can choose to do something using a thread-blocking operation? Specifically, I've only seen it in Python. And yeah, it's not very ideal there. In other languages, it's typically only possible to do the operation in async mode, so you never write a foo_sync function in the first place.

throw10920 2y ago
The "it's typically only possible to do the operation in async mode" is part of the problem. If I'm writing a a batch script that parses a file as part of its operation, I don't want or need the read_file() function to be async! My code should just block until the file opens. Alternately, I want to be able to designate a computationally-intense function call (just that call, leaving the other calls alone) as async so that control yields to the event loop. The main problem is that someone got it in their head that the function definition was the right place to designate whether a function was async or not, and it's not. The right place is the call site.
- spankalee 2y ago
  > The main problem is that someone got it in their head This unnecessarily trivializes the technical problems at hand. This wasn't just something someone got in their head, especially considering... > that the function definition was the right place to designate whether a function was async or not, and it's not. The right place is the call site. This is exactly what JavaScript did. The program only yields at `await`ed callsites and doesn't yield at all other callsites. `async` only tells the VM to create the state machine necessary to resume the function after `awaited` calls return.
  - throw10920 2y ago
    > This unnecessarily trivializes the technical problems at hand. Making a language that automatically generates two versions of a function, one that is async and returns a Promise-wrapped object, and another that is sync, is not hard. > This is exactly what JavaScript did. No, it isn't. JavaScript requires you to declare functions as async at the function definition, and you can't call async functions from sync ones. This is exactly the thing I am arguing against, and is the opposite of "The right place is the call site."
    - spankalee 2y ago
      If it wasn't hard, it would have been done. I suppose we should all await your backwards compatible proposal? > No, it isn't. Yes, actually, it is. Async functions are a concept that only affects the internal structure of a function - to generate the state machine that allows yielding at `await` keywords and resuming after they resolve. Externally they are no different from "sync" Promise-returning functions. So they only thing that async functions do is enable yielding at the callsite, the `await` keyword is what actually yields at the callsite and you can await anything, not just async functions. Again: > I want to be able to designate a computationally-intense function call (just that call, leaving the other calls alone) as async so that control yields to the event loop. This is what `await` is - `await` yields. Non-await calls don't yield.
      - throw10920 2y ago
        > If it wasn't hard, it would have been done. This comment shows a true departure from reality. Computing is filled to the brim with ideas that are easy but are not implemented for reasons other than difficulty. > I suppose we should all await your backwards compatible proposal? Your sarcasm merely helps to further demonstrate that you're not interested in a serious discussion. > Yes, actually, it is. Then it should be trivial for you to show me an instance of a sync function calling an async one, synchronously waiting for it, then getting back the return value, without clever hacks.
    - deleted 2y ago
      [deleted]

throw10920 2y ago

The "it's typically only possible to do the operation in async mode" is part of the problem. If I'm writing a a batch script that parses a file as part of its operation, I don't want or need the read_file() function to be async! My code should just block until the file opens. Alternately, I want to be able to designate a computationally-intense function call (just that call, leaving the other calls alone) as async so that control yields to the event loop. The main problem is that someone got it in their head that the function definition was the right place to designate whether a function was async or not, and it's not. The right place is the call site.

spankalee 2y ago
> The main problem is that someone got it in their head This unnecessarily trivializes the technical problems at hand. This wasn't just something someone got in their head, especially considering... > that the function definition was the right place to designate whether a function was async or not, and it's not. The right place is the call site. This is exactly what JavaScript did. The program only yields at `await`ed callsites and doesn't yield at all other callsites. `async` only tells the VM to create the state machine necessary to resume the function after `awaited` calls return.
- throw10920 2y ago
  > This unnecessarily trivializes the technical problems at hand. Making a language that automatically generates two versions of a function, one that is async and returns a Promise-wrapped object, and another that is sync, is not hard. > This is exactly what JavaScript did. No, it isn't. JavaScript requires you to declare functions as async at the function definition, and you can't call async functions from sync ones. This is exactly the thing I am arguing against, and is the opposite of "The right place is the call site."
  - spankalee 2y ago
    If it wasn't hard, it would have been done. I suppose we should all await your backwards compatible proposal? > No, it isn't. Yes, actually, it is. Async functions are a concept that only affects the internal structure of a function - to generate the state machine that allows yielding at `await` keywords and resuming after they resolve. Externally they are no different from "sync" Promise-returning functions. So they only thing that async functions do is enable yielding at the callsite, the `await` keyword is what actually yields at the callsite and you can await anything, not just async functions. Again: > I want to be able to designate a computationally-intense function call (just that call, leaving the other calls alone) as async so that control yields to the event loop. This is what `await` is - `await` yields. Non-await calls don't yield.
    - throw10920 2y ago
      > If it wasn't hard, it would have been done. This comment shows a true departure from reality. Computing is filled to the brim with ideas that are easy but are not implemented for reasons other than difficulty. > I suppose we should all await your backwards compatible proposal? Your sarcasm merely helps to further demonstrate that you're not interested in a serious discussion. > Yes, actually, it is. Then it should be trivial for you to show me an instance of a sync function calling an async one, synchronously waiting for it, then getting back the return value, without clever hacks.
  - deleted 2y ago
    [deleted]