3 ms·
No, I don't really agree. I don't like async because of something you accused conditions and restarts of: hidden control flow. In your example, I don't see any
by ghoward 4y ago
No, I don't really agree. I don't like async because of something you accused conditions and restarts of: hidden control flow.
In your example, I don't see any, which is great. But async can have hidden control flow. (I wonder why Andrew Kelley added it when he is so against even hidden function calls.)
On top of that, I don't think async is a good paradigm, but that's neither here or there to the conversation.
- Schroedingersat 4y agoThat's the entire point I'm making though...exception style semantics are the worst way of handling errors. Algebraic effects make it a little better. Error values are much better as a default paradigm. Ie. Zig's error system which is not based on algebraic effects is best in class. Async does carry that same cost, but it comes with capabilities you can't get otherwise and is optional. Any objections to it are a demonstration of my point, not a disagreement with it.
- ghoward 4y agoError values suffer from the pit of failure. If you forget to handle them correctly, you have a bug. See [1]. Exceptions are better than async because they do not "reify" stack frames, an incredibly terrible idea. I mean, it works, but it's not a good model, mentally or otherwise. [1]: http://joeduffyblog.com/2016/02/07/the-error-model/ http://joeduffyblog.com/2016/02/07/the-error-model/
- Schroedingersat 4y ago> Error values suffer from the pit of failure. If you forget to handle them correctly, you have a bug. See [1]. Then you put your value behind the error in the type...like rust or zig where you cannot ignore them. You keep describing the upsides of Zig's error system as reasons why something else is better.