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

91–100 of 165 posts

Re: Rust means never having to close a socket

#91

Post by steveklabnik »

mwcampbell wrote: post #81
steveklabnik wrote: post #71

Earlier quoted context omitted.

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.

I know Rust has RC pointers. But I'm guessing a Rust programmer would still have to understand ownership and borrowing, since the standard library and third-party libraries use those concepts. I think what I'd really like is something like C# and the .NET base class library, but AOT compiled to native code and using automatic reference counting, with some way to indicate weak references. I know that neither GC nor re…

That's true, you can't totally avoid knowing about these things. But if you don't want to think about them in your code, and are okay with the price, you can.

It sounds like Swift may be close to what you want, yeah?

Re: Rust means never having to close a socket

#92

Post by mercurial »

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?

The 'with' idioms I've seen in the past do, which, combined with yield operators, can make for some unexpected 'fun' at runtime, but it remains extremely convenient most of the time.

Re: Rust means never having to close a socket

#94

Post by pjmlp »

mwcampbell wrote: post #81
steveklabnik wrote: post #71

Earlier quoted context omitted.

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.

I know Rust has RC pointers. But I'm guessing a Rust programmer would still have to understand ownership and borrowing, since the standard library and third-party libraries use those concepts. I think what I'd really like is something like C# and the .NET base class library, but AOT compiled to native code and using automatic reference counting, with some way to indicate weak references. I know that neither GC nor re…

> C# and the .NET base class library, but AOT compiled to native code

Mono -aot and .NET Native.

Just not with RC, though.

Or D, if you with to have both GC and RC.

Re: Rust means never having to close a socket

#95

Post by spullara »

masklinn wrote: post #66
spullara wrote: post #62

"Rust achieves both of these features without runtime costs (garbage collection or reference counting), and without sacrificing safety." If it is freeing everything at the scope boundary it is incurring a huge runtime cost relative to garbage collected languages. GC scales with the number of live objects during GC while this scheme scales with the number of allocated objects. It is far more predictable than GC but I…

> It is far more predictable than GC but I don't believe that it isn't more expensive. A GC has to determine liveness of objects, so it has to traverse the object graph (or at least the most recent generation if the GC is generational) to know which objects are still alive and which aren't. That's what "GC scaling" refers to. Then it still has to deallocate dead objects, and pay the same deallocation cost as scope-bo…

It doesn't have to deallocate dead objects. That is sort of the point of most collectors.

Re: Rust means never having to close a socket

#96

Post by spullara »

wycats wrote: post #72
krig wrote: post #68

Earlier quoted context omitted.

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…

Arena allocation has similar efficiencies as GC.

Re: Rust means never having to close a socket

#97

Post by yoodenvranx »

Rusky wrote: post #88
yoodenvranx wrote: post #87

Does anybody know if Rust will reach all those nice goals or are there some theoretical / comp sci reasons why it might fail?

Everything in this article already works (and has for quite some time). The author is using it in production.

Yes, I know it is working for quite some time, I was more wondering if there are some hidden inherent problems lurking below the surface or if the theory behind rust is sound, e.g. some corner cases where it breaks down or result in undefined behaviour.

Re: Rust means never having to close a socket

#98

Post by lbrandy »

masklinn wrote: post #73
crantanplum wrote: post #56

Earlier quoted context omitted.

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 pre…

OP is correct. You've quoted the general language around move semantics but unique_ptr itself has a stronger gaurantee.

From 20.7.1

  Additionally, u can, upon request, transfer ownership to
  another unique pointer u2. Upon completion of such a
  transfer, the following postconditions hold:

  — u.p is equal to nullptr,
unique_ptr isn't what's unsafe here. Null pointers are. The difference, admittedly, is mostly semantic. There is nothing undefined about using a unique_ptr after moving unless you use the internal pointer in undefined ways.

Re: Rust means never having to close a socket

#99

Post by spion »

kibwen wrote: post #54
spion wrote: post #34

If borrowing is the default, why does it require additional syntactic noise? Why isn't transfer achieved by adding sigils such as "&"?

1. Familiarity to C++ programmers, for whom taking a reference via `&` is a familiar operation. 2. There are two different kinds of references: `&` is immutable and `&mut` is mutable. One way or the other you'd need some sort of differentiation. 3. Borrowing, though crucial to the idea of Rust, is still less fundamental than ownership. You can have a language with ownership and without borrowing (indeed, this is how…

Doesn't #1 matter less in Rust? C++ has to deal with backward compatibility in syntax, Rust doesn't.

Based on this article, immutable references are the most common kind of declarations. It seems to me that rust code would look much cleaner if they had the shortest syntax (including in pattern matching etc)

Post reply on HN