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

131–140 of 161 posts

Re: A 30 minute introduction to Rust

#131

Post by steveklabnik »

kybernetikos wrote: post #126
steveklabnik wrote: post #121

Earlier quoted context omitted.

> but a sentence like 'but wait, RWArc is just a library, how come it was able to do the thing that I said the compiler wouldn't let you do?' would have cleared it up just fine. Hmmm. Isn't that what this says? > So, the Rust language does not allow for shared mutable state, yet I just showed you some code that has it. How’s this possible? The answer: unsafe.

Well for me at least, you're introducing the language so it seems like RWArc is part of that. I have no idea as to whether or not there are any little cheats put into things like RWArc that are not available to other code, so emphasizing that RWArc is the kind of thing I could have written myself would have helped me understand. It's that jump from being introduced to RWArc to considering how it might have been imple…

Gotcha. It seems a few other people had this issue too, I'll take care of it in the next iteration. Thank you!

Re: A 30 minute introduction to Rust

#132

Post by scott_s »

steveklabnik wrote: post #2

I like the overall structure, but I'm not sure about throwing so much syntax without explaining it in detail.

I think the amount of syntax you've shown is fine. Since there's C++ and Rust code that both do the same thing, it allows readers familiar with C++ to infer what the Rust syntax means. This is a much quicker process than reading "Here's how you write an if clause ..." prose.

When it comes to showing new languages to experienced programmers, I prefer showing code, and explaining what it accomplishes. Experienced programmers will start building up a Bayesian model of the syntax without being explicitly told.

I think of this as the "Dive Into Python" approach: http://www.diveintopython.net/

Re: A 30 minute introduction to Rust

#133

Post by seanmcdirmid »

ChuckMcM wrote: post #74

This is an excellent summary Steve, it also points out one of the challenges of 'System' languages, which is the requirement for 'unsafe.' One of the first things I did when I started working on Oak (which became Java) was to see about writing an OS in it. The idea being that if you could write an OS in a 'safe' language then you could have a more reliable OS. But we were unable to write it completely in Oak/Java and…

Sun eventually did JavaOS, though I'm not sure how much of its code was Java.

IBM did Jikes RVM (old name: Jalapeno) which was mostly, if not purely Java. They handled the bootstrapping problem with some clever ahead-of-time compilation + meta-programming. Even their GC is implemented in Java.

Re: A 30 minute introduction to Rust

#134

Post by pbsd »

masklinn wrote: post #68
steveklabnik wrote: post #44

Earlier quoted context omitted.

Absolutely, I don't want people to think I'm attacking a straw man. Maybe a heap allocated example would be better?

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 more helpful, but sadly the compiler cannot monitor the state of x at compile time, like Rust. 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.

Re: A 30 minute introduction to Rust

#135

Post by kybernetikos »

steveklabnik wrote: post #131
kybernetikos wrote: post #126

Earlier quoted context omitted.

Well for me at least, you're introducing the language so it seems like RWArc is part of that. I have no idea as to whether or not there are any little cheats put into things like RWArc that are not available to other code, so emphasizing that RWArc is the kind of thing I could have written myself would have helped me understand. It's that jump from being introduced to RWArc to considering how it might have been imple…

Gotcha. It seems a few other people had this issue too, I'll take care of it in the next iteration. Thank you!

Thanks for doing this, I've got much more appetite for reading about rust than can easily be sated, so it's very gratifying to have someone explain the key concepts so clearly and well.

Re: A 30 minute introduction to Rust

#136

Post by anon_d »

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`?

Just to clarify, using a `unsafe` block in a function does NOT mean that you have to tag that function as unsafe.

Re: A 30 minute introduction to Rust

#137

Post by pnathan »

rubiquity wrote: post #48
steveklabnik wrote: post #20

Earlier quoted context omitted.

I have you covered in that case as well: http://www.rustforrubyists.com/ I want to provide a version of the 30 minute intro that's not strictly for systems people as well, but you have to start somewhere.

Do you see Rust as a language that people will write the business domain type applications in or as a supplement to languages like Ruby, Python, etc. to write those "gotta have performance here" parts of the application?

I'm not the person you asked, but I see Rust as making a play in these areas:

- embedded systems

- games

- high performance + high correctness environments

Personally, I don't see it as a web-app or line of business app development languages. But it will allow you to create the components that the webapp and LoB apps call into. But I imagine if some people really like Rust for those purposes, they will start building the libraries and code infrastructure to make it easy and away we go.

Re: A 30 minute introduction to Rust

#138

Post by pcwalton »

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…

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

Re: A 30 minute introduction to Rust

#139

Post by steveklabnik »

kybernetikos wrote: post #135
steveklabnik wrote: post #131

Earlier quoted context omitted.

Gotcha. It seems a few other people had this issue too, I'll take care of it in the next iteration. Thank you!

Thanks for doing this, I've got much more appetite for reading about rust than can easily be sated, so it's very gratifying to have someone explain the key concepts so clearly and well.

Any time. If only there were five of me!

Re: A 30 minute introduction to Rust

#140

Post by pbsd »

pcwalton wrote: post #138
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…

> 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.
Post reply on HN