4 ms·

To me, this actually reads as a reason for function coloring. Your project makes guarantees that neatly match up to the division between async and sync code, an

by fwip 2y ago

To me, this actually reads as a reason for function coloring. Your project makes guarantees that neatly match up to the division between async and sync code, and it would be fundamentally incorrect to ever call a function marked as async from most points of your program flow. So in this case, it would be good that the language enforces this for you, right?

assbuttbuttass 2y ago
> it would be fundamentally incorrect to ever call a function marked as async from most points of your program flow For a language with async/await yes, you need to bifurcate your program into synchronous and asynchronous pieces, and be very careful to maintain that split. For a language with a synchronous thread abstraction like go, you simply don't need to create this artificial bifurcation in the first place
- fwip 2y ago
  Yes. The person I replied to described a situation that, to me, is made easier by this bifurcation.
  - eyelidlessness 2y ago
    Is it though? In a hypothetical JS with the possibility of, say, “decoloring” async functions—e.g. by optionally blocking on their resolved return value—the situation that function coloring helps… ceases to exist as a situation in need of helping in the first place. That would be broadly unappealing where single threaded, cooperative concurrency is a baseline assumption! But it’s more fair to say it’s a trade off, and it’s also fair to recognize the things made impossible by a trade off.
eyelidlessness 2y ago
Well, yes and no. Yes: because the language has distinct semantics for asynchrony which fundamentally* cannot be made synchronous, it is good that the language also makes that fundamental inability explicit, and inviolable. No: the above reasoning is inherently tautological! It’s effectively arguing that it’s good that the language doesn’t have a massive inconsistency between two deeply coupled aspects of the same semantics. That is good! But it’s the kind of good you kind of have to expect, or treat as a tragic design flaw in its absence. * There are some exceptions, but they’re generally esoteric or niche or have other important caveats.

by fwip 2y ago

assbuttbuttass 2y ago

> it would be fundamentally incorrect to ever call a function marked as async from most points of your program flow For a language with async/await yes, you need to bifurcate your program into synchronous and asynchronous pieces, and be very careful to maintain that split. For a language with a synchronous thread abstraction like go, you simply don't need to create this artificial bifurcation in the first place

fwip 2y ago
Yes. The person I replied to described a situation that, to me, is made easier by this bifurcation.
- eyelidlessness 2y ago
  Is it though? In a hypothetical JS with the possibility of, say, “decoloring” async functions—e.g. by optionally blocking on their resolved return value—the situation that function coloring helps… ceases to exist as a situation in need of helping in the first place. That would be broadly unappealing where single threaded, cooperative concurrency is a baseline assumption! But it’s more fair to say it’s a trade off, and it’s also fair to recognize the things made impossible by a trade off.

eyelidlessness 2y ago

Well, yes and no. Yes: because the language has distinct semantics for asynchrony which fundamentally* cannot be made synchronous, it is good that the language also makes that fundamental inability explicit, and inviolable. No: the above reasoning is inherently tautological! It’s effectively arguing that it’s good that the language doesn’t have a massive inconsistency between two deeply coupled aspects of the same semantics. That is good! But it’s the kind of good you kind of have to expect, or treat as a tragic design flaw in its absence. * There are some exceptions, but they’re generally esoteric or niche or have other important caveats.