Live data from Hacker News

A 30 minute introduction to Rust

words.steveklabnik.com

121–130 of 161 posts

Re: A 30 minute introduction to Rust

#121

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…

> I happen to write like I talk, it gets good and bad reviews. I found it unusually clear, which I liked a lot. There was a bit at the end to do with unsafe that was a bit difficult to follow, 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.

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

Re: A 30 minute introduction to Rust

#122
post #114
post #107

Earlier quoted context omitted.

Rust uses the `Option` type for that (name taken from Scala and ML, it's called `Maybe` in Haskell). http://static.rust-lang.org/doc/master/std/option/index.html What's neat is that if you stuff a pointer inside an `Option`, then not only is it guaranteed to be memory-safe but it also compiles down to a plain old nullable pointer at runtime, so there's no extra overhead while still retaining safety.

So it doesn't have "null" but it has "None." On the linked page: // Remove the contained string, destroying the Option let unwrapped_msg = match msg { Some(m) => m, None => ~"default message" }; Now why is there that ";" at the end? Before that there is a construct without it: // Take a reference to the contained string match msg { Some(ref m) => println!("{}", *m), None => () } And did we have take the "reference" t…

[deleted]

Re: A 30 minute introduction to Rust

#123

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.

Re: A 30 minute introduction to Rust

#124
post #106

Earlier quoted context omitted.

> I wrote it this way because the systems people I talk to are skeptical at times that a compiler knows best. Well, the best way to combat that would be demonstrate that cool things can be done safely in Rust, but that probably requires a lot more than fits in your introduction. I think you could allay that fear by addressing it directly, rather than saying that Rust's secret sauce is unsafety.

Hm. I thought that talking about building ARC and discussing its implementation was something cool that directly addresses it. What would you like to see?

I think talking about how ARC is implemented in Rust is cool. I would just pitch it differently.

I think what I don't like about your current description is that it makes it seem like unsafety is what allows you to _have_ Arc in the language. Instead, unsafe blocks are what allow you to _implement_ Arc inside the language.

I'd start the footnote this way:

---------------

A footnote: Implementing Arc

So, the Rust language doesn't let us use shared mutable state in dangerous ways, but what happens if we really need to get down and dirty? For example, what if we wanted to _implement_ `Arc` ourselves?

In fact, `Arc` and `RWArc` are both implemented in Rust. Inside their implementations, they use locks, low-level memory operations, and everything else you might see in a C++ program. However, anytime we use these features, we have to wrap them in an `unsafe` block.

...

---------------

I hope that conveys the different emphasis that I'm talking about.

Re: A 30 minute introduction to Rust

#125
post #114
post #107

Earlier quoted context omitted.

Rust uses the `Option` type for that (name taken from Scala and ML, it's called `Maybe` in Haskell). http://static.rust-lang.org/doc/master/std/option/index.html What's neat is that if you stuff a pointer inside an `Option`, then not only is it guaranteed to be memory-safe but it also compiles down to a plain old nullable pointer at runtime, so there's no extra overhead while still retaining safety.

So it doesn't have "null" but it has "None." On the linked page: // Remove the contained string, destroying the Option let unwrapped_msg = match msg { Some(m) => m, None => ~"default message" }; Now why is there that ";" at the end? Before that there is a construct without it: // Take a reference to the contained string match msg { Some(ref m) => println!("{}", *m), None => () } And did we have take the "reference" t…

Most of this is out of the scope of this tutorial, but is in the comprehensive one.

match is an expression, but let is a statement. In the first example, the match expression is used inside of the let statement, in order to produce what is assigned.

I'm not 100% sure if you _must_ take that reference, but given that it's a pointer, that makes sense. In the previous version, it's simply returning a value, but println! needs the contents, not the pointer itself.

Inside the linked Option enum, it shows both: http://static.rust-lang.org/doc/master/std/option/enum.Optio...

It's an enum like any other.

That said, these are all good points, and this documentation should be improved. Thanks, I'll add this to my list.

Re: A 30 minute introduction to Rust

#126

Earlier quoted context omitted.

> I happen to write like I talk, it gets good and bad reviews. I found it unusually clear, which I liked a lot. There was a bit at the end to do with unsafe that was a bit difficult to follow, 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.

> 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 implemented that wasn't obvious to me.

Re: A 30 minute introduction to Rust

#127
post #124

Earlier quoted context omitted.

Hm. I thought that talking about building ARC and discussing its implementation was something cool that directly addresses it. What would you like to see?

I think talking about how ARC is implemented in Rust is cool. I would just pitch it differently. I think what I don't like about your current description is that it makes it seem like unsafety is what allows you to _have_ Arc in the language. Instead, unsafe blocks are what allow you to _implement_ Arc inside the language. I'd start the footnote this way: --------------- A footnote: Implementing Arc So, the Rust lang…

Certainly. Thanks. That's much more clear.

Re: A 30 minute introduction to Rust

#128
post #114
post #107

Earlier quoted context omitted.

Rust uses the `Option` type for that (name taken from Scala and ML, it's called `Maybe` in Haskell). http://static.rust-lang.org/doc/master/std/option/index.html What's neat is that if you stuff a pointer inside an `Option`, then not only is it guaranteed to be memory-safe but it also compiles down to a plain old nullable pointer at runtime, so there's no extra overhead while still retaining safety.

So it doesn't have "null" but it has "None." On the linked page: // Remove the contained string, destroying the Option let unwrapped_msg = match msg { Some(m) => m, None => ~"default message" }; Now why is there that ";" at the end? Before that there is a construct without it: // Take a reference to the contained string match msg { Some(ref m) => println!("{}", *m), None => () } And did we have take the "reference" t…

The first example is an expression. The result of `match` will be assigned to `unwrapped_msg`.

The second example is a statement. Thus, we're not using the result of the `match` statement.

Re: A 30 minute introduction to Rust

#129
post #75

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…

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

Re: A 30 minute introduction to Rust

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

I'm not 100% sure exactly what you mean by 'built-ins', but Rust is almost entirely written in Rust. I don't think there's anything major implemented via C FFI in the compiler itself.
Post reply on HN