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

81–90 of 165 posts

Re: Rust means never having to close a socket

#81

Post by mwcampbell »

steveklabnik wrote: post #71
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.

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 reference counting quite reaches the level of "don't make me think" when it comes to resource management, but given a choice between explicit resource disposal and the occasional weak reference annotation, I think I'd choose the latter.

Anyway, enough ranting from me for now.

Re: Rust means never having to close a socket

#82

Post by kibwen »

Animats wrote: post #64
wycats wrote: post #58

Earlier quoted context omitted.

Also, there are a whole host of very common types (integers, etc.) that actually want to be passed by value and copied. There's no point in making a pointer to an integer and then dereferencing the pointer in the callee when an integer fits into the same amount of space as a pointer in the first place. Very simple types (without heap pointers or destructors) can be passed by value and efficiently copied. You end up w…

If something is immutable (and doesn't own something else), it doesn't matter whether it's passed by value or reference. That's a decision the compiler can, and should, make, as an optimization decision. In Modula, where pass-as-read-only was the default, small items were passed by value and large ones by reference. "Small" is a CPU-dependent optimization and should be left to the compiler, not "user intuition". The…

  > the defaults aren't in the safest direction
Can you elaborate on this? I'm curious to know how you perceive Rust's defaults as unsafe.

Re: Rust means never having to close a socket

#83

Post by Dewie »

kibwen wrote: post #80
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 syn…

> 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.

That's interesting. So this holds for languages and applications where you could get away with not knowing the automatic memory management implementation and adjusting your design based on that? For example, that you don't have to worry yourself with making sure to not allocate too many values on the heap, at least in most of the code?

Would you prefer using Rust for problems and domains where you strictly don't need the efficiency and determinism (like memory usage) you get from using Rust?

Re: Rust means never having to close a socket

#84

Post by portmanteaufu »

kibwen wrote: post #24
monocasa wrote: post #8

Earlier quoted context omitted.

> Wherever you would have written "socket.close()", in rust you can just say "drop(socket)". The difference is, it takes advantage of the ownership system to statically prove that you won't try to use the socket after close. Does a drop somehow say something to the type system as well, disallowing reads and writes afterwards? I'm new to rust, sorry if that's a stupid question.

In fact, the `drop` function is totally trivial. It's just a function that takes ownership of a thing, then does nothing with it whatsoever. In other words, the function body is entirely empty! :) https://github.com/rust-lang/rust/blob/master/src/libcore/me...

Ha! I've been using this function for ages and always assumed it was a compiler built-in. I love that it's just that simple.

Re: Rust means never having to close a socket

#85

Post by kibwen »

phunge wrote: post #63
wycats wrote: post #27

Earlier quoted context omitted.

What happens if there's a cycle? It will get closed when the cycle is finally collected. You can rely on a GC (and refcounting + a cycle collector is absolutely a GC) to finalize your resources for you, but it is quite difficult to reason about when the file will eventually be closed. Also, the reference counting semantics of CPython are implementation-specific. From the PEP that introduced `with`: > Note that we're…

Props to Rust for tackling this head on, more languages should provide resource allocation that's deterministic, predictable and syntactically convenient. CPython's behavior is nice, but it seems to me it came about by accident. Big heavy resources use refcounting because everything uses refcounting. Plus, if CPython had true concurrency, across-the-board refcounting probably wouldn't have lasted nearly as long (reas…

I agree that refcounting is a great and usable compromise in this space, but your own comment flirts with why I don't think modern languages are chomping at the bit to base resource management on it: concurrency.

Granted, I have no idea how much overhead is imposed by atomic operations vs. a stop-the-world or concurrent GC (if anyone has some data, I'd love to see it!). But given how it's become de rigeur for new languages to come with a baked-in concurrency story and emphasize concurrent applications, I don't blame them for not wanting to tie themselves to the RC cart.

Re: Rust means never having to close a socket

#86

Post by Ericson2314 »

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…

I use and love Rust, but I must admit this is true. GC has some advantages over the current options. Fear not however as post 1.0, optional GC will be most likely added to Rust. See https://github.com/rust-lang/rfcs/pull/244.

Re: Rust means never having to close a socket

#89

Post by steveklabnik »

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 the post works today.

This doesn't mean that Rust is absolutely perfect. There's tons of stuff that is awkward to express, and tons of more features that would be nice to have. But the core all works, and works well.

Re: Rust means never having to close a socket

#90

Post by kibwen »

Dewie wrote: post #83
kibwen wrote: post #80

Earlier quoted context omitted.

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

> 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. That's interesting. So this holds for languages and applications where you could get away with not knowing the automatic memory management implementation and adjusting your design based on that? For example, that you don't have to worry your…

  > Would you prefer using Rust for problems and domains 
  > where you strictly don't need the efficiency and 
  > determinism (like memory usage) you get from using Rust?
It would highly depend on circumstance. How often is my code going to be run? How long will it be maintained for, and how often will it be updated, and by whom?

I think we all have a hierarchy of sorts: bash or Perl for one-off, disposable scripting tasks; Python or some other light dynamic language for when things start getting more serious, but are still personal projects; C# or some other relatively heavyweight hammer for when we're writing code that will live beyond our control, maintained by others and run for years and years.

I don't write production code in Rust yet (heavens no, not until 1.0 at least... godspeed to wycats :P ) but right now it's in that third category of languages where I trust that it can be maintained by a team and trusted to exist for years. However, I would consider Rust for that second category of somewhat-serious personal projects, because I know too well how such "personal projects" can vault unexpectedly into that third category of "mission-critical team projects". But before that, I'd need to wait for the library ecosystem to mature.

EDIT: I should clarify too that resource management is only part of the reason why I don't worry about Rust code. There's also stuff like the ability to know that a given global variable is immutable, and can't be changed out from under me. Or knowing that an innocent-looking block of code can't unexpectedly kill the process (divide-by-zero notwithstanding).

Post reply on HN