3 ms·

> Unlike Promises and async/await, Effection is fundamentally synchronous in nature My understanding is that async/await is fundamentally synchronous. Your JS

by jemmyw 3y ago

> Unlike Promises and async/await, Effection is fundamentally synchronous in nature My understanding is that async/await is fundamentally synchronous. Your JS code runs on a single thread, as far as you're aware, unless you use workers (browser) or child processes (node). I don't think I've ever seen a situation where that is not the case. Is there a place where the use of promises is actually concurrent? Other than that, it's a nice library, but I wouldn't go for it myself. I'd rather see improvements to await/async than trying to patch around it with a different API. I've seen a few libs over the years using generators to simulate await and in every case you go back later and get confused by what is going on.

cyanydeez 3y ago
it uses generators. those generators basically allow tearing down promises inflight with allowing them to "return" it solves the problem of uncancelable side effects and nested promises failing without clean up. if you traded callback he'll for try catch ad nausea control, this cleans up nested promises.
mpalmer 3y ago
How do you account for the behavior of Promise.all? Or do you mean parallel?
- chpatrick 3y ago
  Promise.all is just a for loop that awaits all the promises. They still don't run concurrently. The way JS works is that some event happens, which can cause some handler to run. When it's finished, the next event handler runs. But no two pieces of code execute at the same time in the same context.
- jemmyw 3y ago
  They don't run any js code concurrently. They'll call into native code that does run concurrently, or at least concurrent io, but when it gets back to your js code it is all synchronous.
vanderZwan 3y ago
> My understanding is that async/await is fundamentally synchronous. Your JS code runs on a single thread, as far as you're aware, unless you use workers (browser) or child processes (node). You're talking about paralellism. Concurrency is not parallelism. Synchronous and asynchronous concurrency can both run single-threaded. They behave very differently however. Asynchronous basically is about offloading work to be automatically resumed at some point in the future - both in the form of currently active code being able to schedule code for later, as well as incoming events being suspended and queued up to be handled after the current bit of code finishes running. Synchronous concurrency essentially revolves around being able to suspend the current bit of code until explicitly resumed - coroutines are an example, but it may also be in the form of "suspend this code block until a certain event happens", like in Céu. This has the advantage of being deterministic in behavior (unlike asynchronous code). It also has very low memory overhead compared to other paradigms. This makes it extremely useful in embedded real-time systems, hence the existence of languages like Esterel and Céu specifically with that target in mind[0][1][2]. [0] https://en.wikipedia.org/wiki/Synchronous_programming_language https://en.wikipedia.org/wiki/Synchronous_programming_langua... [1] https://en.wikipedia.org/wiki/Esterel https://en.wikipedia.org/wiki/Esterel [2] http://www.ceu-lang.org/ http://www.ceu-lang.org/

by jemmyw 3y ago

cyanydeez 3y ago

it uses generators. those generators basically allow tearing down promises inflight with allowing them to "return" it solves the problem of uncancelable side effects and nested promises failing without clean up. if you traded callback he'll for try catch ad nausea control, this cleans up nested promises.

mpalmer 3y ago

How do you account for the behavior of Promise.all? Or do you mean parallel?

chpatrick 3y ago
Promise.all is just a for loop that awaits all the promises. They still don't run concurrently. The way JS works is that some event happens, which can cause some handler to run. When it's finished, the next event handler runs. But no two pieces of code execute at the same time in the same context.
jemmyw 3y ago
They don't run any js code concurrently. They'll call into native code that does run concurrently, or at least concurrent io, but when it gets back to your js code it is all synchronous.

vanderZwan 3y ago

> My understanding is that async/await is fundamentally synchronous. Your JS code runs on a single thread, as far as you're aware, unless you use workers (browser) or child processes (node). You're talking about paralellism. Concurrency is not parallelism. Synchronous and asynchronous concurrency can both run single-threaded. They behave very differently however. Asynchronous basically is about offloading work to be automatically resumed at some point in the future - both in the form of currently active code being able to schedule code for later, as well as incoming events being suspended and queued up to be handled after the current bit of code finishes running. Synchronous concurrency essentially revolves around being able to suspend the current bit of code until explicitly resumed - coroutines are an example, but it may also be in the form of "suspend this code block until a certain event happens", like in Céu. This has the advantage of being deterministic in behavior (unlike asynchronous code). It also has very low memory overhead compared to other paradigms. This makes it extremely useful in embedded real-time systems, hence the existence of languages like Esterel and Céu specifically with that target in mind[0][1][2]. [0] https://en.wikipedia.org/wiki/Synchronous_programming_language https://en.wikipedia.org/wiki/Synchronous_programming_langua... [1] https://en.wikipedia.org/wiki/Esterel https://en.wikipedia.org/wiki/Esterel [2] http://www.ceu-lang.org/ http://www.ceu-lang.org/