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

41–50 of 161 posts

Re: A 30 minute introduction to Rust

#41

Post by tptacek »

steveklabnik wrote: post #19
tptacek wrote: 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…

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.

Re: A 30 minute introduction to Rust

#42

Post by 45g »

> You can see how this makes it impossible to mutate the state without remembering to aquire the lock.

Not quite true. Looking at the type signature of e.g. RWArc::write I see this:

    fn write(&self, blk: |x: &mut T| -> U) -> U
which means I could probably do:

    let mut n = local_arc.write(|nums| {
         nums[num] += 1;
         return ~(*nums);
     });
    n[2] = 42;

Re: A 30 minute introduction to Rust

#43

Post by samth »

I think the emphasis on "unsafe" isn't helpful. As far as I can tell, the only thing that "unsafe" is enabling is that Arc and RWArc are written in Rust rather than in C in the runtime (the way they'd be in Go, or Erlang, or Haskell). The things that make Rust able to do what it does are ownership and tasks and lifetimes and affine types -- all the things the post covers before talking about "unsafe".

Also, it gives the impression that there's something fundamentally unsafe about all of this, whereas the whole point is that these abstractions are _safe_ to use.

Re: A 30 minute introduction to Rust

#44

Post by steveklabnik »

tptacek wrote: post #41
steveklabnik wrote: post #19

Earlier quoted context omitted.

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…

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?

Re: A 30 minute introduction to Rust

#45

Post by [deleted] »

45g wrote: post #42

> You can see how this makes it impossible to mutate the state without remembering to aquire the lock. Not quite true. Looking at the type signature of e.g. RWArc::write I see this: fn write (&self, blk: |x: &mut T| -> U) -> U which means I could probably do: let mut n = local_arc.write(|nums| { nums[num] += 1; return ~(*nums); }); n[2] = 42;

[deleted]

Re: A 30 minute introduction to Rust

#46

Post by pcwalton »

tptacek wrote: post #39
pcwalton wrote: post #21

Earlier quoted context omitted.

> This isn't so much an introduction to Rust as it is an introduction to Rust's concurrency model. Ownership is really central to Rust. It's central to both memory management and concurrency: to work with Rust you need to understand it. > 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's just a simple example. The sa…

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 on references (&).

> On the other hand, building libraries to abstract unsafe pointers has been somewhat discredited by C++ and shared_ptr.

I think we do a lot better than C++. First of all, we believe our system is safe, unlike shared_ptr (proof is in the works). Second, shared_ptr isn't very fast, due to some design decisions like requiring atomic reference counting (which is an order of magnitude slower) and not being intrusive (requiring 2x the allocations). We also allow shared_ptr to be converted into references, allowing the programmer to eliminate a lot of reference count traffic. Most importantly, though, reference counting is something you only use if you actually need multiple references and you don't have one specific place to free the object in: in other words, you don't use reference counting in Rust much more than you'd use reference counting in C. Typical malloc/free patterns are handled with unique pointers.

Re: A 30 minute introduction to Rust

#47

Post by eridius »

45g wrote: post #42

> You can see how this makes it impossible to mutate the state without remembering to aquire the lock. Not quite true. Looking at the type signature of e.g. RWArc::write I see this: fn write (&self, blk: |x: &mut T| -> U) -> U which means I could probably do: let mut n = local_arc.write(|nums| { nums[num] += 1; return ~(*nums); }); n[2] = 42;

You're not letting anything escape. You're copying `nums` and then mutating your copy. And this only works because `nums` can be implicitly copied like this. If you changed it from `[int, ..3]` to `~[int]` you'd get a compiler error (as `~[T]` cannot be implicitly copied).

Re: A 30 minute introduction to Rust

#48

Post by rubiquity »

steveklabnik wrote: post #20
Jemaclus wrote: post #16

The last time I touched C code was my sophomore year in college, so maybe 12 years ago? As a result, the last time I had to deal with pointers and such was back then, as well. I'm primarily a web-dev. Ruby, PHP, and Javascript are the languages I'm most familiar with at the moment. Are there any Rust for Dummies-style tutorials floating around? As simple as this introduction is, it was still over my head...

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?

Re: A 30 minute introduction to Rust

#49

Post by eridius »

samth wrote: post #43

I think the emphasis on "unsafe" isn't helpful. As far as I can tell, the only thing that "unsafe" is enabling is that Arc and RWArc are written in Rust rather than in C in the runtime (the way they'd be in Go, or Erlang, or Haskell). The things that make Rust able to do what it does are ownership and tasks and lifetimes and affine types -- all the things the post covers before talking about "unsafe". Also, it gives…

I think `unsafe` is important to talk about. It's the escape hatch that lets you subvert the type system and do things that the compiler cannot statically reason about. The ability to implement Arc in pure Rust code is very important. But I do agree that it could have been presented perhaps in a different way.

Re: A 30 minute introduction to Rust

#50

Post by minimax »

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…

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

Post reply on HN