Rust Tutorial #5 - Console Input

[@raulwolters2380]

4:19 Ok I know this might be confusing, but when you transfer ownership of a variable it is usually NOT copied! Only a select few types that implement the Copy trait are allowed to be implicitly copied like that. Ownership of a variable really only has to do with who is responsible for managing the memory. Giving ownership of a piece of data to someone else is essentially equivalent to telling the compiler you will never access that data again within the same scope. In your example, you supposed transferring ownership of a heap-allocated String to a function. Heap-allocated objects are never directly accessible to a function, since they don't live on the stack (they live on the heap), so ownership of a heap-allocated variable is really just ownership of a pointer to a place in memory. Internally, passing a "String" or a "&String" is the exact same thing: you're just passing a pointer to a place on the heap. I hope that it is now clear that passing a String vs a &String is _not the same thing_ as pass-by-reference vs pass-by-value. So what does it actually do? I already quickly mentioned that ownership has to do with a sort of contract with the compiler as to who is responsible for the piece of memory. With this contract the compiler can decide when to delete your stuff. *Transferring* ownership of a piece of data (so passing a String as "String" or "mut String") to a function tells the compiler that you do not want to access the data anymore outside of the function, so the compiler will destroy the object after the function has been run. *Borrowing* ownership of a piece of data (passing it as "&String" or "&mut String") in a function signature tells the compiler that you DO need the data after the function completed, so it can't go ahead and delete it for you yet. So why does read_line() take a borrowed String rather than an owned one? Well, if you want user input, you usually want to be able to look at it afterwards. Passing the owned String would've told the compiler it is ok to delete the string after it had been filled with user input. We don't want that, that's why you pass in a borrowed String.

[@perc-ai]

How do u know so much

[@AndrewDeVriesturtle17]

Well said!

[@remi.scarlet.]

Does that mean that after he passed "input" to the println! macro (and the console printed it out) input gets deleted? Since it wasn't passed by ref (&)?

[@IanRiley915]

@@remi.scarlet. println! is a macro and not a function so it can work differently. Macros are pre-processed before compilation so they can do essentially anything with their inputs. In this case, println actually rewrites its inputs to use borrowing.

[@vs_gaming3013]

This was just a brilliant explanation! Thanks a lot, Raul! After Python Rust seems like a whole new world.

[@NorteXGame]

For anyone interested, the Result() in Rust can be somewhat compared to a Promise inside JS, just not asynchronous. But essentially it means it can be successful (and return Ok, or in JS .then) or unsuccessful (and return an Err, or in JS .catch).

[@perc-ai]

Ty so much bro

[@ojochegbe_]

Ty bro

[@AbhinavKulshreshtha]

4:20 Sentence you were looking for is "pass by reference" instead of "pass by value". Compared to C/C++, this feels more secure because we are explicitly marking the variable as mutable while on C there is no need for check regarding this as all variables are mutable by default, also error handling was not mandatorily required as it is here, but it was always a standard practice to implement error handling for inputs. Once again, Rust Tooling is awesome. If I compare traditional languages like C/Java/C#, to modern languages like elm/kotlin/swift and now rust, I feel that 1st party tooling ecosystem plays a great role in the language's claim for security. Not to mention the lessons learned by analysing the history of traditional languages.

[@nicholasbicholas]

I'm no expert but just since I didn't see anybody else talk about this in the comments. stdin != Standard Output In, but rather just Standard Input. Standard output, input, and error (stdout, stdin, stderr) are three devices that often but don't necessarily send and receive data to/from a terminal. It's very common to redirect them to and from other files or devices. For a terminal-bound user, beyond simply using programs that interactively request user input over stdin, it's also very common (and unixy) to form pipelines of commands where each command in the chain 'pipes' or connects its standard output to the next command's standard input, for example something like 'ps -a | grep process_name'.

[@frozenn00b]

Came here to say the same thing... stdin = standard in/standard input... standard output in makes zero sense. Data goes in, or out.. not out then back in.

[@dyspatch8574]

Great! Thanks for teaching Rust to beginners and making it more popular. 👌

[@TravisGarnett]

Thank-you, Tim: I like the use of the expect(), for error handling! 😎👍

[@kamogelooliphant1730]

❤ I went through 5 videos enjoying the tutorials of rust

[@CornishMiner]

Useful detail Tim, it's one of the things I like about your videos.

[@KamyanYT]

Great video! I always love your content. Thanks for the upload, such an inspiration!

[@fireplank7520]

Thanks! Awesome series so far. Looking forward to the rest when you upload more.

[@voidemon490]

4:22 I'm very new to rust so please correct me if I'm wrong. In rust like any other high level languages such as c and c++, you don't actually copy value of an object in heap by default, rather it copies the address that points to that object. Also it's worth mentioning that in rust each variable is responsible for managing their space in heap, meaning compiler will add the "drop(address)" invocation as soon as the variable becomes out of scope. However by passing the variable "input" to "read_line" function you also pass the responsibility (a.k.a Ownership) of it. As a result the call to "drop" function occurs at the end of the lifetime of the parameter in "read_line" function, that is at the end of the function. Which means the value of input becomes unavailable after the call to read_line function. Sorry for the lengthy explanation, just trying to share my understanding of rust with other learners. Keep learning 💪

[@voidemon490]

You might also be curious how "&input" and "input" is different in this case. Simply by passing the reference instead of the variable itself you are only borrowing the value of the variable, so rust compiler will know that "read_line" function is only interested in the value and not the ownership of the value.

[@Hellbending]

Did you just call c and c++ high level languages? High level from what, assembly? 🤣🤣 Bro the only thing high level here is you 🌿💨

[@mani_mincraft]

Wow great video and explantion!

[@curtisblake261]

Procedural versus declarative programming comes to mind. I knew someone who couldn't grasp "x=x+1" because it seemed like an impossibility to them. I'd call theirs a declarative mindset.

[@mykolamorozov2099]

From performance consideration, does it make sense to use input as a ref in print macro to avoid value copy? For instance: println!(&input)

[@subee128]

Thanks

[@hazmat86]

Love this series! Think I have learned more with Tim than with all other instructors combined!!!

[@ankitchetri2968]

Hmm thankyou

[@Dr.Cosmar]

saying @mut ~3:49 threw me off. Meant to say &("and")mut I can't wait until my brain is mush like this lolol I can feel it slowly happening already with that method for getting input. Python... "u_in = input()|" Me: "I need to graduate to a better language, I said, it will be worth it, I said."

[@m_t_t_]

you have 3 file descriptors - stdin, stdout, stderr. not std out in

[@zenglingyu]

please make this tut complete..

[@guitaek4100]

4:32 this is actually wrong. But I don't know either how to explain that without explaining ownership. Maybe "moving" is a better word here

[@curtisblake261]

_bstr_t used to do the heavy lifting in C++.

[@pravachanpatra4012]

Can you collab with Tiff in Tech

[@cl.5974]

What do you use for IDE?

[@funworld8379]

sublime text editor

[@longlong10203]

Rust sucks at getting input other than strings like int or array/vector

[@jumpingjoy7689]

quick poll: how do you pronounce std? A: s t d, individually. or? B: stid I personally use B

[@frozenn00b]

s-t-d or standard... stdin = standard in, stdout = standard out, stderr = standard error, etc. So either s-t-d or standard.

[@diegomartin6332]

Can you teach Ruby?

[@md.shazidalhasan6726]

Unlike python, Rust seems very restricted language

[@AlexanderHyll]

You are right, it is more restrictive. The other side of the coin is that these restrictions also, compared to python, give you super powers. It is hundreds of times faster than python, it is safer (much lower risk of undefined behavior), no garbage collection and many times more memory efficient. You use python when being unrestricted is more important. You use rust when you need performance, safety, or have resource constraints. Rust is not as difficult or restrictive as it looks at first glance either. Thats why we use both at my firm. P.S. note that restrictive here means forcing (mostly) good habits, there’s no limitations to what you can make in rust.

[@md.shazidalhasan6726]

@@AlexanderHyll I got you

[@ohwow2074]

I like how it is a strongly typed language. Just like Ada.

[@jma42]

this is why it is so hard, you have to do mind-bending logic on lifecycles to work around on its restrictiveness

[@AlexanderHyll]

@@jma42 It's much more daunting when you start out, before realizing how basic the concept really is. Your data can be written once or read by many. And that's it (kinda sorta). All you need to do is spend a little more time when you set out to write your program so that your data structure design works in this way. The first couple times it feels like the compiler is your worst enemy when you get the bat to fight it after having written some code. After a few times though, when you get the bat it's more like a dear old sparring partner helping you get better. So essentially yes I do agree it is a barrier to entry, but it's not really that mind boggling after you grasp the core concept (a concept which in essence is fairly simple).

[@rami_atallah]

Rust is a harder version of c++ 😂

[@ohwow2074]

Nothing is harder than C++. As someone with an intermediate knowledge of C++, Rust code makes a lot of sense to me. This is the beginning though. Let's wait and see what other concepts Tim will teach us.

[@jma42]

they should be somewhat similar in difficulty but damn its sure hard to program in a rust way, so many stuffs on it are outlier to most languages.

[@paraxicgaming5743]

@@ohwow2074 ANSI/ISO enforced C code begs to differ, also assembly language