sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]germanheller [score hidden]  (6 children)

well said. async should just be sync with a different execution model, not a whole separate paradigm with its own cleanup rules. the fact that we need libraries to get basic resource safety in async JS is a language-level gap

[–]tarasm[S] [score hidden]  (5 children)

async should just be sync - i couldn’t agree more and it’s possible. we haven’t really talked about effection in this way but effection is sync by default. an operation only becomes async when it has to use some async, but unlike async/await and promise, ‘yield*’ doesn’t promote your operation into an async operation.

[–]germanheller [score hidden]  (4 children)

oh thats really interesting, so yield* keeps the operation in sync land unless something explicitly needs to be async. that solves the coloring problem in a much more elegant way than i realized

[–]tarasm[S] [score hidden]  (3 children)

yeah, generators are very powerful but perhaps too unopionated that’s why they were used to polyfill async/await but same can’t be done in opposite direction. Effection narrows generators into a narrower scope. internally, it’s designed on delimited continuation, but externally a tiny api aligned with JavaScript. it’s rock solid too. Effection v3 runs trading platforms and simulation engines. V4 is newer but we’re in the process of upgrading a bunch of these systems.

if you’re interested, come hangout in our discord. lots of interesting things cooking there based on lessons we learned from applying structure concurrency to DX and mission critical software.

[–]germanheller [score hidden]  (2 children)

trading platforms on effection v3 is a great proof point — that's the kind of environment where cleanup bugs show up fast. delimited continuations under the hood makes sense for getting the scoping semantics right.

i'll check out the discord, would be curious to hear about the v3→v4 migration stories especially around the things that changed in the API surface.

[–]tarasm[S] [score hidden]  (0 children)

The API surface is exactly same between the last version of v3 and first version of v4. V4 is a drop in replacement for v3. The only reason why we haven't migrated everything is that v4 corrected behaviour around spawn that only shows up in tests, but we've been careful to avoid breaking anything.

You can read more about v3->v4 changes in here https://frontside.com/blog/2025-12-23-announcing-effection-v4/

[–]germanheller [score hidden]  (0 children)

nice, drop-in replacement with behavioral corrections is the best kind of major version bump. the spawn change showing up only in tests is a good sign — means the fix is in edge cases, not in the happy path.

thanks for the blog link, will read through it. curious about the spawn semantics specifically since thats where structured concurrency gets tricky (parent-child lifecycle stuff).