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

31–40 of 165 posts

Re: Rust means never having to close a socket

#31

Post by kibwen »

Leon wrote: post #19
pcwalton wrote: post #9

Earlier quoted context omitted.

> Does a drop somehow say something to the type system as well, disallowing reads and writes afterwards? Yes.

The other poster says it proves operations won't happen again - does it do both?

Yep! The owner of a thing can do the following:

1. Give ownership away to something else.

2. Free the object at the end of the scope.

In order to do anything to the object, you give up ownership to the function that does it (which can then give it back, if it doesn't need ownership of the value any more and doesn't want to free it itself). This even applies to the `drop` function, which just takes ownership and then does nothing whatsoever to the passed-in value, allowing it to go out of scope immediately. So once you've called `drop(foo)`, you no longer own the value and so can't give it away to any reading or writing function, and you can't drop it for the very same reason.

Re: Rust means never having to close a socket

#32

Post by doe88 »

dengnan wrote: post #22

Anyone has good learning resources about rust? I find it's a very interesting language but the document on its web site is so limited. Many topics are not covered or explained in vague terms. The new guide is a good starting point but still needs some improvement.

For newcomers I think the documentation is quite good. But where I think there is currently a big problem it is for intermediate / advanced level documentations, it is very limited. Sometimes you'll read some code and say to yourself "I didn't know I could do that, cool". In order to grasp more knowledge you'll have to read RFC, commit logs, issues, and source codes, but because it certainly is not your main job it's really time consuming.

Re: Rust means never having to close a socket

#33

Post by illumen »

wycats wrote: post #27
illumen wrote: post #14

For files python[0] does not need an explicit with to close the file. It gets closed when references reach zero. [0] For the pedants repeating each other in the replies... Where by python, I mean the implementation that 98% of people use, called python, which the competition calls CPython. Yes it is a great feature of the implementation, like the deterministic memory management through reference counting.

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…

CPython is the implementation that 98% of the market uses, but you are partially correct for that other 2%.

You are also wrong for CPython which does NOT require the garbage collector to be on, and DOES release the file in a deterministic way.

Simply, the article is misleading with regards to python.

Re: Rust means never having to close a socket

#35

Post by steveklabnik »

doe88 wrote: post #32
dengnan wrote: post #22

Anyone has good learning resources about rust? I find it's a very interesting language but the document on its web site is so limited. Many topics are not covered or explained in vague terms. The new guide is a good starting point but still needs some improvement.

For newcomers I think the documentation is quite good. But where I think there is currently a big problem it is for intermediate / advanced level documentations, it is very limited. Sometimes you'll read some code and say to yourself "I didn't know I could do that, cool". In order to grasp more knowledge you'll have to read RFC, commit logs, issues, and source codes, but because it certainly is not your main job it's…

Yup. I've been working from the bottom up, so I'd agree with your analysis wholeheartedly. As the rest of the Guides fill out, it'll get better.

Re: Rust means never having to close a socket

#36

Post by solipsism »

ef4 wrote: post #5
kevingadd wrote: post #2

Using automated resource management to drive socket (and handle, in general) lifetime is a terrible idea. Sometimes you really, really want to close a handle at a given time. The disposal of associated resources is another matter, and automating that is fine, but leaving a socket open 5 seconds too long is simultaneously 'correct' from a garbage collection perspective and totally, totally not the right thing to do. T…

There is no garbage collection in rust. There is no possible "five second gap". 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. Or just let it go out scope and it will be dropped immediately. NOT eventually garbage collected.

Just to be clear (and to check this myself -- I'm just starting to learn Rust), a five second gap is actually possible right? Say I use a socket, stop using it, don't call drop(socket), and I don't leave the scope for 5 seconds because I'm busy doing something.

Re: Rust means never having to close a socket

#37

Post by kibwen »

hrjet wrote: post #30
pcwalton wrote: post #9

Earlier quoted context omitted.

> Does a drop somehow say something to the type system as well, disallowing reads and writes afterwards? Yes.

Curious to know why `drop` isn't called automatically by the compiler as soon as possible (since the type system already seems to know it is safe). Is there a trade-off involved here?

Freeing resources as soon as humanly (computerly?) possible will optimize your memory usage, but can actually be worse for execution speed. If you're willing to use slightly more memory, it's generally faster to free memory in coarse chunks than one-thing-at-a-time. So even though Rust can conceivably free memory sooner, it might as well defer freeing until the end of the scope, since it can prove that that's safe.

To take this to the logical extreme, see this awesome post from Walter Bright, where he doubles the speed of the D compiler by providing a custom malloc implementation that never frees, leaking all memory until the end of the process: http://www.drdobbs.com/cpp/increasing-compiler-speed-by-over...

Re: Rust means never having to close a socket

#38

Post by doe88 »

steveklabnik wrote: post #35
doe88 wrote: post #32

Earlier quoted context omitted.

For newcomers I think the documentation is quite good. But where I think there is currently a big problem it is for intermediate / advanced level documentations, it is very limited. Sometimes you'll read some code and say to yourself "I didn't know I could do that, cool". In order to grasp more knowledge you'll have to read RFC, commit logs, issues, and source codes, but because it certainly is not your main job it's…

Yup. I've been working from the bottom up, so I'd agree with your analysis wholeheartedly. As the rest of the Guides fill out, it'll get better.

Great! keep-up the good work, Rust is awesome.

Re: Rust means never having to close a socket

#39

Post by DAddYE »

dengnan wrote: post #22

Anyone has good learning resources about rust? I find it's a very interesting language but the document on its web site is so limited. Many topics are not covered or explained in vague terms. The new guide is a good starting point but still needs some improvement.

The best one other than the official is this:

http://rustbyexample.com

Re: Rust means never having to close a socket

#40

Post by mwcampbell »

illumen wrote: post #33
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…

CPython is the implementation that 98% of the market uses, but you are partially correct for that other 2%. You are also wrong for CPython which does NOT require the garbage collector to be on, and DOES release the file in a deterministic way. Simply, the article is misleading with regards to python.

Still, do you want to bake assumptions based on CPython's implementation into your codebase, then have those assumptions invalidated when you later switch to PyPy to take advantage of the JIT compiler?
Post reply on HN