[aturon]

Yes -- the blog post didn't go into details about this, but Futures in general have an error type as well, and all the combinators know how to propagate errors correctly. (There's also a notion of "cancellation" for a future -- we'll get into this with later posts).

In terms of debugging, there's not infrastructure currently, but the kind of thing you're talking about should be easy to add!

[KirinDave]

I've used async tooling extensively on several platforms now, including Go, C#, Java, Clojure's core async, the new async methods in JS.

The challenge of these state machine codegen abstractions is not performance. It's making source-facing debuggers do the right thing and handle errors in a way that doesn't break the illusion that the code running is the code in source.

If you can match the degree of support C# has for error handling, you'll be in an amazing place.

[skybrian]

It would be useful to give a Future a name (for debugging) in the code that creates it, so a list of "pending jobs" is more readable. I don't think any other language is doing that.

Like other kinds of debugging info, you might also want a way to strip out the job names in a production build.