Hacker News: cowboyd

New comment by cowboyd in "You can't cancel a JavaScript promise (except sometimes you can)"

cowboyd — Tue, 07 Apr 2026 19:41:14 +0000

I think writing an effect library yourself is a tough ask, but some of them have gotten really, really good. And they get you things that are simply not possible with promise. Check out Effection if you want a more vanilla javascript syntax, or Effect if you're really into expressing things functionally.

New comment by cowboyd in "You can't cancel a JavaScript promise (except sometimes you can)"

cowboyd — Tue, 07 Apr 2026 18:45:50 +0000

Is it safe to just "stop calling next() on a generator?" like the post suggest?

To me that sounds like dropping the task on the floor. Specifically, this will not invoke any finally {} blocks:

More correctly, you should invoke `return()` on the generator. Otherwise, you won't provide execution guarantees. This is how Effection does it. There is no equivalent in async functions, so it sounds like the same problem would apply to the GC technique.

New comment by cowboyd in "Delimited Generators – A more natural API for JS generators"

cowboyd — Sun, 05 May 2024 21:57:42 +0000

JavaScript generators are unmined gold! We've done a lot of usage of JavaScript generators as delimited continuations; using them to implement the classic shift/reset operations in JavaScript. https://github.com/thefrontside/continuation

Built on those delimited continuations is structured concurrency for JavaScript (https://frontside.com/effection)

New comment by cowboyd in "Show HN: Starfx – A modern approach to side-effect and state management in UI"

cowboyd — Fri, 01 Mar 2024 17:16:51 +0000

> yes but what do I say to my colleagues when they realize they need to learn generators (it's a non-trivial hurdle for many people)

Just tell them that they already know them.

`yield*` is

- a superset of `await` so if you understand `await`, you understand `yield*`

- infinitely more powerful because it can handle any effect, not just Promise resolution.

- It's just javascript syntax that predates `await`

Effection 3.0 – Structured Concurrency and Effects for JavaScript

cowboyd — Mon, 18 Dec 2023 17:28:15 +0000

Article URL: https://frontside.com/blog/2023-12-18-announcing-effection-v3/

Comments URL: https://news.ycombinator.com/item?id=38685475

Points: 6

# Comments: 2

New comment by cowboyd in "The Await Event Horizon in JavaScript"

cowboyd — Mon, 11 Dec 2023 19:57:20 +0000

JavaScript’s async/await constructs have a critical lack of power which makes them unsuitable to implement structured concurrency.

The Await Event Horizon in JavaScript

cowboyd — Mon, 11 Dec 2023 19:57:20 +0000

Article URL: https://frontside.com/blog/2023-12-11-await-event-horizon/

Comments URL: https://news.ycombinator.com/item?id=38604684

Points: 6

# Comments: 2

New comment by cowboyd in "Structured Concurrency"

cowboyd — Mon, 21 Mar 2022 09:19:23 +0000

For those interested in exploring Structured Concurrency in JavaScript, there is https://frontside.com/effection

New comment by cowboyd in "Structured Concurrency"

cowboyd — Mon, 21 Mar 2022 09:11:40 +0000

I think the simplest expression of the idea of structured concurrency that I've come across is this: The scope of any concurrent process is the same as the lexical scope of the function that created it. This has profound implications.

Let's say, for example that I call `doTasks()` with 10 separate tasks. Before any of them can complete, one of them fails. What happens to the other 9? In your example, they are "leaked" because they will continue running, even though the scope that was awaiting their results in gone. Using a "worker pool" as in the example, it might go something like this:

  async function doTasks(tasks = []) {
    let workerpool = new WorkerPool();
    try {
      for (let task of tasks) {
        workerpool.exec("my task", task);
      }
      let results = await workerpool.all();
      // do stuff with results
    } finally {
      // no matter the outcome, nothing outlives this scope.
      await workerpool.destroy();
    }
  }

It should be noted that cancellation, i.e. the ability to "destroy" a concurrent task is a necessary primitive for structured concurrency. You can think of it as the equivalent of automatically releasing memory at the end of a lexical scope.

There is already an implementation of Structured Concurrency for JavasScript here https://frontside.com/effection

New comment by cowboyd in "Effection: For When Async/Await Is Not Enough"

cowboyd — Tue, 23 Nov 2021 10:16:46 +0000

> I'm not sure I buy the premise for the library's existence, at least with how the author describes it.

Just do a google search for "structured concurrency". These ideas did not come out of a vacuum, but instead from years of research in language communities ranging from C/C++ to Java, Swift, and Python. Effection is just these same ideas projected into the world of JavaScript.

You may find the following resources are helpful

- https://vorpus.org/blog/notes-on-structured-concurrency-or-g...

- https://elizarov.medium.com/structured-concurrency-722d765aa...

- https://openjdk.java.net/jeps/8277129

- https://www.wwdcnotes.com/notes/wwdc21/10134/