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

51–60 of 165 posts

Re: Rust means never having to close a socket

#51

Post by steveklabnik »

dengnan wrote: post #48
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…

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.

This kind of thing is coming. I wanted to let the Guide sit for a while before I got to it.

Re: Rust means never having to close a socket

#52

Post by Animats »

pcwalton wrote: post #6
justinsb wrote: post #4

C++11 introduces unique_ptr, which has a lot of the same safety characteristics. Rust's syntax does seem much nicer, though.

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

Right. C++ used to have auto_ptr, which did roughly the same thing, but didn't quite get it right. Transferring ownership was always iffy. There were, I think, three standardized versions of auto_ptr, all bad. Now there's unique_ptr, which is supposed to be better.

The lesson of C++ is that you can't bolt on safety by using templates to paper over the underlying mess. The mold always seeps through the wallpaper. The usual problem is that at some point you need raw pointers to call some API. If you can get raw pointers, the abstraction has to have a leak.

Re: Rust means never having to close a socket

#53

Post by dengnan »

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

Excellent site! Although it is still under development, I can see it'd become very important to the community.

Re: Rust means never having to close a socket

#54

Post by kibwen »

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 most prior languages with ownership work). But you can't have borrowing without tracking ownership.

Re: Rust means never having to close a socket

#55

Post by ben0x539 »

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 "&"?

Well, really the default is passing trivial implicitly-copyable values like integers. You probably don't want to write a & every time you pass an i32 to a function, so that sort of thing gets the default just-passing-bytes-around syntax from other C-like languages.

For resources or generally things that require cleaning up when they disappear, that just extends into the transfer, logically a shallow copy with the original variable flagged as dead in the type system.

The & symbol denotes a reference type, and it's an explicit thing in the type system and not just an annotation as part of the function call process. It can show up anywhere you'd write a type, things like `Option` or other types with `&T` fields aren't too uncommon, and `&&T` is also a type.

I haven't really thought it through, I guess, but modifying a type `T` with a `&` to make it a pointer type `&T` seems to compose a lot better than making all types `T` implicitly pointers and requiring `&T` whenever you want the value inline and not behind a pointer indirection, whether in a local variable or as a field in a struct.

Re: Rust means never having to close a socket

#56

Post by crantanplum »

pcwalton wrote: post #6
justinsb wrote: post #4

C++11 introduces unique_ptr, which has a lot of the same safety characteristics. Rust's syntax does seem much nicer, though.

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

Re: Rust means never having to close a socket

#57

Post by steveklabnik »

ben0x539 wrote: post #50
steveklabnik wrote: post #21

Earlier quoted context omitted.

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

Yes, it's hard to figure out which way to talk about it. Rc isn't really part of the borrow checker... it technically subverts it to do its own thing internally.

Re: Rust means never having to close a socket

#58

Post by wycats »

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…

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 with a bit of an intuition for "value types" (simple types whose identity is bound up in the shallow memory that they contain).

In other GC'ed languages, there is a fixed set of these kinds of values (often called "primitives"). In Rust, any simple user-specified type can be a "primitive".

Re: Rust means never having to close a socket

#59

Post by ef4 »

msopena wrote: post #42
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.

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

That's a good question.

If dropping was really implemented that way, every type would need to implement the Drop trait. Because otherwise there would be no way to free any memory at all.

Instead, Rust knows how to free any object. Implementing Drop is optional, and you only need to do it if you want some custom behavior at destruction.

Re: Rust means never having to close a socket

#60

Post by ben0x539 »

steveklabnik wrote: post #57
ben0x539 wrote: post #50

Earlier quoted context omitted.

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.

Yes, it's hard to figure out which way to talk about it. Rc isn't really part of the borrow checker... it technically subverts it to do its own thing internally.

I wouldn't really consider the whole ownership thing or specifically the mechanism that inserts destructor calls at the logical end of a value's lifetime part of the borrow checker either, but I dunno how the implementation is laid out.
Post reply on HN