Live data from Hacker News

A 30 minute introduction to Rust

words.steveklabnik.com

61–70 of 161 posts

Re: A 30 minute introduction to Rust

#61
post #55

Earlier quoted context omitted.

> In modern C++ we are (hopefully) using smart pointers (std::unique_ptr, std::shared_ptr) to manage heap-allocated object lifetimes. Those aren't safe. There are many ways to cause use-after-free with unique_ptr: for example, placing a uniquely-owned object in a vector and clearing the vector in a method call on that object.

True, and hopefully the likes of D, Rust and Go will improve the situation. In the mean time, we can take advantage of modern C++ safe constructs instead of keep on using C, as new language adoption always takes time.

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.

Re: A 30 minute introduction to Rust

#64
post #3

I like this tutorial because dives straight into the most unique/unfamiliar parts of Rust (ownership/references) and gets them out of the way. It's a "learn the hard way"-style tutorial, and I think that's the best approach. Once you learn how ownership and borrowing work, along with ARCs and concurrency, everything else is really simple and just naturally falls out.

Agreed. I'd love to see an even more in depth document that takes a wide range of ownership/allocation patterns that are common in C and C++, shows Rust equivalents, and analyses why Rust can or cannot prove that they are safe (i.e. whether they require unsafe blocks or not). I don't have an intuitive sense yet for the boundaries of what Rust can automatically prove safe. How much C and C++ could be directly translated into safe Rust and how much would need to be reworked or put in unsafe blocks?

Re: A 30 minute introduction to Rust

#67
post #12

This isn't so much an introduction to Rust as it is an introduction to Rust's concurrency model. The example of returning a reference to an automatic variable isn't super compelling, since every competent C/C++ programmer knows not to do it. That bug does pop up every once in awhile, but almost always in the context of a function that returns a reference to one of many different possible variables depending on some c…

Salespeople qualify leads by determining if you're ready to buy or not. If you're not, they stop wasting time on you. The general idea for a quick introduction is to qualify your lead. So this isn't a "introduction to Rust's syntax" it's "an introduction to why you should (or should not) care about Rust." > since every competent C/C++ programmer knows not to do it. Everyone knows, yet programs still segfault. The poi…

A conversational style is fine, but those particular sentences actually get in the way. The style comes from the overall tone of the writing, not just sentences which talk to the reader directly.

Re: A 30 minute introduction to Rust

#68
post #41

Earlier quoted context omitted.

Oh, don't get me wrong, I'm sold on memory protection as a type system feature. I'm just suggesting that the example you're using might make it sound less valuable, because returning stack variable references isn't the most common kind of error made by C programmers; when you do that, more often than not your program doesn't work at all.

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(sizeof(int));
      *v = 3;
      destroyer(v);
      printf("%d\n", *v);
      return 0
    }
Which compiles without warnings using Clang (unless -Weverything, and even then the warnings are not related to use-after-free), works "correctly" in O0 and O1 (prints "3" twice) then breaks starting at O2 (prints "3" then "0"). (note: it always prints "3" twice with GCC 4.8, showing how fun these things are)

meanwhile the equivalent

    fn main() {
        let v = ~3;
        destroyer(v);
        println!("{}", *v)
    }

    fn destroyer(val: ~int) {
        println!("{}", *val)
    }
refuses to compile and explains why:

    test.rs:4:20: 4:21 error: use of moved value: `v`
    test.rs:4     println!("{}", *v)
                                  ^
    note: in expansion of format_args!
    :224:8: 224:50 note: expansion site
    :223:4: 225:6 note: in expansion of format!
    :241:45: 241:63 note: expansion site
    :240:4: 242:5 note: in expansion of println!
    test.rs:4:4: 5:1 note: expansion site
    test.rs:3:14: 3:15 note: `v` moved here because it has type `~int`, which is non-copyable (perhaps you meant to use clone()?)
    test.rs:3     destroyer(v);
                            ^
    error: aborting due to previous error
which can be fixed either by explicitly cloning the value, or by altering the sub-function to not consider it owns the pointer (or by removing the `println!` call in `main()`, thus transferring the ownership of the pointer to the sub-function safely, of course)

Re: A 30 minute introduction to Rust

#69
post #55

Earlier quoted context omitted.

True, and hopefully the likes of D, Rust and Go will improve the situation. In the mean time, we can take advantage of modern C++ safe constructs instead of keep on using C, as new language adoption always takes time.

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.

Re: A 30 minute introduction to Rust

#70
post #50

Earlier quoted context omitted.

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

"Second, shared_ptr isn't very fast, due to some design decisions like ... not being intrusive (requiring 2x the allocations)." Not quite. You can use std::make_shared to allocate the object and the ref count in one allocation. You get improved locality of reference as an added bonus.

And it uses (or may use) a lock-free implementation on many platforms.
Post reply on HN