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

151–160 of 161 posts

Re: A 30 minute introduction to Rust

#151

Post by bsaul »

steveklabnik wrote: post #102
bsaul wrote: post #100

Is rust borrowing any kind of code from what is used for objective C ARC technology relative to detecting the lifetime of a variable and automaticaly freeing the resource ? Is it a common known algorithm ?

Everything is written in Rust, so we're not borrowing the code. Reference counting is very common: http://en.wikipedia.org/wiki/Reference_counting

I had the impression that rust and ARC were doing a bit of static code analysis to detect when a "reference count decrease/increase" could be performed ( thus the "automatic" part in ARC), and insert code at compile time. Which seems a bit more complicated than simply decrease them dynamically when a pointing is object is destroyed. But now that i come to think of it, things look a little blurry for me on that part.

Re: A 30 minute introduction to Rust

#152

Post by silon3 »

kibwen wrote: post #75
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…

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…

>Note that's just dereferencing: there's nothing inherently unsafe about just creating and passing around the pointers themselves.

Sure there is. Passing around multiple pointers can result in a double free and then the dangerous dereference can happen. I'm guessing the developer must be careful when writing unsafe blocks to make sure this doesn't happen.

Re: A 30 minute introduction to Rust

#153

Post by octo_t »

silon3 wrote: post #152
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…

>Note that's just dereferencing: there's nothing inherently unsafe about just creating and passing around the pointers themselves. Sure there is. Passing around multiple pointers can result in a double free and then the dangerous dereference can happen. I'm guessing the developer must be careful when writing unsafe blocks to make sure this doesn't happen.

but they are safe until you decide to do that deferencing, otherwise they're just uint_ptrs really.

Re: A 30 minute introduction to Rust

#154

Post by coldtea »

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…

>I happen to write like I talk, it gets good and bad reviews. A more neutral style would be more appropriate if/when this gets pulled into Rust itself, thanks, that's a great point

I think the style's alright. I also like the tone of the tutorial on the Rust website, don't know if you were involved with that too.

>Thanks for the great feedback. :)

FWIW, I found the feedback to be a little too condescending for what is a volunter effort to help people understand a new language.

Re: A 30 minute introduction to Rust

#155

Post by dbaupp »

silon3 wrote: post #152
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…

>Note that's just dereferencing: there's nothing inherently unsafe about just creating and passing around the pointers themselves. Sure there is. Passing around multiple pointers can result in a double free and then the dangerous dereference can happen. I'm guessing the developer must be careful when writing unsafe blocks to make sure this doesn't happen.

Unsafe behaviours with raw pointers:

  - dereferencing
  - arithmetic (implemented as ptr.offset(number) in the stdlib), 
    since it is undefined behaviour for LLVM to move a pointer to
    point outside* of the object that it came from originally 
    (even without deferencing)
Everything else is OK. (Although the only other thing possible is passing it around as "black box" value.)

*One byte past the end is ok.

Re: A 30 minute introduction to Rust

#156

Post by eatfish »

eridius wrote: post #49
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.

Agreed. My experiments with rust have been uphill because I've been fighting with lifetimes, ownership and borrowing.

For the most part I failed to see that I -needed- unsafe code in some situations. Instead I was trying (failing) to annotate my code to ridiculous levels with lifetimes. It was really frustrating.

I don't think the current docs do a great job of putting unsafe in a suitable perspective. It's somewhat downplayed IMO.

Still, I've learned now and it's been pretty pleasant after that.

FWIW I've been doing c++ for maybe 18 years, writing device drivers, game engines, compiler development. I thought rust was made for me but it's been tough, much more so than any other language except maybe SML!

Re: A 30 minute introduction to Rust

#157

Post by volatile »

scott_s wrote: post #123
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…

You'll probably be interested in the Singularity project at Microsoft Research: http://research.microsoft.com/en-us/projects/singularity/ Much of the kernel is implemented in managed code.

I remember hearing about Singularity a few years back - it sounded promising. Looking at the linked page, there doesn't seem to be anything published or presented since 2009. Anyone know what's going on with Singularity these days?

Re: A 30 minute introduction to Rust

#158

Post by anon1385 »

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…

Your C example is caught by the clang static analyzer:

  main.c:14:20: warning: Use of memory after it is freed
    printf("%d\n", *v);
                   ^~

Re: A 30 minute introduction to Rust

#159

Post by pjmlp »

masklinn wrote: post #101
pjmlp wrote: post #78

Earlier quoted context omitted.

The main issue with that, is that although there are lots of GC enabled languages to choose from, not all of them have mainstream AOT compilers available. Shipping a VM with the product is not always possible/desireable.

Even with that constraint, OCaml's 15 years old, so's SML/MLTon, D's 12 years old (D2 is 6 years old), Eiffel's nearly 30 (and moved under ECMA in 2005), Common Lisp can be compiled to native via CMUCL, SBCL or CCL and Scheme via Chicken Scheme or Chez Scheme. And these are off the top of my head, I'm sure there are others.

I know all those languages and played with them one time or the other.

I am also active on D forums.

However the mainstream developers aren't aware, or even care, about those languages. Which leaves us in the current state of affairs in the industry.

Re: A 30 minute introduction to Rust

#160

Post by twic »

seanmcdirmid wrote: post #133
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.

Jikes RVM was an absolutely amazing project. Superb work.

googles

Jikes RVM is an absolutely amazing project. Superb work. And i'm very glad to see it's still under somewhat active development!

http://jikesrvm.org/

Post reply on HN