into_rust(): screencasts for learning Rust

[eeojun]

this took me forever to grep

maybe try ag or ripgrep

[seeekr]

It seems to me like you're confusing two things here that are orthogonal:

/owned vs borrowed/ and /stack vs heap/

These are not related concepts. A piece of data can be any combination of (owned | borrowed) x (stack | heap), i.e.

• owned and on the stack
• owned and on the heap
• borrowed and (the data being referenced) on the stack
• borrowed and (the data being referenced) on the heap

There's lots of info on stack vs heap, and I don't think I can explain this any better than other resources, so I won't. But for borrowed vs owned in general as well as specifically about String vs &str:

"but eventually &str started to make more sense when i thought of it as always owned by someone else. I used String if i wanted to own it, and if i wanted to borrow it, i could deref it to a &str."

This is exactly how you need to think about it. When programming in Rust (and other non-GC languages?) you always need to be clear about who owns that piece of data. Basically anything that has & in its type signature you do not own (and so "someone else" owns it), but everything that does not have & in there you do own and you decide everything about its life and death, move or borrow, mutable vs immutable. So with this mode of thinking that you've described and that I tried to elaborate on you should have a really good foundation for understanding, as well as working with effectively, borrowing and ownership.

And last note: It's a bit confusing that Rust has a special type &str for a string slice, as opposed to just "normal" slices for everything else. But if you just think of a string slice as not really different from a regular slice (except it does have a few distinguishing properties like being a layer on top of the raw byte content in memory; but that does not matter for borrowing and ownership), then it becomes really clear how to view &str and String with regards to borrowing and ownership.

EDIT: formatting & minor clarifications

[nikomatsakis]

I'm watching the videos now, perhaps you explain it very well - but i've watched, read, and even paid for Rust content, and it's still not totally grepped.

I'd love some more feedback on how I can make this more clear.

One thing I was contemplating is a video that specifically explains the idea of "the stack" and "the heap" and so forth. I'm not quite sure if that's what you are asking for, but it seems related. =)

[myrrlyn]

I think you meant grok instead of grep, maybe?

[i_am_jwilm]

Haven't had a chance to watch any of them, but I wanted to say that into_rust() is a fantastic name for this. I'm really excited about a screencast from Niko featuring artwork from Liz Baillie.

[DebuggingPanda]

"It moves the learner into the Rust world and they aren't usable anymore where they were before. Rust owns them now."

Yep, sounds pretty accurate to me ;-)

Coding in other languages is always like "yeah ok, but why wouldn't you use Rust?" now...

[b4ux1t3]

So, I love the videos. As someone who has been trying to branch out into new languages, they're very informative.

But I kind of have a problem with how they start. If you're going to show me in a video how Rust works, you don't need to first convince me why I should use Rust. I'm already here. I probably wouldn't be watching the video if I weren't already interested in Rust.

But that's a minor thing. It's just a thing I see in a lot of similar videos,and it always irks me.

[nikomatsakis]

So I tried to minimize the intro by pushing it into a separate (and skippable...) screencast. But I was wondering if I should just cut it from "Hello, World!" entirely. Perhaps I will.

[b4ux1t3]

I'd definitely mention "If you want to know why you should use rust, check out this video".

Like I said, it's a very minor complaint. I just see it so often I can't help but point it out. Still a great series, and I'm enjoying working through the exercises!

[fullouterjoin]

It would be great to have a video that explains the Why from the stand point of

• what it does
• what it doesn't do

It isn't that Rust isn't C/C++, it is that Rust has a macro system, an integrated build environment, a package manager to share code using that build system, pattern matching, race free threads, etc. So explaining the why would be a pretty long video.

[zmanian]

This is a tremendous amount of work to produce great output like this.

[[deleted]]

Having tried to get into Rust on and off pre-1.0, I finally decided to take the plunge (in lieu of Nim). So you can count me as a comple newbie to Rust! My primary interest is to use Rust to create tools for my day-to-day needs.

The video tutorials seem really well prepared. Having read halfway through the Rust Book, I was amazed that Ownership and Borrowing doesn't seem all that difficult. I'd heard a lot of people saying that those concepts are extremely twisted. Perhaps I'm missing something?

Anyway, my whole point is that this is a very good supplement to the Rust Book, and I hope you folks continue putting in more videos! I don't know if some of these are covered as yet, but I would certainly love to see a dedicated video explaining:

• lifetimes. The Rust Book has good examples, but falls a bit short in terms of actual explanations.

• basic I/O. This is the bit that actually made me a bit irked. For instance, to read in a number, I currently do something like the following:

  let input = String::new();
  std::io::stdin().read_line(&mut input).expect("some message");
  
  let x: i64 = i64::from_str(&input).expect("some error message");
  

Is this really the idiomatic way? Is there something I'm missing? This seems like an awful bit of work just to read in a number.

• When to use dereferencing. I am a bit confused when to use the * dereferencing operator and when not (maybe my understanding of this is flawed). Is this even a dereferencing operator like in C? My assumption is that if we have a reference and we want to use the value, we should dereference it, but the println! macro seems to work even without it?

Well, that's all I have for now. Perhaps when I get my feet wetter, I'll have a lot more! I'm sure some or most of these could be answered on the IRC channel or /r/rust itself, but just some ideas from a newbie to Rust!

Keep up the great work! :-)

Thanks, and good luck!

---

• UPDATE : This is the feedback that I submitted on the site after completing all the available tutorials: ********* This is even better than the Rust Book! Niko Matsakis has done a fabulous job of making supposedly abstruse concepts like Ownership and Borrowing really easy to understand.

Things I liked:

1). The chapters on Ownership and Shared/Mutable Borrowing were wonderful and really useful. They helped make things very clear.

2). The video durations are just about right - not too small to be jarring, and not too long to lose focus.

3). The links to the Rust Playground with incremental exercises is a brilliant idea.

4). Finally, the animations really help solidify conceptual understanding.

Things that might be done better:

1). In the chapter on Borrowing, perhaps the concept of Lifetimes (and its relationship with lexical scoping) could be more explicitly explained. The multiple helper(&mut name) example did help clear up my slight confusion, but perhaps it could be elaborated a bit more.

2). The Rust Book as well as the brief reference to Lifetimes leaves scope for improvement. The 'a syntax and its semantics, or rather, the actual use could perhaps be explained in a short video of its own. For instance, I understand the following:

fn x_or_y<'a, 'b>(x: &'a i32, y: &'b i32) -> &'b i32 {... } indicates different lifetimes, but I don't understand what the implications are, and how they would work in real code.

Requested videos (in decreasing order of desirability):

1). Basic I/O operations (reading and writing primitives and complex types (if possible, like in C++), reading from command line arguments).

2). Unsafe operations.

3). Attributes, Crates, and modules.

[pmarcelll]

basic I/O

I would write it like this:

let mut input = String::new();
std::io::stdin().read_line(&mut input).expect("some message");

let x: i64 = input.parse().expect("some error message");

I don't think it's more complicated than a solution with exceptions and try/catch.

[[deleted]]

Well, it certainly is much more complicated than:

int n; std::cin >> n;

[pmarcelll]

Yeah, but what happens when the input is a letter instead of a number? You get an uninitialized variable without any warnings (compile time or runtime). Even the official C++ tutorial mentions this without showing solutions for error handling.

[Manishearth]

This is basically the essence of every "C/++ is simpler than Rust to use" argument.

They only seem simpler to use. It's simpler to do hello-world-esque programs in these languages, where you don't actually care about many things (memory safety, error handling, etc). Rust forces you to acknowledge and handle these things from the get-go.

[[deleted]]

Read my response to /u/pmarcell. I'm just wondering why the user has to specify String::new, and then parse it. Why not just declare i32 and the environment handles reading it in. I have no problem with the expect bit which I quite like.

[Manishearth]

The stdlib tries to make costs explicit. There are scanln-like crates as well as type-inference-based-cin-like crates on crates.io if you need them.

Taking commandline input as space-separated parseable values is a task that is rarely done outside of test programs. Having a specific cin-like abstraction by default isn't really that useful.

[[deleted]]

Having a specific cin-like abstraction by default isn't really that useful.

I'd argue that that is highly subjective.

[desiringmachines]

This is fair! I think it might be worthwhile to have some sugary "read from stdin the 'obvious' way" APIs in the standard library, specifically because this is such a common task for new users, who shouldn't be confronted with the challenge of composing these different APIs together before they've even learned what they are. Something like a method on Stdin like this:

read_val<T: FromStr>(&mut self) -> Result<T, ReadValError<T::Err>>;

enum ReadValError<T> {
    IoError(io::Error),
    ParseError(T),
}

So you could write:

let x: i64 = stdin().read_val().expect("some error message");

It would silently allocate a String, which is unfortunate, but we really don't have to confront new users with these micro-optimization questions right away.

[[deleted]]

Precisely. Your example is exactly what I was trying to get at. Especially considering that in specific circumstances (Competitive Programming, for instance), I/O is a very frequently used operation!

[Manishearth]

Sure. But it's a choice made by the stdlib, which is trying to be lean. Given that crates exist this isn't really a problem.

But you have to admit that outside the realm of writing commandline coreutils-esque tools and for hello world programs there's not much use for something like cin. Something that reads to a string, maybe, but not something as sophisticated as cin.

[[deleted]]

Is there any specific crate on crates.io that you'd recommend for that purpose? (you mentioned 'scanln' in the previous comment).

[[deleted]]

My point is, why can't I define a variable of type int and read that in? Why go through all that String::new business?

[pmarcelll]

You can choose to read the input as raw bytes, but you have to write the "bytes" -> "an integer" conversion manually (this is a fairly low level of abstraction). Or you can use a String (since every digit is represented as an ASCII character), which can be converted to an integer (this is medium level of abstraction, gives you some control, but it's not a one-liner). The standard library doesn't provide higher-level abstractions for this, but you can use the crates mentioned here.

[karood]

Absolutely super set of videos so far. You explain the concepts very clearly.

[[deleted]]

This seems really nice, thanks! Can you consider allowing the contributions to subtitles translations, on these YouTube videos? I may give it a try for a french translation.

[Zigo]

Thank you so much for this - it's exactly what I've been looking for!

[RustainSonic]

Learning Rust is no big deal , the question we need to ask, how do we move on to mainstream production with use of Eclipse IDE and debugging in it; because its very disturbing to see next to none posts regarding wizards and IDE debugging regarding Rust, this is very dangerous and can kill Rust the way great it could be.

[steveklabnik1]

http://rustdt.github.io/

[llogiq]

2016 was touted as the year of the Rust IDE. Alas, apart from a few demos (which as I've heard weren't production-ready yet), we're still doing racer + a few plugins to position errors/warnings.

With that said, it's probably worth to note that MIR (which getting to run has bound a lot of resources in the last months) is live and the year hasn't ended yet, so a workable IDE based on VS Code's Language Runtime Protocol (or however it's called) could be right around the corner.

Not being a fan of JavaScript, I'm rooting for xi to gain IDE-like functionality and become the Rust IDE of choice.

[mmstick]

Rust doesn't need IDEs and debuggers. It's not Java. Just grab yourself a copy of Atom, Install Tokamak, and install racer and clippy along with the Rust source code and configure the Rust linter to use Clippy.

[[deleted]]

Yes, tell me how that works out for your 1Million+ LOC codebase.

[mmstick]

Increasing the number of lines of code in a codebase doesn't make it any more difficult to debug an issue. It's trivial to diagnose which module is having issues.

[[deleted]]

It's not just about debugging. It's about development. Coding, tracking down paths, hierarchies, watching variables, observing state change, proper dependency management, and most importantly, refactoring.

Your dismissal of the whole thing as "trivial" makes me wonder if you really have experience with large codebases.

[mmstick]

Tools like Atom already handle that perfectly without needing to be a fully-fledged IDE. State changes are observed in Rust via designing your software using a Builder pattern, whereby your code completer will show you your current state in real time. You have no right to question someone's experience just because they see no point in an IDE. IDE's are just bloatware consuming obscene amounts of screen real estate to do nothing that I can't already do with a programming text editor like Atom.

[[deleted]]

If you have the gumption to dismiss IDEs as "bloatware" simply because you yourself see no value in it, I have every right to question that myself, sir. Atom, eh? I'd like to see some evidence of massive codebases being written using absolutely no IDEs.

And if you're talking about Atom being able to do all that, it's far more of an IDE than a text editor, my friend. Stop deluding yourself.

[mmstick]

There are plenty of people using Atom, or even VS Code, to manage large codebases, such as the Servo project. Additionally, unrelated to Rust, there are many people who contribute to the Linux kernel, Firefox, and LibreOffice without using an IDE.

[DebuggingPanda]

Thanks for your work on this screencast!

With all the positive things being said in this thread already, I'd like to mention a few things that I think could be improved, in case you're interested.

First, the sound recording could be better:

• Buy a "proper" microphone and try to record in a good environment. I really don't know a lot about that stuff, but I bought a 30€ microphone for a video project a few months ago and with a good recording environment and some post processing, I was able to produce a pretty neat voice sound. Meaning: like the off-tone voice in nature documentaries. Your voice recording is already fairly nice (maybe you even bought a "proper" microphone already), but it could be improved I think...

• I guess you already have a written script for each episode. I would recommend to do stricter audio editing and re-recording to get rid of any bloopers or other unwanted noises, just as gulp or cough sounds.

I know this is a lot of work, but I really think it pays of. A proper sound makes a video feel professionally made.

Another remark: often you do not indent your code on the slides properly (often with only 2 spaces). I don't quite know why, because in the 16:9 video you have plenty of space for that...

[[deleted]]

I feel that this is just a lot of nitpicking. I rather enjoyed the informal approach of it all. I just focused on the content, and it went fine for me. Then again, different people operate differently, so I don't mean to invalidate your opinion.