Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust RAII is better than the Haskell bracket pattern

snoyman.com

Post reply on HN
Print view View original

121–130 of 156 posts

Re: Rust RAII is better than the Haskell bracket pattern

#121

Post by electrograv »

pcwalton wrote: post #104
electrograv wrote: post #96

Earlier quoted context omitted.

The fact that this is not resolved after over a year is concerning to me. At some point you have to make a decision and implement a solution, even if not everyone agrees 100% on which solution to chose. Letting this slide for this long is a very bad sign. I’ve been a big Rust fan for my hobby projects, but the whole point of Rust is effortless correctness and safety. The more I encounter bugs and issues that have no…

It's not resolved because it's (a) tricky and (b) is really just a minor question about naming conventions and mutability. I'm quite comfortable stating that non-lexical lifetimes and async I/O, for instance, are far more important. The number of users who benefit from those two features are multiple orders of magnitude greater than the number of users who care about whether the official opinion of the guidelines sub…

As I mentioned in my other reply to Steve Klabnik, documenting this edge case would have been a sufficient “resolution” to the bug at hand.

I may call it a bug, and you may call it undocumented silent data loss behavior; either way, we’re talking about the same thing. Silent data loss from undocumented behavior is not good, wouldn’t you agree?

I certainly was not aware that drops in Rust could throw away potentially serious error codes. Now I have to go re-audit the correctness of all my Rust code that uses the file system (at the very least).

If the behavior was documented I would not consider this a bug. That said, perhaps I’m missing something in the documentarion — my apologies if thats the case — but I did just re-read the fs::File docs and see no mentions or precautions about potential data loss when a File is dropped.

Re: Rust RAII is better than the Haskell bracket pattern

#123

Post by ehsanu1 »

steveklabnik wrote: post #69
tveita wrote: post #68

Earlier quoted context omitted.

I do use explicit drop() calls in my own code to call attention to drops with side effects, but it does not seem to be common practice. My preferred semantics would have been early drops by default, and a must_drop annotation similar to must_use, to say that objects like RwLockReadGuard should be explicitly dropped or moved.

Those semantics would be nice, but they have a lot of unsolved issues: https://gankro.github.io/blah/linear-rust/

Nice article, but not sure that the changes it talks about are actually required for the suggested semantics. The `must_drop` annotation suggested could just be a lint rather than actually being encoded in the type system. I don't know if early drops is related or possible though.

Re: Rust RAII is better than the Haskell bracket pattern

#124

Post by Animats »

steveklabnik wrote: post #101
electrograv wrote: post #96

Earlier quoted context omitted.

The fact that this is not resolved after over a year is concerning to me. At some point you have to make a decision and implement a solution, even if not everyone agrees 100% on which solution to chose. Letting this slide for this long is a very bad sign. I’ve been a big Rust fan for my hobby projects, but the whole point of Rust is effortless correctness and safety. The more I encounter bugs and issues that have no…

> the whole point of Rust is effortless correctness and safety. Rust has never been about proving correctness. Yes, correctness is a goal, but it is subservient to other goals, depending on details. Furthermore, it's not clear that this can really be implemented in a reasonable way, see https://news.ycombinator.com/item?id=18175838 > it seems sometimes that Rust management would rather focus on cool new language enha…

Furthermore, it's not clear that this can really be implemented in a reasonable way

Which is why RAII in a language without exceptions is inappropriate for a resource which has a status on closeout.

Re: Rust RAII is better than the Haskell bracket pattern

#125

Post by dllthomas »

simias wrote: post #19
Animats wrote: post #10

How do you handle errors at resource release? When you close a file, the final writes take place, and they can fail. What's the idiom in Rust for getting them out? Python's "with" clause, and the way it interacts with exceptions, is the only system I've seen that gets this right for the nested case.

I don't think Rust can notify on a failing destructor other than panic!ing. AFAIK the best you can do if you want to handle errors on close is to call `flush()` (which does return errors) before dropping the object. Of course that nullifies the benefits from RAII. I don't know if there's an elegant way to solve this. If Rust had exception you could use that but then again in C++ it's often explicitly discouraged to t…

> I don't know if there's an elegant way to solve this.

It could take a callback. Then for any given file handle, if you don't care that the write failed you can ignore it; if you care but can't sensibly respond, you can panic; if you can sensibly respond you can do it inline or schedule work to be done somewhere with a longer lifetime than the file handle.

Re: Rust RAII is better than the Haskell bracket pattern

#126

Post by pcwalton »

Animats wrote: post #124
steveklabnik wrote: post #101

Earlier quoted context omitted.

> the whole point of Rust is effortless correctness and safety. Rust has never been about proving correctness. Yes, correctness is a goal, but it is subservient to other goals, depending on details. Furthermore, it's not clear that this can really be implemented in a reasonable way, see https://news.ycombinator.com/item?id=18175838 > it seems sometimes that Rust management would rather focus on cool new language enha…

Furthermore, it's not clear that this can really be implemented in a reasonable way Which is why RAII in a language without exceptions is inappropriate for a resource which has a status on closeout.

The alternative to closing the file in the destructor is leaking OS resources in the event of unexpected control flow destroying the file object. I fail to see how that is preferable.

Re: Rust RAII is better than the Haskell bracket pattern

#127

Post by burntsushi »

rbehrends wrote: post #78
burntsushi wrote: post #73

Earlier quoted context omitted.

> Rust's ownership problem solves it for trivial cases, at the cost of making it hard to do other things Your analysis of the trade offs is fine, but you claim that Rust only solves this problem for "trivial" cases. If that's true, then most of the Rust code I've written is trivial. To me, that pretty thoroughly weakens your dismissal here, at least in my case.

I am talking about just using basic references & borrowing. Once you introduce reference counting (Rc and Arc ) and copying, you open up a lot more options, of course, but at this point you also can't make any lifetime guarantees anymore, because objects can escape the "owner's" scope at will.

> I am talking about just using basic references & borrowing.

... yes, I know. And is presumably what you referred to as "trivial." But this in fact comprises the vast majority of Rust code I've written. So you can call it trivial if you want, but as I said, it significantly reduces the weight of your dismissal.

There's plenty of Rust code I've written that makes use of Arc/Rc, specifically for cases you've called out (global caches, structural sharing, etc.) but it's nowhere near ubiquitous. So what I'm trying to say is that your representation of the problems that Rust solves is at best misleading, as supported by my experience writing a not insignificant amount of Rust.

So in other words, sure, you can call most of my code "trivial," but on the other hand, I can say that the problems posed by you in your top-level comment are actually solved in most of my code, regardless of whether you think it's trivial or not.

Re: Rust RAII is better than the Haskell bracket pattern

#128

Post by klodolph »

agentultra wrote: post #95
klodolph wrote: post #52

Earlier quoted context omitted.

Haskell has such an extensive set of language extensions, I would say adding new features to the type system is probably the MOST Haskell-ish way of doing things. The explicit purpose of Haskell is to be a basis for research into functional language design (edit: among other purposes). By "explicit purpose" I mean exactly that... people got together in 1987 to come up with a language for research. Haskell was never s…

I do normal, boring line-of-business programming in Haskell every day. I think Haskell does have a good model for bringing together practical application of theoretical research. Parent's comment is spreading the myth that Haskell is an academic language. It's not wrong but it's not Haskell's only stated purpose or utility by far.

I used to do normal, line-of-business programming and I stand by the comment.

If it sounds like I'm saying that Haskell is not useful for boring, line-of-business programs then I wasn't clear... Haskell is a research language, yes, and not exclusively so. But I'm confused why it's objectionable to spread a "myth" if that myth is, in your words, "not wrong". The stated purpose of Haskell, when it was created, is a matter of historical record.

> It should be suitable for teaching, research, and applications, including building large systems.

This, to me, means that we are not going to freeze the language, and sacrifice research, in order to support business applications. That would go against the goals of the language.

Doing everything as a library seems "un-Haskellish" to me because there's an ongoing and vibrant community that's doing research into things like type theory, which can't be done as libraries, and kicking that group of people off the Haskell platform just to support business applications would be a failure of Haskell as a language.

Haskell can support both groups.

Re: Rust RAII is better than the Haskell bracket pattern

#129

Post by pcwalton »

electrograv wrote: post #121
pcwalton wrote: post #104

Earlier quoted context omitted.

It's not resolved because it's (a) tricky and (b) is really just a minor question about naming conventions and mutability. I'm quite comfortable stating that non-lexical lifetimes and async I/O, for instance, are far more important. The number of users who benefit from those two features are multiple orders of magnitude greater than the number of users who care about whether the official opinion of the guidelines sub…

As I mentioned in my other reply to Steve Klabnik, documenting this edge case would have been a sufficient “resolution” to the bug at hand. I may call it a bug, and you may call it undocumented silent data loss behavior; either way, we’re talking about the same thing. Silent data loss from undocumented behavior is not good, wouldn’t you agree? I certainly was not aware that drops in Rust could throw away potentially…

I mean, I guess it's not documented as well as it could be, but the only alternative to dropping close errors would be panicking, and that would be significantly worse. Destructors aren't supposed to fail.

Re: Rust RAII is better than the Haskell bracket pattern

#130

Post by klodolph »

dang wrote: post #108
klodolph wrote: post #52

Earlier quoted context omitted.

Haskell has such an extensive set of language extensions, I would say adding new features to the type system is probably the MOST Haskell-ish way of doing things. The explicit purpose of Haskell is to be a basis for research into functional language design (edit: among other purposes). By "explicit purpose" I mean exactly that... people got together in 1987 to come up with a language for research. Haskell was never s…

> What are you talking about? Please edit swipes like that out of your comments here. The rest is fine and stands on its own.

I would love to edit that out but the two-hour edit window is so short, sometimes.
Post reply on HN