4 ms·

In your examples you are explicitly handling the async nature of foo(). So you acknowedlge that there is a difference and you even use specific syntax to deal w

In your examples you are explicitly handling the async nature of foo(). So you acknowedlge that there is a difference and you even use specific syntax to deal with it. The question is rather: is it possible to remove the await and just automatically rewrite every program to use await where necessary? And the answer is no, because with only sync functions you have the guarantee that if your thread crashes, every code immediately stops executing. Not so with async functions. Once they are run there is a chance that your own thread crashes but some other thread keeps executing more code, at least for some time, potentially executing side effects. It cannot be automatically decided if this is okay or not. Or to turn it around: the behaviour of a program that automatically awaits async functions (which formerly where sync) can be different.

pron 4y ago
I think we're talking past each other. There is a semantic difference between `asyncFoo()` and `blockingFoo()`, but not between `await asyncFoo()` and `blockingFoo()`, and not between `asyncFoo()` and `spawn blockingFoo()`. There's obviously a difference between launching an operation to run concurrently with the spawning code and launching an operation and awaiting its completion, but that difference does not require the introduction of an async/await feature, and is perfectly expressible with nothing but threads and synchronous code. In particular, there is no need for two separate syntactic domains between async and sync subroutines. Indeed, in Erlang, Go, and Java, all the same behaviour of async/await is achieved with no such need, and no need for different kinds of APIs.
- valenterry 4y ago
  > but not between `await asyncFoo()` and `blockingFoo()` Of course there is. The former constraints the type (or return-type) of the function it is used in, the latter does not. > but that difference does not require the introduction of an async/await feature I don't remember saying anything about async/await in my original post though.
  - pron 4y ago
    > Of course there is. The former constraints the type (or return-type) of the function it is used in, the latter does not. That's not a semantic difference, but a syntactic one. Syntactic differences are expressed by which programs are accepted or rejected by the language; semantic differences are expressed by programs exhibiting different behaviours. To show a semantic difference you need to find P and Q such that when the value of P is the same in the two programs, the value of Q could be different; that's what expresses the semantics of the code between P and Q. Again, there are some (e.g. P: `(t = currentThread(), true)`, Q: `currentThread() == t`), but they're purely technical. > I don't remember saying anything about async/await in my original post though. You said that the lack of need of a syntactic kind for asynchronous routines is a fallacy. It is not. Everything that you can describe with sync and async routines your can describe, with the same ease and semantics, with just sync routines and threads. There is no need for a special syntactic category of asynchronous subroutines.
    - valenterry 4y ago
      > Everything that you can describe with sync and async routines your can describe, with the same ease and semantics, with just sync routines and threads. There is no need for a special syntactic category of asynchronous subroutines. I agree with that statement. > semantic differences are expressed by programs exhibiting different behaviours. It can cause different behaviour whether code runs on the same thread or on a different one (see one of my other posts here). That doesn't have to happen in every program and it doesn't have to happen on each execution, but that still makes it a different behaviour - at least in my terminology. > You said that the lack of need of a syntactic kind for asynchronous routines is a fallacy. It is not. That's not what I said (or at least not what I meant). I meant that it is doomed to fail to try to generally unify sync and async code on a language (or runtime) level.
      - pron 4y ago
        When people say a language "unifies sync and async code" all they mean is that there is no distinct syntactic category for "async routines". Rather, asynchronous operations are expressed as regular (i.e. synchronous, blocking) methods spawned on another thread. Either you agree that there is no loss in what you can express or believe it is doomed to fail. I don't understand how you can do both.

pron 4y ago

I think we're talking past each other. There is a semantic difference between `asyncFoo()` and `blockingFoo()`, but not between `await asyncFoo()` and `blockingFoo()`, and not between `asyncFoo()` and `spawn blockingFoo()`. There's obviously a difference between launching an operation to run concurrently with the spawning code and launching an operation and awaiting its completion, but that difference does not require the introduction of an async/await feature, and is perfectly expressible with nothing but threads and synchronous code. In particular, there is no need for two separate syntactic domains between async and sync subroutines. Indeed, in Erlang, Go, and Java, all the same behaviour of async/await is achieved with no such need, and no need for different kinds of APIs.

valenterry 4y ago
> but not between `await asyncFoo()` and `blockingFoo()` Of course there is. The former constraints the type (or return-type) of the function it is used in, the latter does not. > but that difference does not require the introduction of an async/await feature I don't remember saying anything about async/await in my original post though.
- pron 4y ago
  > Of course there is. The former constraints the type (or return-type) of the function it is used in, the latter does not. That's not a semantic difference, but a syntactic one. Syntactic differences are expressed by which programs are accepted or rejected by the language; semantic differences are expressed by programs exhibiting different behaviours. To show a semantic difference you need to find P and Q such that when the value of P is the same in the two programs, the value of Q could be different; that's what expresses the semantics of the code between P and Q. Again, there are some (e.g. P: `(t = currentThread(), true)`, Q: `currentThread() == t`), but they're purely technical. > I don't remember saying anything about async/await in my original post though. You said that the lack of need of a syntactic kind for asynchronous routines is a fallacy. It is not. Everything that you can describe with sync and async routines your can describe, with the same ease and semantics, with just sync routines and threads. There is no need for a special syntactic category of asynchronous subroutines.
  - valenterry 4y ago
    > Everything that you can describe with sync and async routines your can describe, with the same ease and semantics, with just sync routines and threads. There is no need for a special syntactic category of asynchronous subroutines. I agree with that statement. > semantic differences are expressed by programs exhibiting different behaviours. It can cause different behaviour whether code runs on the same thread or on a different one (see one of my other posts here). That doesn't have to happen in every program and it doesn't have to happen on each execution, but that still makes it a different behaviour - at least in my terminology. > You said that the lack of need of a syntactic kind for asynchronous routines is a fallacy. It is not. That's not what I said (or at least not what I meant). I meant that it is doomed to fail to try to generally unify sync and async code on a language (or runtime) level.
    - pron 4y ago
      When people say a language "unifies sync and async code" all they mean is that there is no distinct syntactic category for "async routines". Rather, asynchronous operations are expressed as regular (i.e. synchronous, blocking) methods spawned on another thread. Either you agree that there is no loss in what you can express or believe it is doomed to fail. I don't understand how you can do both.