One of the best Rust talks out there, as a js fanatic myself, i finally found a systems programming language i can understand and use without fear of fucking things up lol
Excellent talk. The speaker was clear and concise. I've dabbled a bit in rust but never really looked much into parallelism features. The qsort example is really neat. The || syntax threw me off for a minute before realizing that it is just a closure!
Great talk, I've been wanting to learn about rust for a while. I feel weird about these talks about language B at a language A conference, though. At the Scipy conference there is always a small crowd talking about Julia. Kind of weird I think.
vcpkg is one really good cross platform package manager. I'm using it on win10 and it works great. In two commands you can download c++ package and install it, and then just #include it inside visual studio. This is great for just checking out if some library is ok. Try it out. :)
Brilliant question made by 2nd guy. "Everything was a good idea back in the day". Now C++ syntax is garbage mostly due to retro compatibility and bad ideas.
Interesting but wouldn't the C++ publish function pass the vector by reference? Not sure what publish does but surely you don't want to copy the vector.
That wasn't the point of the example. The point was to demonstrate ownership. Publish wants to own the book. In C++ the book is copied and _that copy_ is owned. You could move the book into the function but that leaves the book variable you moved out of in a invalid state, yet nothing stops you from messing with it. In Rust using the original book variable after you moved it (transferred ownership in Rust terms) *is a compile error*. If publish should only read from the book both languages have similar behavior there, a reference to const in C++ or a borrow in Rust.
Yeah catering to decades of old code can be quite an anchor. I like the epoch system described. Python should have pushed for the explicit use of #!/bin/python2 or ...python3 as a preferred style so the two interpreters can live on the same machine without the need for the user to call either of them to run a particular script. ( most 'nix machines already install the interpreters like this "/bin/python" just sim-links to one of them and the other must be used explicitly)
IntoIter is not the same thing as Iterator. You need to call .into_iter(), .iter(), or .iter_mut() to actually create the iterator. How does the Vec, or &Vec keep track of where it is in the iteration? It doesn't, the iterator that .iter() creates does, however, so you can actually iterate.
Yes, I agree with you here, but the way a `for in` loop works is by calling IntoIter::into_iter then iterating the result. this is a no-op for things already iterators, and then makes it also work with &Vec, etc.
David Ross yea I must agree actually, I was wrong here. I've always called the iter methods manually, so I guess I just assumed that for only worked on actual iterators.
Sounds snazzy. Uphill battle though, there is a good chance it will be overtaken by C++17 or 20 though as the C++ team has been adding many modern features that compete in the same realm, and Rust is not that different. (ie HDVD vs Blueray) Also Rust must become established which means splitting the existing pie into yet smaller pieces, getting into education, proven compiler reliability and efficiency etc.. Meanwhile C++ has the established bit in the bag, with well-refined compilers and all the works, ++ only needs to add a few features to match a most of what Rust can do. (as long as the needed features get in to one of them its a win, I don't really care which name is on the language)
actually C++ will even have better compiler enforced safety: while rust only has unsafe, C++ will gain more granular tags, which allow more specific control
Yes, it's great to see C++ adding modern features. Type deduction, lambdas etc. But good grief, C++ has become massively complex. With a syntax and semantics so huge contorted that I don't believe there is a single person in the world that knows and understands it all let alone how all all the parts work together. That's before we start talking about the standard library. Certainly the compiler writers don't, if they did their error messages would actually be useful. But anyway, I think you are wrong. Certainly you can add some more features to C++ to match a lot of what is in Rust, BUT I suspect it's impossible to add the most important feature of Rust to C++, the assurance of correctness and safety. The prevention of all those buffer overflows, use after frees, null pointer errors, use of uninitialized variables, memory leaks, data races, switch fall thoughs, undefined cases, etc, etc, etc. Sure you can achieve such safety in C++ if you try hard enough. Why not let the compiler do all that checking work for you? I'm not totally sure but I think it's impossible with the C++ syntax and would require changing the semantics so much it would fail to compile most existing C++ programs. Ain't going to happen.
@@climatechangedoesntbargain9140 Yeah, great. And I will be a much better programmer in the future, so hire me, Google. I am tired of that never ending talk about what C++ will have in the future. It is complicated enough already, and it lacks basic safety features that Rust has _right now_, not tomorrow. I was shocked when I checked the C++ vector example and it compiled without even a warning, and then of course crashed when run. Come on man, stop living in a dream. How much time is needed to not only implement all the safe features for C++ but also to standardize them? Waiting another 10 years does not look like a viable option to me. And even if it all comes out tomorrow, what's the point? C++ will still have an enormous historical baggage that you cannot easily throw away, so it will never be as good as a language that was developed from scratch with C++ problems in mind.
@@TheamxxLThis is just as problematic as the original comment. Everyone is a noob when they touch programming for the first time, no matter the language. So, you're saying C++ should "not be for noobs"?
You don't need to know or care if a type is copy. Since copy acts as a move just cheaper. I maybe wrong but it seems a lot more straight forward than having to worry about std::move.
The best video that explains the features of Rust. Everything is clear even without clear knowledge of the English language. Thank you very much!
An excellent video to learn Rust for C++ programmers.
What is I don't know C++
One of the best Rust talks out there, as a js fanatic myself, i finally found a systems programming language i can understand and use without fear of fucking things up lol
Suddenly lifetimes do not look so scarry.
This was a great talk for c++ programmers(intermediate) to learn about rust basics. It made me understand how I can start using rust
Excellent talk. The speaker was clear and concise. I've dabbled a bit in rust but never really looked much into parallelism features. The qsort example is really neat. The || syntax threw me off for a minute before realizing that it is just a closure!
First time I read |_, _| I was like "what the fuck is that??". Than it becomes clear.
Listening to "Niko Matsakis" is just a joy.
This helps me to write better C++ code, well prepared presentation!
Great talk, I've been wanting to learn about rust for a while. I feel weird about these talks about language B at a language A conference, though. At the Scipy conference there is always a small crowd talking about Julia. Kind of weird I think.
i love the early description of editions
This is honestly, truly, mind blowing and amazing. Everything boiled down to what "you learned in Kindergarten". Just about.
Fantastic talk!
Wow, c++ needs the package manager library thing.
Conan.io is trying to fill this gap
You won't see adherence from embedded system developers.
vcpkg
I think the cargo system, combined with its build system and single compiler, is one of rusts biggest weaknesses.
vcpkg is one really good cross platform package manager. I'm using it on win10 and it works great. In two commands you can download c++ package and install it, and then just #include it inside visual studio. This is great for just checking out if some library is ok. Try it out. :)
I really like this guys talks!
Really, really good talk !!
I watched this talk whwn it first came out. it was good to watch again now I'| more familiar with the language. and see it still taught me some stuff
Nice talk! Liked it a lot. I thought at one moment Niko will have heart-attack! Niko was so thrilled about Rust.
xD
true
Excellent talk! :)
You know it is a good talk when people interrupt you because they want to know more
Brilliant question made by 2nd guy. "Everything was a good idea back in the day". Now C++ syntax is garbage mostly due to retro compatibility and bad ideas.
Excellent Talk!
Interesting but wouldn't the C++ publish function pass the vector by reference? Not sure what publish does but surely you don't want to copy the vector.
That wasn't the point of the example. The point was to demonstrate ownership. Publish wants to own the book. In C++ the book is copied and _that copy_ is owned. You could move the book into the function but that leaves the book variable you moved out of in a invalid state, yet nothing stops you from messing with it. In Rust using the original book variable after you moved it (transferred ownership in Rust terms) *is a compile error*.
If publish should only read from the book both languages have similar behavior there, a reference to const in C++ or a borrow in Rust.
Who here just started coding and doesn't get any of this stuff but is still super fascinated too?
damn, i love it, i finished the book
Yeah catering to decades of old code can be quite an anchor. I like the epoch system described.
Python should have pushed for the explicit use of #!/bin/python2 or ...python3 as a preferred style so the two interpreters can live on the same machine without the need for the user to call either of them to run a particular script. ( most 'nix machines already install the interpreters like this "/bin/python" just sim-links to one of them and the other must be used explicitly)
at 34:50, the for loop should be 'for elem in self.iter()', not just 'for elem in self'.
I believe this actually will work as it is, because IntoIter is implemented on `&Vec` such that it iterates over `&T`
IntoIter is not the same thing as Iterator. You need to call .into_iter(), .iter(), or .iter_mut() to actually create the iterator. How does the Vec, or &Vec keep track of where it is in the iteration? It doesn't, the iterator that .iter() creates does, however, so you can actually iterate.
Yes, I agree with you here, but the way a `for in` loop works is by calling IntoIter::into_iter then iterating the result. this is a no-op for things already iterators, and then makes it also work with &Vec, etc.
See play.integer32.com/?gist=d08c439348a3101ddfda76b1b0f9de2e&version=stable
David Ross yea I must agree actually, I was wrong here. I've always called the iter methods manually, so I guess I just assumed that for only worked on actual iterators.
Ok but is the rust compiler turing complete?
Rust has proc macros which allow you to modify subgraphs of the AST at compile time. A bit better than just "turing complete"
Talk start at 0:55. Thank me later
Sounds snazzy. Uphill battle though, there is a good chance it will be overtaken by C++17 or 20 though as the C++ team has been adding many modern features that compete in the same realm, and Rust is not that different. (ie HDVD vs Blueray)
Also Rust must become established which means splitting the existing pie into yet smaller pieces, getting into education, proven compiler reliability and efficiency etc.. Meanwhile C++ has the established bit in the bag, with well-refined compilers and all the works, ++ only needs to add a few features to match a most of what Rust can do.
(as long as the needed features get in to one of them its a win, I don't really care which name is on the language)
Rust is 2 years old...pretty sure people said the same thing about C++ at such early life .
The rust compiler uses LLVM as the back end so it's at least as reliable and efficient as Clang
actually C++ will even have better compiler enforced safety: while rust only has unsafe, C++ will gain more granular tags, which allow more specific control
Yes, it's great to see C++ adding modern features. Type deduction, lambdas etc.
But good grief, C++ has become massively complex. With a syntax and semantics so huge contorted that I don't believe there is a single person in the world that knows and understands it all let alone how all all the parts work together. That's before we start talking about the standard library. Certainly the compiler writers don't, if they did their error messages would actually be useful.
But anyway, I think you are wrong. Certainly you can add some more features to C++ to match a lot of what is in Rust, BUT I suspect it's impossible to add the most important feature of Rust to C++, the assurance of correctness and safety. The prevention of all those buffer overflows, use after frees, null pointer errors, use of uninitialized variables, memory leaks, data races, switch fall thoughs, undefined cases, etc, etc, etc.
Sure you can achieve such safety in C++ if you try hard enough. Why not let the compiler do all that checking work for you? I'm not totally sure but I think it's impossible with the C++ syntax and would require changing the semantics so much it would fail to compile most existing C++ programs. Ain't going to happen.
@@climatechangedoesntbargain9140 Yeah, great. And I will be a much better programmer in the future, so hire me, Google. I am tired of that never ending talk about what C++ will have in the future. It is complicated enough already, and it lacks basic safety features that Rust has _right now_, not tomorrow. I was shocked when I checked the C++ vector example and it compiled without even a warning, and then of course crashed when run. Come on man, stop living in a dream. How much time is needed to not only implement all the safe features for C++ but also to standardize them? Waiting another 10 years does not look like a viable option to me. And even if it all comes out tomorrow, what's the point? C++ will still have an enormous historical baggage that you cannot easily throw away, so it will never be as good as a language that was developed from scratch with C++ problems in mind.
C++ suuuucks
A C++ is not guilty for being used by noobs.
@@TheamxxLThis is just as problematic as the original comment. Everyone is a noob when they touch programming for the first time, no matter the language. So, you're saying C++ should "not be for noobs"?
19:49 - Clone and copy semantics in RUST is horrible idea. Especially when primitives are not moved... I've found std::move more viable.
You don't need to know or care if a type is copy. Since copy acts as a move just cheaper. I maybe wrong but it seems a lot more straight forward than having to worry about std::move.