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

101–110 of 156 posts

Re: Rust RAII is better than the Haskell bracket pattern

#101

Post by steveklabnik »

electrograv wrote: post #96
masklinn wrote: post #22

Earlier quoted context omitted.

> 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? That is unclear. Currently, `File::drop` ignores all errors and drops them on the floor ([unix], [windows]). This is a concern both long-standing and ongoing[0]. AFAIK discussion has gone no further than https://github.com/rust-lang-nursery/api-guideline…

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 enhancements

In this comment, you're complaining that we haven't implemented a "cool new language enhancement." This is at odds with your desire stated here.

Re: Rust RAII is better than the Haskell bracket pattern

#102

Post by agumonkey »

toast0 wrote: post #97
agumonkey wrote: post #79

Earlier quoted context omitted.

Does _exit wipe out memory or just mark some regions as free ? asking for security purposes.

I don't know how Linux manages its memory pages. FreeBSD would put all of the anonymous pages onto essentially a free, but not zeroed queue. And there's an optional background job to zero the pages and put them in the zeroed queue. When a new page is needed, the clean queue is checked first, otherwise nonzeroed pages are zeroed on demand during allocation. (Zeroing can be theoretically skipped in cases where the kern…

Maybe a randomized sparse zeroing ?

Re: Rust RAII is better than the Haskell bracket pattern

#103

Post by anentropic »

DanWaterworth wrote: post #94
anentropic wrote: post #30

Earlier quoted context omitted.

True, but in Python the coding mistake would stand out much more because the with block is syntax sugar - it does not look like regular function application, whereas in the Haskell example there is nothing to tell you that withMyResource is using the 'bracket pattern' (except by reading the src) Also I guess in Haskell there is more expectation that the type system should prevent you from expressing runtime errors

I can see why you might think that, being built into the language, using 'with' in Python in a broken way would be easier to spot. However, having used both languages extensively, I can tell you that, at least for me, there's no discernible difference. I think the reason for this is might be that, in Haskell, a function starting with 'with' is, by convention, using the bracket pattern and the way that you might use s…

I only mean it's visibly more obvious, you have an indented block... what is the purpose of the indented block unless to say "do all your stuff with the resource _inside_ this block". Using the with block is very 'intentional' feeling.

I'm not very familiar with Haskell but it seems like you'd get used to the type system telling you everything you need to know. But in this case it doesn't. In Python world we talk about 'pythonic/unpythonic'... it seems like it's maybe quite unhaskellish to have to rely on a naming convention and remembering not to use the return value of the function?

I would guess that's why the article and many of the other comments here focused on how you could express this behaviour in Haskell's type system, where you'd expect it.

In short: type system > syntax sugar > naming convention

Re: Rust RAII is better than the Haskell bracket pattern

#104

Post by pcwalton »

electrograv wrote: post #96
masklinn wrote: post #22

Earlier quoted context omitted.

> 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? That is unclear. Currently, `File::drop` ignores all errors and drops them on the floor ([unix], [windows]). This is a concern both long-standing and ongoing[0]. AFAIK discussion has gone no further than https://github.com/rust-lang-nursery/api-guideline…

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 subteam is that close() should take &self or &mut self. The Rust team would be doing a disservice to users if it focused on small issues like that—this isn't even a bug we're talking about, it's guidance around conventions!—instead of the biggest complaints that come up constantly.

Re: Rust RAII is better than the Haskell bracket pattern

#105

Post by dllthomas »

T-R wrote: post #15

Something to keep in mind - linear types are on their way[1], with exactly this usecase in mind. Simon Peyton Jones gave an excellent presentation on the topic[2], briefly discussing exceptions, as well as giving a mention to ResourceT and the phantom type solution in the article (described as channel-passing). [1] https://arxiv.org/abs/1710.09756 [2] https://www.youtube.com/watch?v=t0mhvd3-60Y

I'm not convinced the current linear types proposals actually let us solve the problem, in the presence of exceptions. I may very well be missing something, or it may be that exceptions are rare enough that leaking resources until garbage collection only when an exception occurs is fine in practice.

Re: Rust RAII is better than the Haskell bracket pattern

#106

Post by fmap »

thesz wrote: post #35
T-R wrote: post #15

Something to keep in mind - linear types are on their way[1], with exactly this usecase in mind. Simon Peyton Jones gave an excellent presentation on the topic[2], briefly discussing exceptions, as well as giving a mention to ResourceT and the phantom type solution in the article (described as channel-passing). [1] https://arxiv.org/abs/1710.09756 [2] https://www.youtube.com/watch?v=t0mhvd3-60Y

Please, don't add them to the language. Use the library approach instead, it is much more Haskellish.

From a language design perspective it makes a lot of sense to add linear types to the language itself instead of using an encoding. Every encoding that I know of (such as region types encoded as monads, which is what I think the article wants to get at) leads to excessive sequentialization of code. This in turn leads to a lot of boilerplate (or crazy type inference problems) at compile time as well as suboptimal run time performance.

Linear types are the perfect example of a feature that belongs in the core language, or at the very least into a core intermediate language. They are expressive, in that you can encode a lot of high-level design ideas into linear types. You can compile a number of complicated front-end language features into a linearly typed intermediate language. Linear types have clear semantics and can even be used for improved code generation. If we ignore the messy question of how best to expose linear types in a high-level language then this is just an all around win-win situation...

Re: Rust RAII is better than the Haskell bracket pattern

#107

Post by toast0 »

agumonkey wrote: post #102
toast0 wrote: post #97

Earlier quoted context omitted.

I don't know how Linux manages its memory pages. FreeBSD would put all of the anonymous pages onto essentially a free, but not zeroed queue. And there's an optional background job to zero the pages and put them in the zeroed queue. When a new page is needed, the clean queue is checked first, otherwise nonzeroed pages are zeroed on demand during allocation. (Zeroing can be theoretically skipped in cases where the kern…

Maybe a randomized sparse zeroing ?

I'm not sure what a randomized zeroing would get you from a security perspective. You shouldn't need to be concerned about other programs observing the memory, kernels are expected to give programs only zeroed pages. If you're concerned about kernel level memory dumping, randomized zeroing isn't good enough -- it may or may not have zeroed your secrets, so that's not very helpful. Background zeroing doesn't help much here either -- FreeBSD sets a target of zeroing half the free pages, so your secrets may not be zeroed for a long time.

It seems the jury is out on the benefits from a performance perspective (DragonflyBSD took out background zeroing, saying they were unable to observe a performance difference, so simpler code is better)

Re: Rust RAII is better than the Haskell bracket pattern

#108

Post by dang »

klodolph wrote: post #52
thesz wrote: post #35

Earlier quoted context omitted.

Please, don't add them to the language. Use the library approach instead, it is much more Haskellish.

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.

Re: Rust RAII is better than the Haskell bracket pattern

#109

Post by [deleted] »

kccqzy wrote: post #2

The thing is that, in Haskell, even when you attach a function to run during destruction, the runtime doesn't guarantee that the function will be called promptly, or even at all. Rust drops (runs destructor and deallocates) values as soon as they go out of scope; C++ too. In Haskell you depend on the whims of the GC, which makes RAII unusable. (The Haskell approach of not guaranteeing destructors being called does ha…

[deleted]

Re: Rust RAII is better than the Haskell bracket pattern

#110

Post by agumonkey »

toast0 wrote: post #107
agumonkey wrote: post #102

Earlier quoted context omitted.

Maybe a randomized sparse zeroing ?

I'm not sure what a randomized zeroing would get you from a security perspective. You shouldn't need to be concerned about other programs observing the memory, kernels are expected to give programs only zeroed pages. If you're concerned about kernel level memory dumping, randomized zeroing isn't good enough -- it may or may not have zeroed your secrets, so that's not very helpful. Background zeroing doesn't help much…

Not much indeed but it might deter some low hanging leak hacks..
Post reply on HN