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

111–120 of 156 posts

Re: Rust RAII is better than the Haskell bracket pattern

#111

Post by ducklingslicks »

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.

What are you talking about? I liked his comment.

Re: Rust RAII is better than the Haskell bracket pattern

#112

Post by fasquoika »

bjoli wrote: post #40
radarsat1 wrote: post #36

Earlier quoted context omitted.

Is it possible? I mean, to add linear types via a library? I feel like it would have been done already if it were.

I am always impressed by what the ocaml/Haskell people can do compared to my language of choice (scheme). Iirc Oleg Kiselyov implemented proper delimited continuations in ocaml as a library, without touching the runtime or compiler. Something similar has been done in Haskell. I doubt fully dependent types can be implemented in Haskell without extra help by ghc. There has been lots of work in the area, and last time I…

>Iirc Oleg Kiselyov implemented proper delimited continuations in ocaml as a library, without touching the runtime or compiler.

To clarify this, the library you're talking about implements most of the functionality in C, reusing the runtime's exception mechanism. So it doesn't require any upstream change to compiler or runtime, but it also can't be implemented in pure OCaml.

Re: Rust RAII is better than the Haskell bracket pattern

#113

Post by Franciscouzo »

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 ?

Why? When taking into account the cpu cache, branch mispredictions, etc, I bet it would be slower than just zeroing it, besides it wouldn't be secure at all, imagine a process that stores a secret key, and then releases the memory, if another process can trigger the first to generate and release the key memory multiple times, they would be able to read it.

Re: Rust RAII is better than the Haskell bracket pattern

#114

Post by kccqzy »

acqq wrote: post #50
jcelerier wrote: post #41

Earlier quoted context omitted.

> when many C++ and Rust programs are about to end, they spend the last few cycles uselessly deallocating memory that would've immediately been freed via _exit(2) thank god they do this. how many times did I have to manually force linux to release sockets because badly coded C programs which opened sockets forgot to release them causing them to hang up for ~5 minutes after the process ended. With proper RAII classes…

Your example combined with the parents observation show that C++ put under the same construct the concepts that should be separated: memory allocation should be handled differently from the construction, destruction and other resource allocation.

Memory allocation and deallocation on the heap basically mean calling the `operator new` and `operator delete` functions in C++. The language provides a default implementation but you can override it.

Constructors are orthogonal. The job of a constructor is to construct your object given that the space for the object is already allocated. This could be on the stack, where allocation means bumping the stack pointer, or in-place in preallocated storage (like std::vector), or the result of calling `operator new`. Simply using the `new` syntax does both as a shorthand.

Similarly the job of a destructor is to destruct your object without deallocating it. One can in-place destruct without deallocating, or destruct and then deallocate implicitly when the stack pointer is adjusted, or not at all. The `delete` syntax does both destruction and deallocation as a convenience.

Re: Rust RAII is better than the Haskell bracket pattern

#115

Post by whateveracct »

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.

Haskell language features are importable :)

Re: Rust RAII is better than the Haskell bracket pattern

#116

Post by quietbritishjim »

dbaupp wrote: post #33
siscia wrote: post #28

Earlier quoted context omitted.

Can you please dig deeper, that I am not sure I follow. In which case in rust you cannot be sure that "the drop" will be called?

If there's a cycle of strong references with Rc or Arc (or shared_ptr in C++), those objects still never get dropped/have their destructors called.

I think that falls into the category I mentioned in the third paragraph of my comment: a serious pre-existing bug with other consequences will potentially cause the guarantee to be violated. A similar effect would happen if you had a double free that sometimes caused a crash, which is a similar level of programming mistake to creating a cyclic reference. To me it sits outside of a reasonable definition of "guaranteed".

Re: Rust RAII is better than the Haskell bracket pattern

#117

Post by zaphar »

dbaupp wrote: post #33
siscia wrote: post #28

Earlier quoted context omitted.

Can you please dig deeper, that I am not sure I follow. In which case in rust you cannot be sure that "the drop" will be called?

If there's a cycle of strong references with Rc or Arc (or shared_ptr in C++), those objects still never get dropped/have their destructors called.

Rc's drop will be called. But whether the exposed object's drop will be called is dependent on the reference count.

But Rc would not work if the drop was not guaranteed to be called.

Re: Rust RAII is better than the Haskell bracket pattern

#118

Post by steveklabnik »

zaphar wrote: post #117
dbaupp wrote: post #33

Earlier quoted context omitted.

If there's a cycle of strong references with Rc or Arc (or shared_ptr in C++), those objects still never get dropped/have their destructors called.

Rc's drop will be called. But whether the exposed object's drop will be called is dependent on the reference count. But Rc would not work if the drop was not guaranteed to be called.

If you have a reference cycle, the two Rcs will keep each other alive, and their Drops will not be called.

Re: Rust RAII is better than the Haskell bracket pattern

#119

Post by electrograv »

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…

Apologies if it sounded like I demanded a “cool new language enhancement” solution to this issue. On the contrary; if it were just documented that either fs::File [1] or the io::Write trait [2] could silently lose data with no error codes when dropped, that would be one such sufficient solution.

Perhaps I misread this documentation; if so, I don’t think I’d be alone here. I don’t see any particular mention that dropping an fs::File could lead to data loss, and I had generally assumed major edge cases like ‘data loss from a file system library’ would be documented.

[1] https://doc.rust-lang.org/std/fs/struct.File.html

[2] https://doc.rust-lang.org/std/io/trait.Write.html

Re: Rust RAII is better than the Haskell bracket pattern

#120

Post by steveklabnik »

electrograv wrote: post #119
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…

Apologies if it sounded like I demanded a “cool new language enhancement” solution to this issue. On the contrary; if it were just documented that either fs::File [1] or the io::Write trait [2] could silently lose data with no error codes when dropped, that would be one such sufficient solution. Perhaps I misread this documentation; if so, I don’t think I’d be alone here. I don’t see any particular mention that dropp…

It falls out of general principle; destructors may not be called. That said, I would happily accept a PR to make this explicit. Even an issue would be nice!
Post reply on HN