3 ms·

Effection 3.0 – Structured concurrency and effects for JavaScript

37 points by hackandthink 3y ago

slaymaker1907 3y ago
I really wish JS had some sort of preemption for stuff like this. We have web workers now, but those work more like starting up another process since you can't pass functions to them.
- cyanydeez 3y ago
  was just reading the promise black hole and the use of generators to ensure process chain terminations is definitely a missing problem that workers don't solve. unless you're referring to a brute force one-off shutdown.
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/
theogravity 3y ago
> Just over five years ago, in November of 2018, when Structured Concurrency was a little-known peculiarity, First time hearing about it. Wish the post would at least link to what it is.
- starlevel003 3y ago
  https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/ https://vorpus.org/blog/notes-on-structured-concurrency-or-g...
chalsprhebaodu 3y ago
function* operation() { //@ts-expect-error `string` is not assignable to `number`! let count = yield* createString(); return count.toExponential() } Is this a typo? How does the compiler know that count should be a number?

37 points by hackandthink 3y ago

slaymaker1907 3y ago

I really wish JS had some sort of preemption for stuff like this. We have web workers now, but those work more like starting up another process since you can't pass functions to them.

cyanydeez 3y ago
was just reading the promise black hole and the use of generators to ensure process chain terminations is definitely a missing problem that workers don't solve. unless you're referring to a brute force one-off shutdown.

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/

theogravity 3y ago

> Just over five years ago, in November of 2018, when Structured Concurrency was a little-known peculiarity, First time hearing about it. Wish the post would at least link to what it is.

starlevel003 3y ago
https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/ https://vorpus.org/blog/notes-on-structured-concurrency-or-g...

chalsprhebaodu 3y ago

function* operation() { //@ts-expect-error `string` is not assignable to `number`! let count = yield* createString(); return count.toExponential() } Is this a typo? How does the compiler know that count should be a number?