Hacker News Reader

Comment by lukaslalinsky | Hacker News Reader

No, that's not the best description. The Io interface is actually one of the best cancellation stories out there. If you combine it with defer/errdefer, you get safer cancellation guarantees than you have in async Rust (you can do async "drop" for example). The only problematic part is the interaction between the Reader/Writer interface and the Io interface, with regards to error handling.

View on HN

> The only problematic part is the interaction between the Reader/Writer interface and the Io interface, with regards to error handling.

The fact that error handling suffers when combining two of the base interfaces of the standard library is pretty rough though? I don't think rust has that particular problem.

It's a different approach to Rust. There, if you cancel a future, it stops polling and runs the Drop interface. You don't get to do more complex cleanup. But, at the same time, because cancellation is not an error that all functions have to propagate, it's structurally not possible to ignore it. Zig, like many other languages, uses a specific error to indicate cancellation. The application can decide what to do with it, it has some benefits. But unlike Python/Java where exceptions can he thrown from anywhere, Zig errors need to be named and that's where to issues comes from, because the Reader/Writer interfaces no longer are generic, they can't pass the concrete errors returned from the implementations, and cancellation is one of the errors that get hidden that way. It's a comprise either way, Zig would need to have first class support for comptime interfaces/traits to solve it better, but that's not going to happen. So in the meantime, there is a dilema how to handle it, but I'm sure it will get solved, or at least best practices will get developed.

I am not really convinced that new best practices will be developed or in included in the standard library because andrew thinks that there isn't an issue.

I have a partially written blog post in my head, as I've spent a lot of time thinking about the problem. I'd have preferred if there was a change to the reader/writer interfaces, but even without it, I'm starting to see patterns that work and can be applied to any code to make it safe. People just need to be aware of the problem and that's my goal, although I'm probably failing if my tone is creating the drama, so I'm learning how to communicate it better.

I don't think you are creating any drama to be honest. I understand how frustrating it must be.

There is a similar issue in kotlin where a cancellation is marked via a CancellationException but that extends IllegalStateException and thus Exception. Because of that it gets caught and swallowed all the time. This is a constant source of bugs for me at work and google has resorted to a bunch of linting to get around this design mistake.

The most frustrating part about it for me it's Andrew's argument: just write correct code. I have C at home.

In the future, tooling can run those checks statically on IR.

Unfortunately, it you want to handle errors right, it's overly verbose, so no one really does it. That's my problem really. Even in the blog post snippet, I could have show well behaved code, because I'm well aware of it, but then the error handling would be more code than the part I'm trying to showcase. Static analysis will not help there.

In the future, it would be good to not need to require that unwritten tooling

Yeah, I feel Andrew's tooth brushing argument is quite weak here. It is basically the same as the defence of C's error handling, which Zig fixed.

Cancellation in Rust is problematic too but for other reasons than cancellation in Zig is problematic. Maybe there is just no free lunch here, but hopefully it can be fixed in Zig and Rust.

Reply on news.ycombinator.com