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

81–90 of 156 posts

Re: Rust RAII is better than the Haskell bracket pattern

#81

Post by rbehrends »

steveklabnik wrote: post #76
rbehrends wrote: post #72

Earlier quoted context omitted.

> This is a thing people say, but I think it's misleading. Reference counting can increase the lifetime of an object, but borrowing cannot. I've seen this really trip up beginners. "With a maximum reference count of 1." As the reference count becomes 1 upon object creation, it cannot really be increased further. Hence, only operations that keep the (virtual) reference count at 1 or reduce it to 0 are allowed. My poin…

That doesn't change much; the point is that (in many languages), variables going into or out of scopes don't fiddle with the ref count[1], and so people assume that something will live until they make the count go down explicitly. It also only refers to ownership, not borrowing, and both are equally important. Beyond that, what I'm saying is something more meta: It doesn't really matter if this analogy is spot-on or…

> It also only refers to ownership, not borrowing, and both are equally important.

I addressed borrowing above. Borrowing is proving lifetime subset properties and that you therefore can avoid increasing the virtual reference count.

And this is not about whether this is useful for beginners. It is to illustrate inherent limitations of the approach.

Re: Rust RAII is better than the Haskell bracket pattern

#82

Post by bunderbunder »

steveklabnik wrote: post #63
rbehrends wrote: post #61

Earlier quoted context omitted.

> Oddly, Rust's ownership system really does solve these problems No. Rust's ownership problem solves it for trivial cases, at the cost of making it hard to do other things (such as sharing references past the lifetime of the owner without resorting to Rc or Arc , at which point you don't really have lifetime guarantees anymore). The essential limitation of Rust is that (without resorting to Rc and Arc , which would…

> it is conceptually limited to the equivalent of reference counting with a maximum reference count of 1. This is a thing people say, but I think it's misleading. Reference counting can increase the lifetime of an object, but borrowing cannot. I've seen this really trip up beginners. > This inherent limitation makes a lot of things hard It can make them different , which can be hard, but these things are already hard…

> This is a thing people say, but I think it's misleading. Reference counting can increase the lifetime of an object, but borrowing cannot. I've seen this really trip up beginners.

I'm not sure I follow.

The only reference-counted language I've used is (pre-ARC) Objective-C. There, it was a very common idiom to "borrow" objects - so common that it didn't even have a name. There was just objects you "retained" (that is, staked a claim on), and ones you didn't.

Maybe there's a pitfall to how the "automatic" part of automatic reference counting is typically implemented?

Re: Rust RAII is better than the Haskell bracket pattern

#83

Post by steveklabnik »

rbehrends wrote: post #81
steveklabnik wrote: post #76

Earlier quoted context omitted.

That doesn't change much; the point is that (in many languages), variables going into or out of scopes don't fiddle with the ref count[1], and so people assume that something will live until they make the count go down explicitly. It also only refers to ownership, not borrowing, and both are equally important. Beyond that, what I'm saying is something more meta: It doesn't really matter if this analogy is spot-on or…

> It also only refers to ownership, not borrowing, and both are equally important. I addressed borrowing above. Borrowing is proving lifetime subset properties and that you therefore can avoid increasing the virtual reference count. And this is not about whether this is useful for beginners. It is to illustrate inherent limitations of the approach.

> I addressed borrowing above. Borrowing is proving lifetime subset properties and that

Right, so what I'm saying is, the description of borrowing doesn't really fit in with the reference counting aspect of the analogy, so it ends up being separate from it.

> And this is not about whether this is useful for beginners.

Right, that was my point. :)

I mean, in the end, do what you'd like. All I'm saying is that I've seen this analogy lead to tons of confusion. YMMV.

Re: Rust RAII is better than the Haskell bracket pattern

#84

Post by steveklabnik »

bunderbunder wrote: post #82
steveklabnik wrote: post #63

Earlier quoted context omitted.

> it is conceptually limited to the equivalent of reference counting with a maximum reference count of 1. This is a thing people say, but I think it's misleading. Reference counting can increase the lifetime of an object, but borrowing cannot. I've seen this really trip up beginners. > This inherent limitation makes a lot of things hard It can make them different , which can be hard, but these things are already hard…

> This is a thing people say, but I think it's misleading. Reference counting can increase the lifetime of an object, but borrowing cannot. I've seen this really trip up beginners. I'm not sure I follow. The only reference-counted language I've used is (pre-ARC) Objective-C. There, it was a very common idiom to "borrow" objects - so common that it didn't even have a name. There was just objects you "retained" (that i…

It has been years since I've written objective-c, so I'll write out some psuedo-code. This may be wrong, please correct me! (It should map to C++ pretty directly, and certainly does in unsafe Rust.)

* You have an object. You call retain on it. You have a count of one.

* You also have a pointer to that object. The "borrow" in your analogy.

* You return this pointer, and stash it somewhere. The object still has a count of one, so it's still live, so this is okay.

* Later in your program, you use that pointer to call release.

Here, we've only ever had a reference count of one, but our object has lived across arbitrary inner scopes. In Rust, this would not work, unless you dropped into unsafe.

Obviously, with Arc and autoretain this kind of code doesn't get written anymore, I would hope. And even without, it wouldn't be guaranteed, so you'd want the "borrow" to actually bump the refcount. But Rust is about guaranteeing that it can't.

Re: Rust RAII is better than the Haskell bracket pattern

#85

Post by runevault »

pjmlp wrote: post #74
naasking wrote: post #66

Earlier quoted context omitted.

I googled "Midori outcomes", but I only found your posts mentioning it. Have a better keyword to search or a link?

It is a path to enlightenment with multiple stops. :) Start with Joe Duffy blog posts about Midori architecture. http://joeduffyblog.com/2015/11/03/blogging-about-midori/ Then hop on to his talks. "Safe Systems Programming in C# and .NET" https://www.infoq.com/presentations/csharp-systems-programmi... "RustConf 2017 - Closing Keynote: Safe Systems Software and the Future of Computing by Joe Duffy" https://www.youtube…

I either missed or forgot about this stuff, gives me a nice rabbit hole to go down, thanks.

Re: Rust RAII is better than the Haskell bracket pattern

#88

Post by bunderbunder »

steveklabnik wrote: post #84
bunderbunder wrote: post #82

Earlier quoted context omitted.

> This is a thing people say, but I think it's misleading. Reference counting can increase the lifetime of an object, but borrowing cannot. I've seen this really trip up beginners. I'm not sure I follow. The only reference-counted language I've used is (pre-ARC) Objective-C. There, it was a very common idiom to "borrow" objects - so common that it didn't even have a name. There was just objects you "retained" (that i…

It has been years since I've written objective-c, so I'll write out some psuedo-code. This may be wrong, please correct me! (It should map to C++ pretty directly, and certainly does in unsafe Rust.) * You have an object. You call retain on it. You have a count of one. * You also have a pointer to that object. The "borrow" in your analogy. * You return this pointer, and stash it somewhere. The object still has a count…

Ah, I think I follow.

So, it sounds to me like it's not necessarily that Rust's model is fundamentally different from "ref counting with a limit of 1", at least in terms of how you should be managing your memory, so much as that the language doesn't let you some things that you really shouldn't be doing in the first place.

Sometimes it felt like Objective C wouldn't just let you point a gun at your foot, it would actively cheer you on while you did it.

Re: Rust RAII is better than the Haskell bracket pattern

#89

Post by School-Cotton »

agumonkey wrote: post #79
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…

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

Marks it as free, but the OS will wipe it before giving it to another process.
Post reply on HN