Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A 30 minute introduction to Rust

words.steveklabnik.com

Post reply on HN
Print view View original

141–150 of 161 posts

Re: A 30 minute introduction to Rust

#141

Post by dherman »

steveklabnik wrote: post #73
masklinn wrote: post #68

Earlier quoted context omitted.

Probably, with a slightly tricky ownership issue leading to use after free (a well known source of exploits http://cwe.mitre.org/data/definitions/416.html ) e.g. allocate to the heap, pass to a function which deallocates it (assuming that it has ownership) and use it after the call, e.g. #include #include void destroyer(int* val) { printf("%d\n", *val); free(val); } int main(int argc, char** argv) { int* v = malloc(s…

Thanks so much. I'll certainly have to use this if this makes it to Rust proper.

The downside of picking subtler, more intricate examples is that you waste your reader's time trying to understand the subtleties of the example, which isn't teaching them anything about Rust.

Another option is to say something like, "For the sake of brevity, this is a very simple and arguably obvious violation of safety. In practice, there are many subtle and hard-to-diagnose sources of unsafety in C++, even when you use safer abstractions like shared_ptr." This allows you to avoid getting sidetracked and losing your reader, while heading off skepticism of readers with more knowledge about C++.

Re: A 30 minute introduction to Rust

#142

Post by BlackDeath3 »

nfoz wrote: post #118
0x001E84EE wrote: post #63

I'm a big fan of that kudos button! Very nice website and an interesting introduction to Rust.

I find it annoying to the point of offensive. Actions being actived on mouse-hover is terrible; I did not intend to give "kudos" but was curious what might be linked under it, and suddenly an action is recorded. Now I can't consider any webpage safe and have to watch where my mouse goes; that's wrong.

Three cheers for NoScript!

I understand that it doesn't really solve your problem, but if it's safety you're worried about...

Re: A 30 minute introduction to Rust

#143

Post by dbaupp »

pbsd wrote: post #140
pcwalton wrote: post #138

Earlier quoted context omitted.

> The upside is that this bug is easy to catch since the invalid access is guaranteed to try to access a null pointer, and will crash instead of giving garbled results. GCC and LLVM optimize based on the assumption that null pointers are never dereferenced, so this is actually undefined behavior, no? Anything can happen.

You're right that it's UB, good point. It's hard to think what a sane compiler would do in this case besides going through with the dereference, though.

A pointer dereference allows the compiler to assume that a pointer is non-NULL, so it can then perform "invalid" optimisations (like dead-code removal), this post contains an very small example: http://blog.llvm.org/2011/05/what-every-c-programmer-should-...

Re: A 30 minute introduction to Rust

#144

Post by evincarofautumn »

valtron wrote: post #129
kibwen wrote: post #75

Earlier quoted context omitted.

For reference, the following actions are what are enabled within `unsafe` blocks in Rust: 1. Dereferencing raw pointers (a.k.a. "unsafe" pointers). Note that's just dereferencing: there's nothing inherently unsafe about just creating and passing around the pointers themselves. 2. Calling a Rust function that has been marked with the entirely-optional `unsafe` keyword. 3. Calling an external function via the C FFI, al…

Don't points 2 & 3 together imply that anything that uses built-ins, which I assume are implemented with C FFI, is `unsafe`?

No, “unsafe” means “evaluate this unsafe block as though it were safe”. This enables Modula-style safe interfaces for unsafe implementations.

Re: A 30 minute introduction to Rust

#145

Post by bjz_ »

pbsd wrote: post #134
masklinn wrote: post #68

Earlier quoted context omitted.

Probably, with a slightly tricky ownership issue leading to use after free (a well known source of exploits http://cwe.mitre.org/data/definitions/416.html ) e.g. allocate to the heap, pass to a function which deallocates it (assuming that it has ownership) and use it after the call, e.g. #include #include void destroyer(int* val) { printf("%d\n", *val); free(val); } int main(int argc, char** argv) { int* v = malloc(s…

Analogous example in C++11, using unique_ptr (which Rust's owned pointer models): #include #include void destroyer(std::unique_ptr x) { printf("%d\n", *x); // x is deallocated here } int main() { auto x = std::make_unique (3); // destroyer(x); ERROR: ownership must be transferred explicitly destroyer(move(x)); // Override with an explicit move printf("%d\n", *x); // Guaranteed to segfault return 0; } This is somewhat…

Does `unique_ptr` incur a run-time peanalty for those checks?

Re: A 30 minute introduction to Rust

#146

Post by bjz_ »

pcwalton wrote: post #46
tptacek wrote: post #39

Earlier quoted context omitted.

I don't mean to be uncharitable; it seems like a legitimate design. I'm just wondering if there are other magic pointer types or type system features that also protect memory. To me, fewer mechanisms is better. On the other hand, building libraries to abstract unsafe pointers has been somewhat discredited by C++ and shared_ptr.

> I'm just wondering if there are other magic pointer types or type system features that also protect memory. Oh, I see. In that case yes, there are also explicit lifetimes, which allow you to squeeze out more expressiveness to cover most of C++'s use cases for pointers/references: http://static.rust-lang.org/doc/master/guide-lifetimes.html There are no more magic pointer types, though; lifetimes are just annotations…

> proof is in the works

That's very exciting!

Re: A 30 minute introduction to Rust

#147

Post by bjz_ »

noelwelsh wrote: post #93
steveklabnik wrote: post #88

Earlier quoted context omitted.

I think that's totally true. It's not just so much because of Mozilla, but also because Rust is probably closer to C++ than Java... The official tutorial contains much of that information.

Funnily, I see at being closer to Scala than either C++ or Java. I think it all comes down to background. The official tutorial isn't very good on issues of memory management. The first mention of managed references (I assume that means GCed) is in an example in section 11. Nowhere does it actually explain what managed means (and if I missed it, I blame the tutorial for not making it explicit enough!)

Well that's the thing, while Rust occupies the same space as C++, but it doesn't just take its inspirations from there. It also takes it from functional languages like ML or Haskell (the compiler was originally written in OCaml).

Re: A 30 minute introduction to Rust

#148

Post by pbsd »

bjz_ wrote: post #145
pbsd wrote: post #134

Earlier quoted context omitted.

Analogous example in C++11, using unique_ptr (which Rust's owned pointer models): #include #include void destroyer(std::unique_ptr x) { printf("%d\n", *x); // x is deallocated here } int main() { auto x = std::make_unique (3); // destroyer(x); ERROR: ownership must be transferred explicitly destroyer(move(x)); // Override with an explicit move printf("%d\n", *x); // Guaranteed to segfault return 0; } This is somewhat…

Does `unique_ptr` incur a run-time peanalty for those checks?

For all intents and purposes no. unique_ptr is nothing more than a pointer container that disables copying but allows moving. Therefore only one unique_ptr should be owning a pointer at any given time (unless, like everything in C++, you go around it).

Re: A 30 minute introduction to Rust

#149

Post by fanf2 »

ChuckMcM wrote: post #92
kibwen wrote: post #81

Earlier quoted context omitted.

> I need to write a lot of unsafe code. To contrast with application-level code, pcwalton has measured that less than 1% of Servo's code is contained within `unsafe` blocks.

Exactly, and of course this leads me to wondering about computer architectures that "require" unsafe things in their kernels, versus things like Multics where the OS and hardware co-operated at some level to make things safe. Lots of interesting questions.

One possibility might be to add hardware support for fine-grained capability security - http://www.cl.cam.ac.uk/research/security/ctsrd/

Re: A 30 minute introduction to Rust

#150

Post by zurn »

pjmlp wrote: post #69
masklinn wrote: post #61

Earlier quoted context omitted.

Go being mandatorily GC'd I don't think it's relevant to the issue of improving on C/C++ for their existing use cases.

There are still lots of user space applications written in C/C++ nowadays, that could be easily rewriten in Go or any other safer language with native code compilers, without noticeble performance lost for the problem being solved.

The remainig issue for many of those is "need better GC". Apps like games could be brought in with near-pauseless GC that currently seems to exist only in Java land.

(Yes you can work around the current GC's but this drives away some developers)

Post reply on HN