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

Rust means never having to close a socket

blog.skylight.io

Post reply on HN
Print view View original

71–80 of 165 posts

Re: Rust means never having to close a socket

#71

Post by steveklabnik »

mwcampbell wrote: post #67

I agree that automatic, deterministic resource management (as opposed to GC plus a dispose pattern of some kind) is highly desirable. But I think for the vast majority of projects, I would prefer automatic reference counting with the occasional weak reference to break cycles, particularly if that were the default for the language. I can appreciate that being explicit about resource ownership is an advantage in situat…

You can do that if you want, just use the Rc/Arc/Weak types.

That said, you're right: if you don't need Rust's strengths, the tradeoff may not be worth it.

Re: Rust means never having to close a socket

#72

Post by wycats »

krig wrote: post #68
wycats wrote: post #65

Earlier quoted context omitted.

I'm a little bit confused. Every object that gets allocated has to be freed at some point. That cost is the same no matter how the memory is managed. Are you talking about an additional cost beyond "freeing memory that was allocated"?

It sounds like they are talking about a semi-space collector, which I can imagine might in theory be faster than scoped allocation since allocation is a simple pointer bump (just like stack allocation) but when garbage collecting you only have to traverse the live set. However, semi-space collectors can't collect non-memory resources without additional metadata, and they have a memory overhead of at least 2x the maxi…

In Rust, you often use stack allocation, which, as you pointed out, is much more efficient. There's some heap allocation in Rust, but in my experience it's actually a minority of all allocations.

Rust also has an Arena library (http://doc.rust-lang.org/0.11.0/arena/index.html), which can be used for cases where you know that you have enough memory for a given operation and are willing to throw out the entire thing when the operation (or program ;) ) is done.

Re: Rust means never having to close a socket

#73

Post by masklinn »

crantanplum wrote: post #56
pcwalton wrote: post #6

Earlier quoted context omitted.

> C++11 introduces unique_ptr, which has a lot of the same safety characteristics. Sure, other than not actually being safe (UB resulting from use after move of unique_ptr being an obvious one; there are many others).

What part of that is undefined? When you move the pointer, the original becomes null..

> What part of that is undefined? When you move the pointer, the original becomes null..

Nope, the argument is "valid but unspecified" not necessarily null. And http://en.cppreference.com/w/cpp/utility/move specifically has this as an example of UB:

    std::vector v;
    std::string str = "example";
    v.push_back(std::move(str)); // str is now valid but unspecified
    str[0]; // undefined behavior: operator[](size_t n) has a precondition size() > n
There's an other fun UB because std::move doesn't check for aliasing, so self-assignment:

    v = std::move(v);
is also an UB.

And of course even if it were null., pcwalton talks about use after null. Deref'ing a null pointer (to use it) is still an UB.

Re: Rust means never having to close a socket

#75

Post by kazinator »

In garbage collected languages with macros and an "unwind protect" operator, we avoid explicitly closing files and other resources using with scoped binding constructs implemented by macros.

   (with-locked mutex
      ;; ... critical section
   )
   ;; mutex is released here

Re: Rust means never having to close a socket

#76

Post by pcwalton »

crantanplum wrote: post #56
pcwalton wrote: post #6

Earlier quoted context omitted.

> C++11 introduces unique_ptr, which has a lot of the same safety characteristics. Sure, other than not actually being safe (UB resulting from use after move of unique_ptr being an obvious one; there are many others).

What part of that is undefined? When you move the pointer, the original becomes null..

Dereferencing a null pointer (i.e. use) is undefined behavior.

Re: Rust means never having to close a socket

#77

Post by wycats »

kazinator wrote: post #75

In garbage collected languages with macros and an "unwind protect" operator, we avoid explicitly closing files and other resources using with scoped binding constructs implemented by macros. (with-locked mutex ;; ... critical section ) ;; mutex is released here

I specifically address this pattern towards the end of my post (it's essentially the same pattern as Ruby's approach).

Re: Rust means never having to close a socket

#78

Post by ben0x539 »

kazinator wrote: post #75

In garbage collected languages with macros and an "unwind protect" operator, we avoid explicitly closing files and other resources using with scoped binding constructs implemented by macros. (with-locked mutex ;; ... critical section ) ;; mutex is released here

That only works if the lifetime of a resource is a lexical region, right?

Re: Rust means never having to close a socket

#79

Post by agumonkey »

ben0x539 wrote: post #78
kazinator wrote: post #75

In garbage collected languages with macros and an "unwind protect" operator, we avoid explicitly closing files and other resources using with scoped binding constructs implemented by macros. (with-locked mutex ;; ... critical section ) ;; mutex is released here

That only works if the lifetime of a resource is a lexical region, right?

Good question. I wonder if there was some Lisp with linear logic that would allow lexical and ~borrowed (sorry if I misuse the term) resources management.

Re: Rust means never having to close a socket

#80

Post by kibwen »

mwcampbell wrote: post #67

I agree that automatic, deterministic resource management (as opposed to GC plus a dispose pattern of some kind) is highly desirable. But I think for the vast majority of projects, I would prefer automatic reference counting with the occasional weak reference to break cycles, particularly if that were the default for the language. I can appreciate that being explicit about resource ownership is an advantage in situat…

I agree that Rust isn't the be-all, end-all language. But I think this line is mistaken:

  > I think a system of ownership and borrowing like Rust's 
  > would just add extra cognitive load for the programmer 
  > for no appreciable gain.
In my experience, the fact that the compiler can check this stuff ends up subtracting cognitive load. Of any language I've used, Rust code is the code that I worry least about.

Is there syntactic overhead? Yep. Does it impose constraints on design? Yep. But when it comes to resource management, everything that Rust does is just something that you'd need to use a pen and paper to keep track of in other languages (including pervasively reference-counted languages, since AFAIK there's no way to automatically enforce the proper use of weak pointers).

Post reply on HN