4 ms·

All async systems have pitfalls, I'd say core.async's are pretty minor compared to most other systems. You're right that `go` can encourage bloated functions a

All async systems have pitfalls, I'd say core.async's are pretty minor compared to most other systems. You're right that `go` can encourage bloated functions and it would be better if it, for example, handled exception propagation (I would guess every serious core.async user has written their own go-but-with-exception-handing macro, it's not hard but it is unfortunate duplication of effort). (I've never had to think about the state machine code when debugging and I've done a lot of core async debugging. That part really does seem to just work.)

KingMob 5mo ago
To be more clear, I didn't mean debugging the generated state machine itself. What I meant was, the use of the go state machine renders certain debugging techniques useless. E.g., stacktraces are less helpful, and js-debugger is pointless, since you can't guarantee the (js-debugger) will get grouped with the state you're trying to debug. Frequently print/tap is sufficient, but core.async/go narrows your options.