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

41–50 of 165 posts

Re: Rust means never having to close a socket

#41

Post by [deleted] »

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…

[deleted]

Re: Rust means never having to close a socket

#42

Post by msopena »

pcwalton wrote: post #9
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.

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

I'm curious about the drop implementation, which I found here (http://doc.rust-lang.org/src/core/home/rustbuild/src/rust-bu...):

pub fn drop(_x: T) { }

I understand that the drop function is simply taking ownership of the passed value so Rust knows that once "drop" finishes, the _x can be 'dropped'.

But I though that the T had to be bound to have "Drop" trait (i.e. T: Drop) so that Rust knows it's possible to insert the call to 'drop' like _x.drop()?

Re: Rust means never having to close a socket

#43

Post by ef4 »

solipsism wrote: post #36
ef4 wrote: post #5

Earlier quoted context omitted.

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.

Yes, you are correct.

What I was trying to explain is that the timing is deterministic and immediate. People are used to unpredictable GC and rightly don't want to trust it with thing like this.

Re: Rust means never having to close a socket

#44

Post by ben0x539 »

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?

One reason is probably emulating the way RAII works in C++, and allowing "low level" code to use idioms like

    {
        let _lock = acquire_lock();
        
        use_resource();
    } // lock is released here, whether use_resource() returned or caused stack unwinding

Re: Rust means never having to close a socket

#45

Post by microtonal »

DAddYE wrote: post #39
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

Thank you! That's really a nice and quick way to get started with Rust. Any plans to print this in the future?

Re: Rust means never having to close a socket

#46

Post by ben0x539 »

solipsism wrote: post #36
ef4 wrote: post #5

Earlier quoted context omitted.

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.

Yeah, if you hold on to the thing in your scope, it won't go out of scope and won't be disposed of.

Re: Rust means never having to close a socket

#47

Post by bobfunk »

Awesome post. Best explanation I've seen so far how Rust's resource management. Always impressed with Yehuda's ability to explain complex techniques and abstractions clearly.

Having the compiler eliminate resource leaks is really, really handy. This is one thing that's very easy to get wrong in go. Will be interesting to see how much of a cost the upfront typing has during quick prototyping or explorative programming, but its great to see this kind of type system make it into something that's well on track to becoming a mainstream programming language.

Re: Rust means never having to close a socket

#48

Post by dengnan »

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…

Exactly! I think there's lack of document which quickly goes through basics and spends more time on rust-specific features. (Or I'm too lazy to find them?) For developers programming for decades, we do not need to repeat too much about integers, characters, etc.

I personally like to use slides to learn things. I'm not sure if this is typical, but slides are usually concise and easy to read.

Re: Rust means never having to close a socket

#50

Post by ben0x539 »

steveklabnik wrote: post #21
Leon wrote: post #17

Earlier quoted context omitted.

I have not used Rust before; does working with statistical analysis of runtime environments hinder debugging? In a multithreaded environment - does it pause the world for its runtime analysis or are there locks on shared resources representing ownership of individual objects, or does it do copies on writes of resources for idempotent operations as the references are moved around environment for lockless operations?

> does it pause the world for its runtime analysis The borrow checker is _entirely_ at compile time.

To be fair, resource disposal is sometimes "delegated" to runtime. But it's always a local concern, like a reference counter for a shared resource, or a mutable `Option` value that can have the R resource taken out of it or put back into it dynamically. There's no creepy overarching runtime system that tracks individual objects from a distance.
Post reply on HN