👉 To try everything Brilliant has to offer for free for a full 30 days, visit brilliant.org/CodetotheMoon/ You’ll also get 20% off an annual premium subscription. They have courses on LLMs and Quantum Computing!
Other things I think will really translate for a TS dev to Rust: 1. build express server & compare to rust tokio 2. read csv, parse, run aggregations, write file (compare) 3. small cli tic-tac-toe game showing limitations of TS types & strength of Rust Traits 4. Server in-memory operations showing how GC overhead for TS can be problematic at scale, and how Rust automagically removes variables when out of scope. Example usage, aggregator API. Input request is some collection, server queries 4 other APIs, aggregates data and returns collection
I strongly disagree socks and coal are "junk". These items keep you warm in winter. Can't do that with diamonds and emeralds (unless you buy socks and coal with them).
Just as a tip, it might be a good idea to disable code ligatures for the code snippets, at least for videos covering fairly fundamental parts of a language. It might not be hard for people who aren't used to it to figure them out, but it is a small barrier to reading them
The quality of this video is awesome! Please please make more videos like this, the length and content covered is just right. While there are quality videos out there, they end up being very long and unfocused leading to videos closer to an hour long....
Thanks, really happy you liked it! I love making this type of content, but I'm not sure how much of it I'll be able to make. People are much less likely to click on things like this, which means the algorithm relegates the video to a state where it isn't really recommending it to many people. And the effect is not linear - it is exponential. To paint a picture of the magnitude of this phenomenon - consider two videos. Video A gets clicked on by 8% of the people to whom it is recommended. Video B gets clicked on by 4% of the people to whom it is recommended. Common wisdom says that Video B would be viewed about half as many times as video A, *but that's not what happens*. The TH-cam algorithm picks up on this and will recommend video B to viewers far less frequently than video A, due to its much lower "clickthrough rate". In my experience, with the above numbers (Disregarding average view duration, likes, comments etc, which matter but not as much as clickthrough rate), *video B will get recommended about 1/10th as much as video A*. Which means video B will get roughly 5% as many views as video A. Yeah, wow. This seems to be true even if other metrics of video B like average view duration, likes, etc, are superior to those of video A. Many consider view count to be a superficial metric, but for those of us making a living from TH-cam, the situation with video B can be a devastating show stopper. So tl,dr - it is really hard to make content that will get clicked on less frequently than "normal", even if it is only slightly less. Even if you know it will be very helpful and appreciated by a specific group of folks. To be fair, if I were TH-cam I would still design the algorithm exactly how it is - placing a high value on clickthrough rate. If there is a video that viewers are not clicking on, why would we waste valuable screen space in viewer recommendations for that video? TH-cam is funded by advertisers. The longer viewers spend on the platform, the more sustainable the business is. Recommending videos that viewers are less likely to click on will invariably lead to viewers spending less time on the platform, leading to lost revenue. I highlight this phenomenon because I think it is something the average viewer is probably not aware of. I do it to provide context, not because I am complaining or because I want to lobby for some change to the algorithm. I actually think the algorithm is fantastic. It's just a harsh reality that makes certain types of content less feasible to create. Sorry for the long winded response 😎 I'm probably going to post this on Twitter as well.
@@codetothemoon I see this as very strong arguments of how the business model of TH-cam opposes the interests of many people. Admittedly not the majority of people, otherwise these worse rated videos would not have a lower rating than better performing videos. But still people like all of the commenters of this video, who enjoyed it and would like to see more of its kind. Therefore I do complain that the algorithm stands in the way of success for niche videos. I understand your reasoning why the algorithm makes sense for a business, but that does not make it good for the individual viewer.
Super informative video, the only bit that I wasn't clear on was why the Result would stop iterating on the first error it encountered? It sort of makes sense from context but I don't know where that leaves things like the resulting vec or if you can no longer use the collection (as it's been consumed) and you can't access the elements as you only have the Err variant back? (I've been much more likely to use the Vec type so understanding the "rusty" way to do the same thing properly would be awesome!
Thanks for the feedback! You're right - In this situation there wouldn't be a resulting vec - the receiver would be assigned a Result that is of the Err variant. As you point out, the original collection would be consumed and no longer usable.
Great video! One thing is magical but quite confusing though: you have a Result but in map() you only return an Ok(String) not an Ok(Vec). I tried it and was actually surprised that it works. How does Result FromIterator "merge" these into the resulting vector?
i watched this video while on my coffee rush. I am intimately familiar with the topics you covered in this video. Thank you so much for connecting to me on a deep level!
at about 8:51 the the entry(...).or_insert_with(Vec::new) can be rewritten as entry(...).or_default() which clippy will helpfully tell you to do too :) This works because the Default impl of Vec gives you an empty vector.
Good catch :) I had all the examples in one program when I was writing them, so I was using clone everywhere. Intended to remove them all for the video but this one slipped through the cracks
More of these please B0ss 🤣🤣 I’d love to see a sectioned series covering all the traits in the std lib (and maybe some of the extension crates traits that are super popular like itertools)
@@codetothemoon some positive feedback to understand the viewer base side of things- I enjoy seeing your videos pop up and love watching them. A lot of the time I tend to be unsure of what exactly you’ll be covering though (‘direction’ if you will?) I think something like this may help give that solidified feeling that there’s a common audience goal, just some ‘food for thought’ type stuff ig Keep on keepin’ on brother 🤙❤️❤️
I looked into this and you're right! it seems like reduce can mean something a bit different in each ecosystem - for example in Rust it does not allow you to specify an initial accumulator value, and the type of the accumulator must be the same as that of the input elements. But the javascript implementation is more like Rust's fold...
In rust functional operations on collections are not as user friendly as they could be. From a user point of view the .iter() and .collect() add unnecessary fluff. If you're operating on a vector, exposing map directly on vector is useful, and its not that far from how its already used by the for loop.
Going into details: ".into()" is from a Trait Implementation, and used to explicitly convert a data type into another if it supports the conversion. Like for example, converting an i8 (Might commonly be refered as Short type in other languages) '.into()' i32 (Might be commonly be refered as int in other languages). Here in the video, `"Socks"` are actually a `&str`, which could be considered as a Wide-pointer that holds the memory address to some data plus the length of the data (i. E. How many chars can you safely read. It's kind of like Java' s Arrays, which you can find the array's length by reading the 'length' attribute) "&str" are different from "String" because the first is a "wide-pointer" that holds some memory addres + the length, whereas the second is dynamic sized array (Vectors). The String (which is a vector under the hood) would additionally hold the capacity, so you can know how many more chars/bytes can you push into the allocation, before you need to re-allocate the string in the heap to get more writing space. Short form: `String` can be gotten from a "&str", which is where CodeToTheMoon used it the most, and because he was storing Strings, and not & str's, he needed to call ".into()" because Rust doesn't do implicit conversions
This is because Rust is a low-level language so it doesn't have any garbage collector, so you shouldn't compare Rust to high-level languages such as C#, Java, JavaScript or Python, you should compare it to other low-level languages such as C, C++, D and Zig. When you compare Rust to other low-level languages you will see why the borrowing and ownership stuff is amazing.
👉 To try everything Brilliant has to offer for free for a full 30 days, visit brilliant.org/CodetotheMoon/ You’ll also get 20% off an annual premium subscription. They have courses on LLMs and Quantum Computing!
You little cheater! You implemented not listed a day before uploading and added the trait first comment before we even had a chance
@@CrazyLuke11 haha guilty as charged!
BIG YES to this kind of Rust knowledge. It bridges the gap for JS / Python devs nicely
Nice, glad it resonated with you!
Other things I think will really translate for a TS dev to Rust:
1. build express server & compare to rust tokio
2. read csv, parse, run aggregations, write file (compare)
3. small cli tic-tac-toe game showing limitations of TS types & strength of Rust Traits
4. Server in-memory operations showing how GC overhead for TS can be problematic at scale, and how Rust automagically removes variables when out of scope. Example usage, aggregator API. Input request is some collection, server queries 4 other APIs, aggregates data and returns collection
I strongly disagree socks and coal are "junk". These items keep you warm in winter. Can't do that with diamonds and emeralds (unless you buy socks and coal with them).
Touché, good point. My implicit frame of reference was an rpg-like video game, I should have made this clear 😎
Just as a tip, it might be a good idea to disable code ligatures for the code snippets, at least for videos covering fairly fundamental parts of a language. It might not be hard for people who aren't used to it to figure them out, but it is a small barrier to reading them
Thanks for the feedback, this is something I hadn’t considered!
The quality of this video is awesome! Please please make more videos like this, the length and content covered is just right.
While there are quality videos out there, they end up being very long and unfocused leading to videos closer to an hour long....
Thank you, really happy it resonated with you!
more of this content please, break down of all the most commonly used rust patterns :)
Thanks, really happy you liked it!
I love making this type of content, but I'm not sure how much of it I'll be able to make. People are much less likely to click on things like this, which means the algorithm relegates the video to a state where it isn't really recommending it to many people. And the effect is not linear - it is exponential.
To paint a picture of the magnitude of this phenomenon - consider two videos. Video A gets clicked on by 8% of the people to whom it is recommended. Video B gets clicked on by 4% of the people to whom it is recommended. Common wisdom says that Video B would be viewed about half as many times as video A, *but that's not what happens*.
The TH-cam algorithm picks up on this and will recommend video B to viewers far less frequently than video A, due to its much lower "clickthrough rate". In my experience, with the above numbers (Disregarding average view duration, likes, comments etc, which matter but not as much as clickthrough rate), *video B will get recommended about 1/10th as much as video A*. Which means video B will get roughly 5% as many views as video A. Yeah, wow.
This seems to be true even if other metrics of video B like average view duration, likes, etc, are superior to those of video A.
Many consider view count to be a superficial metric, but for those of us making a living from TH-cam, the situation with video B can be a devastating show stopper.
So tl,dr - it is really hard to make content that will get clicked on less frequently than "normal", even if it is only slightly less. Even if you know it will be very helpful and appreciated by a specific group of folks.
To be fair, if I were TH-cam I would still design the algorithm exactly how it is - placing a high value on clickthrough rate. If there is a video that viewers are not clicking on, why would we waste valuable screen space in viewer recommendations for that video? TH-cam is funded by advertisers. The longer viewers spend on the platform, the more sustainable the business is. Recommending videos that viewers are less likely to click on will invariably lead to viewers spending less time on the platform, leading to lost revenue.
I highlight this phenomenon because I think it is something the average viewer is probably not aware of. I do it to provide context, not because I am complaining or because I want to lobby for some change to the algorithm. I actually think the algorithm is fantastic. It's just a harsh reality that makes certain types of content less feasible to create.
Sorry for the long winded response 😎 I'm probably going to post this on Twitter as well.
@@codetothemoon I see this as very strong arguments of how the business model of TH-cam opposes the interests of many people. Admittedly not the majority of people, otherwise these worse rated videos would not have a lower rating than better performing videos. But still people like all of the commenters of this video, who enjoyed it and would like to see more of its kind. Therefore I do complain that the algorithm stands in the way of success for niche videos. I understand your reasoning why the algorithm makes sense for a business, but that does not make it good for the individual viewer.
Super informative video, the only bit that I wasn't clear on was why the Result would stop iterating on the first error it encountered? It sort of makes sense from context but I don't know where that leaves things like the resulting vec or if you can no longer use the collection (as it's been consumed) and you can't access the elements as you only have the Err variant back?
(I've been much more likely to use the Vec type so understanding the "rusty" way to do the same thing properly would be awesome!
Thanks for the feedback! You're right - In this situation there wouldn't be a resulting vec - the receiver would be assigned a Result that is of the Err variant. As you point out, the original collection would be consumed and no longer usable.
Thanks! Really good explanation of collections and iterators!
Glad you enjoyed it!
Great video!
One thing is magical but quite confusing though: you have a Result but in map() you only return an Ok(String) not an Ok(Vec).
I tried it and was actually surprised that it works.
How does Result FromIterator "merge" these into the resulting vector?
I love this channel
Taught me so much stuff about rust.
I always recommend it to other people who learn rust
Thank you so much
awesome, really happy you got something out of it! and thanks for the kind words!
i watched this video while on my coffee rush. I am intimately familiar with the topics you covered in this video. Thank you so much for connecting to me on a deep level!
nice, really glad you liked it despite already knowing much of the content!
Thank you SO MUCH for this video! It finally cleared up the confusion about all this iterator stuff!
nice! really happy you got someting out of it!
at about 8:51 the the entry(...).or_insert_with(Vec::new) can be rewritten as entry(...).or_default() which clippy will helpfully tell you to do too :) This works because the Default impl of Vec gives you an empty vector.
ahh great point! that would simplify things a bit!
Very nice explanations of some basic concepts that trips people up. More of this type of content please!
thanks for the feedback, will do!
My favourite rust feature is exactly this.
The type system and other features that accomodate it.
Agree, the Rust type system is amazing 🤩
4:01 I don't think you should use clone there 😂
Good catch :) I had all the examples in one program when I was writing them, so I was using clone everywhere. Intended to remove them all for the video but this one slipped through the cracks
Cool, Rust is powerful thanks
Indeed, thx for watching!
More of these please B0ss 🤣🤣
I’d love to see a sectioned series covering all the traits in the std lib (and maybe some of the extension crates traits that are super popular like itertools)
nice, glad it resonated with you! and great idea!
@@codetothemoon some positive feedback to understand the viewer base side of things- I enjoy seeing your videos pop up and love watching them. A lot of the time I tend to be unsure of what exactly you’ll be covering though (‘direction’ if you will?) I think something like this may help give that solidified feeling that there’s a common audience goal, just some ‘food for thought’ type stuff ig
Keep on keepin’ on brother 🤙❤️❤️
What did you use to animate these code snippets?
Animotion, created by the fellow who runs the “Joy of Code” channel! Fantastic tool.
thank you
Glad you liked it!
fold is similar to array.reduce method in javascript.
In C# you have the Aggregate method which I believe is similar.
I looked into this and you're right! it seems like reduce can mean something a bit different in each ecosystem - for example in Rust it does not allow you to specify an initial accumulator value, and the type of the accumulator must be the same as that of the input elements. But the javascript implementation is more like Rust's fold...
Please more videos like this 🙏
Will do!
I did not know about or_insert_with. That's going straight to the pool room.
Nice, glad you got something from the video!!
In rust functional operations on collections are not as user friendly as they could be.
From a user point of view the .iter() and .collect() add unnecessary fluff.
If you're operating on a vector, exposing map directly on vector is useful, and its not that far from how its already used by the for loop.
Liked the video just for the thumbnail
Hah thank you!
thanks a lot for the good work, the beard is awesome 😎 sir
thanks for watching, and thank you!
can~t still understand, into~thing
If you can tell me what part you’re stuck on maybe I can clarify a bit!
Going into details: ".into()" is from a Trait Implementation, and used to explicitly convert a data type into another if it supports the conversion. Like for example, converting an i8 (Might commonly be refered as Short type in other languages) '.into()' i32 (Might be commonly be refered as int in other languages).
Here in the video, `"Socks"` are actually a `&str`, which could be considered as a Wide-pointer that holds the memory address to some data plus the length of the data (i. E. How many chars can you safely read. It's kind of like Java' s Arrays, which you can find the array's length by reading the 'length' attribute)
"&str" are different from "String" because the first is a "wide-pointer" that holds some memory addres + the length, whereas the second is dynamic sized array (Vectors).
The String (which is a vector under the hood) would additionally hold the capacity, so you can know how many more chars/bytes can you push into the allocation, before you need to re-allocate the string in the heap to get more writing space.
Short form:
`String` can be gotten from a "&str", which is where CodeToTheMoon used it the most, and because he was storing Strings, and not & str's, he needed to call ".into()" because Rust doesn't do implicit conversions
Noice!
Thank you! 🙏
Second 🎉
Nice!
Longest 12 minutes video. To fully understand, watch/listen multiple times.
Thanks for the feedback. Would a slower pace have been better?
@ No, the pace and the delivery are good. The topic is not an easy one.
Third! yay
Nice!
I don't like Rust just because of ceremony of writing borrowing, ownership fluff.
Understandable!
This is because Rust is a low-level language so it doesn't have any garbage collector, so you shouldn't compare Rust to high-level languages such as C#, Java, JavaScript or Python, you should compare it to other low-level languages such as C, C++, D and Zig. When you compare Rust to other low-level languages you will see why the borrowing and ownership stuff is amazing.
Weak