Microsoft's Introduction to Rust Video Course(youtube.com)
youtube.com
Microsoft's Introduction to Rust Video Course
https://www.youtube.com/playlist?list=PLlrxD0HtieHjbTjrchBwOVks_sr8EVW1x#
50 comments
Sometimes people just need to get started by doing something with technology that they are interested in. Once they get past the first hurdle or two, they are more able to absorb the deeper material.
I have a lot of books where I read quite a bit about something, but never really did anything.
There's a ton of great information about rust, so perhaps they thought getting the right kickstart in front of the right people would be most impactful.
I have a lot of books where I read quite a bit about something, but never really did anything.
There's a ton of great information about rust, so perhaps they thought getting the right kickstart in front of the right people would be most impactful.
I'm not really a fan of that model either, but for what it's worth, Ryan Levick, one of the presenters, has some good learning material on Youtube that's long form. https://www.youtube.com/c/RyanLevicksVideos/videos
> step is simply a "next step", and the narrator merely describes what is being done
I mean; it's listed a Demo. That's a little unfair I think unless they don't go into more detail in the other other 34 (!!) videos in the course.
I mean; it's listed a Demo. That's a little unfair I think unless they don't go into more detail in the other other 34 (!!) videos in the course.
If a demo is this, then my view is that it's no good.
Here's a demo: https://www.youtube.com/watch?v=MCs5OvhV9S4
Notice in the Rust case the narrator is just "announcing" what's happening.
Notice in the Python case the narrator is explaining why they are doing something; what they are doing; critically evaluating it (why its good/bad).
Notice also, that David uses humour and brings people on a "journey through a thought process".
Here's a demo: https://www.youtube.com/watch?v=MCs5OvhV9S4
Notice in the Rust case the narrator is just "announcing" what's happening.
Notice in the Python case the narrator is explaining why they are doing something; what they are doing; critically evaluating it (why its good/bad).
Notice also, that David uses humour and brings people on a "journey through a thought process".
You're comparing a 46 minute presentation with single 5 minute slice of a 160 minute course?
(I have watched that concurrency pycon session previously - it is good.)
(I have watched that concurrency pycon session previously - it is good.)
Yes, I am. I am rejecting the premise that videos should be 5min. That 10min on traits and a 5min "demo" in this style is actually a productive form of learning.
If you can only do 160 min, do a 160 min journey. Consider any of the 3hr tutorial videos done at pycon.
10 min on traits, within that 160min, I think would be very productive.
EDIT: from elsewhere in this thread: https://www.youtube.com/watch?v=WnWGO-tLtLA -- c. 3hrs on rust (I havent seen it, but I suspect that it is approached as a journey, will improve its quality).
If you can only do 160 min, do a 160 min journey. Consider any of the 3hr tutorial videos done at pycon.
10 min on traits, within that 160min, I think would be very productive.
EDIT: from elsewhere in this thread: https://www.youtube.com/watch?v=WnWGO-tLtLA -- c. 3hrs on rust (I havent seen it, but I suspect that it is approached as a journey, will improve its quality).
You can watch as many sequenced 5 minute videos as you wish in a single sitting; The fact that they're divided into separate videos in a playlist is hardly different than taking a longer video and marking the timestamps where different ideas are presented.
That’s technically true, but it’s obviously not true in practice — a 5-min video system means that everything will be self-contained within those 5 minutes.
TV is the clearest counter-example (though it has additional constraints, like week-long gaps) — you need an ending at each 30 minutes, because you don’t expect the viewer to watch 4 episodes in one sitting. And this obviously isn’t the same as 2 hrs in a movie, where they expect the viewer to sit through the whole thing continuously.
Even on Netflix, where they do expect you to binge watch, they still have to uphold the ending-per-episode constraint, because they’ve told the viewer this is a natural stopping point, by virtue of the format
TV is the clearest counter-example (though it has additional constraints, like week-long gaps) — you need an ending at each 30 minutes, because you don’t expect the viewer to watch 4 episodes in one sitting. And this obviously isn’t the same as 2 hrs in a movie, where they expect the viewer to sit through the whole thing continuously.
Even on Netflix, where they do expect you to binge watch, they still have to uphold the ending-per-episode constraint, because they’ve told the viewer this is a natural stopping point, by virtue of the format
People are talking out both sides here. Complaining that the 5 minute demo isn't giving enough context; but also saying that you can't get deep enough in 5 minutes because the 5 minute video has to rehash to add context.
I get it; some people dislike short videos; but there's also a fare bit of straw man building going on at the same time, starting at the dislike and trying to justify it.
Luckily we have lots of options :)
I get it; some people dislike short videos; but there's also a fare bit of straw man building going on at the same time, starting at the dislike and trying to justify it.
Luckily we have lots of options :)
I think there's a place for both types of presentation. Strang is giving a conceptual overview, and a listener is necessarily passive. The MS videos are presenting technical details of how to write rust programs, and bite-sized chunks can be good there, because they provide natural stopping points for listeners to experiment with the presented methods. Similarly, I could see bite-sized videos being natural for teaching the business of actually calculating solutions to a system of linear equations.
Im skeptical of this kind of educational material.
It seems like they want to provide the feeling and the aesthetic of learning, but aren't willing to dig in to the hard work of it.
I think it has a lot to do with the people producing it just not being educators; at least, not for years and not with the 100s/1000s of students necessary to build up those skills.
And a lot of the training for technical educators is based around technical learning being tool-based; where you do just need a series of short videos on a GUI.
It's a complex problem.
I am aware, however, that a lot of people working in online learning think that this is a good style. I believe as it helps with learner engagement.
I have to think, however, that this is just because there's nothing actually challenging to engage with.
And a lot of the training for technical educators is based around technical learning being tool-based; where you do just need a series of short videos on a GUI.
It's a complex problem.
I am aware, however, that a lot of people working in online learning think that this is a good style. I believe as it helps with learner engagement.
I have to think, however, that this is just because there's nothing actually challenging to engage with.
There is choice overload.
People are willing to dig in and learn deep concepts. But they have to get past analysis paralysis first, and start doing something.
People are willing to dig in and learn deep concepts. But they have to get past analysis paralysis first, and start doing something.
It's definitely pitched weirdly. Like it thinks maybe a decision maker is viewing these courses to decide if their team should use Rust or learn from these videos, rather than anybody who'd actually need an introductory video.
The seventh (of 35) video is about variables. It spends some time justifying the existence of variables. But wait, this series claims that it is intended for existing programmers, and it's a stretch to imagine any of that intended audience get value from being told what variables are.
This video introduces mutability, tells viewers Rust's variables are immutable by default, but then it lurches off to talk about constants which, it notes, are also immutable.
Why? To do this the video also needs to introduce boilerplate it doesn't have time to explain, because Rust's constants need an explicit type and neither types nor the type inference used already are explained in this video of course.
It also makes a false claim - which may even have been true when some of the presenters learned Rust, that Rust's constants can't be defined in terms of a function. In fact today they can be defined using const functions, such as String::new() and function execution happens at compile time (even if you've got a foreign target so it needs to behave differently than local native code).
But having introduced constants, and immutability, we don't really learn anything about why Rust has these separately.
And that's it, the whole video. I don't know what value somebody gets from this very brief format.
Many years ago I helped teach Java to CM1xx undergraduates, and although a double (two hours) is probably too much to digest, an hour is at the short end of what I thought was useful to actually get material out of my head and into the students' heads.
I never took that class, it was introduced after I graduated, I learned Standard ML instead, and IMNSHO that was a better choice to learn programming (but industry wanted Java not ML, and industry hires graduates) but even with the much reduced boilerplate in ML, I can't see how I'd have learned anything in five minute chunks. And Rust is not a smaller or easier language than SML.
Take currying. Possible but awkward and rarely important in Rust, yet crucial to ML. I can see a one hour class with either experienced programmers who've never seen first class functions before or newbies who hadn't seen any function at all until last week, both getting to a place where the students see that currying is useful. But in five minutes all you can do is rush through some trivial demo that doesn't reveal even to an attentive audience how powerful this idea actually is.
Are twelve, five minute segments worth an hour? I think emphatically not.
That said, I would like to see someone's attempt at a serious CM1xx style course teaching Programming with Rust as first language. I don't know if that's a good idea, but if anybody tries it I would like to see it anyway.
The seventh (of 35) video is about variables. It spends some time justifying the existence of variables. But wait, this series claims that it is intended for existing programmers, and it's a stretch to imagine any of that intended audience get value from being told what variables are.
This video introduces mutability, tells viewers Rust's variables are immutable by default, but then it lurches off to talk about constants which, it notes, are also immutable.
Why? To do this the video also needs to introduce boilerplate it doesn't have time to explain, because Rust's constants need an explicit type and neither types nor the type inference used already are explained in this video of course.
It also makes a false claim - which may even have been true when some of the presenters learned Rust, that Rust's constants can't be defined in terms of a function. In fact today they can be defined using const functions, such as String::new() and function execution happens at compile time (even if you've got a foreign target so it needs to behave differently than local native code).
But having introduced constants, and immutability, we don't really learn anything about why Rust has these separately.
And that's it, the whole video. I don't know what value somebody gets from this very brief format.
Many years ago I helped teach Java to CM1xx undergraduates, and although a double (two hours) is probably too much to digest, an hour is at the short end of what I thought was useful to actually get material out of my head and into the students' heads.
I never took that class, it was introduced after I graduated, I learned Standard ML instead, and IMNSHO that was a better choice to learn programming (but industry wanted Java not ML, and industry hires graduates) but even with the much reduced boilerplate in ML, I can't see how I'd have learned anything in five minute chunks. And Rust is not a smaller or easier language than SML.
Take currying. Possible but awkward and rarely important in Rust, yet crucial to ML. I can see a one hour class with either experienced programmers who've never seen first class functions before or newbies who hadn't seen any function at all until last week, both getting to a place where the students see that currying is useful. But in five minutes all you can do is rush through some trivial demo that doesn't reveal even to an attentive audience how powerful this idea actually is.
Are twelve, five minute segments worth an hour? I think emphatically not.
That said, I would like to see someone's attempt at a serious CM1xx style course teaching Programming with Rust as first language. I don't know if that's a good idea, but if anybody tries it I would like to see it anyway.
different people learn in different ways. Microsoft isn't claiming to be the one stop shop for Rust here. I'm a strong believer that programming content should take all lengths and all mediums. It's not about having a randomized controlled trial test comparing effectiveness. It's about reaching the % of the population that is for whatever reason attracted by this format - and by no means is anyone saying they should stop there.
tldr; let them make this stuff, it doesnt teach everything but learners will figure that out anyway once they are engaged.
tldr; let them make this stuff, it doesnt teach everything but learners will figure that out anyway once they are engaged.
> different people learn in different ways.
That just avoids the discussion altogether. We can’t evaluate any form of education or presentation or description because “different strokes for different folks” — but we know some styles are almost-objectively bad (beating you with a shovel once a minute while I teach you is an all-around terrible idea, even if I can’t prove it — different learning styles!), which means we have an metric we can evaluate by and discuss on, even if it’s largely driven by intuition and anecdotal experience.
The question here is, for a novice, does this trick you into thinking you’ve learned something, when you really haven’t? A novice also doesn’t have the knowledge to effectively judge that, because, well, it’s a novice.
That just avoids the discussion altogether. We can’t evaluate any form of education or presentation or description because “different strokes for different folks” — but we know some styles are almost-objectively bad (beating you with a shovel once a minute while I teach you is an all-around terrible idea, even if I can’t prove it — different learning styles!), which means we have an metric we can evaluate by and discuss on, even if it’s largely driven by intuition and anecdotal experience.
The question here is, for a novice, does this trick you into thinking you’ve learned something, when you really haven’t? A novice also doesn’t have the knowledge to effectively judge that, because, well, it’s a novice.
i understand that there are some known bad ways. but you are dangerously close to concluding that your way is the One True Way to learn here. neither of us has data so i'm gonna leave it there :)
> you are dangerously close to concluding that your way is the One True Way to learn here
No I’m not. I’m only arguing that there’s clearly room for discussion. That different strokes for different folks is a cop-out (in fact, I don’t believe it’s ever a useful idiom).
In fact, I don’t think I’ve even suggested a preference for any particular strategy — well, other than that beating someone with a shovel is not an effective method of education, but I assume you already agree with that.
Unless you’ve determined that any willingness to engage is in itself a signal to extreme preference (or taking an extreme stance against your position) — but I believe thats known as a ridiculous assumption.
No I’m not. I’m only arguing that there’s clearly room for discussion. That different strokes for different folks is a cop-out (in fact, I don’t believe it’s ever a useful idiom).
In fact, I don’t think I’ve even suggested a preference for any particular strategy — well, other than that beating someone with a shovel is not an effective method of education, but I assume you already agree with that.
Unless you’ve determined that any willingness to engage is in itself a signal to extreme preference (or taking an extreme stance against your position) — but I believe thats known as a ridiculous assumption.
Microsoft Learn has Rust learning content as well: https://docs.microsoft.com/learn/paths/rust-first-steps/
I discovered Microsoft Learn about six months ago, and still can't believe it: Microsoft putting up programming tutorials and guides with XP and whatnot.
I also found it funny that the part on setting up the dev environment in Python worths more XP than the memory management part in the Rust course.
I also found it funny that the part on setting up the dev environment in Python worths more XP than the memory management part in the Rust course.
I hadn't heard of this resource (Microsoft is terrible at promoting their stuff).
But I will say that I first learned programming by reading MSDN documentation on CDs that I got for free through my high school.
I'll forever be grateful to the company for putting that content out.
But I will say that I first learned programming by reading MSDN documentation on CDs that I got for free through my high school.
I'll forever be grateful to the company for putting that content out.
This is more of a question to anyone that may have insider information
It is normal for any large organization to be interested and use many language
But is microsoft really getting invested and interest in Rust? Will the start using Rust for some of their major products Or is this just business as usual
It is normal for any large organization to be interested and use many language
But is microsoft really getting invested and interest in Rust? Will the start using Rust for some of their major products Or is this just business as usual
I've seen news that Microsoft is adopting Rust for safe systems programming. I believe they've been investing in Rust for a while.
- https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe...
- https://github.com/microsoft/windows-rs
- https://cloudblogs.microsoft.com/opensource/2021/02/08/micro...
- https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe...
- https://github.com/microsoft/windows-rs
- https://cloudblogs.microsoft.com/opensource/2021/02/08/micro...
It's also very in-character for them to push for safer languages. They have quite successfully pushed C# over C++ for Windows software development, and pushed more and more static analysis into (c/c++) Windows driver development.
Yep. And at MS Research they've had various projects focusing on safe languages over the past couple decades (the time I've paid attention to it, probably more research preceding that).
It would make sense for MS to be interested in an existing, popular, relatively mature language that possessed many of the safety features their research languages have explored.
It would make sense for MS to be interested in an existing, popular, relatively mature language that possessed many of the safety features their research languages have explored.
I think Joe Duffy mentioned somewhere that if Rust was around when they started Midori, that would have been their option instead of creating System C# (aka M#), but I cannot find that quote.
There are a smattering (36 right now) of job openings on their career site that mention rust: https://careers.microsoft.com/us/en/search-results?keywords=... A few seem to be boilerplate lists of languages, but some actually mention a preference for candidates that know rust. My read on this is that there are probably some small teams (looks like in Azure) that use rust. But I don't see a big company-wide push yet--there would be a lot more open positions if so.
There are teams that are big into Rust and are hiring for it. They seem to be mostly in Windows and Azure, which makes sense: both have a huge need for safety and reliability (moreso than other areas).
But Windows has been around for 35 years; it's a huge C++ codebase, so trying to turn that ship takes time. And just as you can't wholesale rewrite Linux in Rust, it'll take time to integrate Rust into the OS. I assume Azure is a bit easier since there are new services coming online all the time that aren't necessarily dependent on others. I imagine that as these safety- and performance-critical 'experiments' take off, you'll see other teams investing in a big way. (FD: I'm in the Windows org but don't have any sort of special knowledge of the decision calculus here.)
But Windows has been around for 35 years; it's a huge C++ codebase, so trying to turn that ship takes time. And just as you can't wholesale rewrite Linux in Rust, it'll take time to integrate Rust into the OS. I assume Azure is a bit easier since there are new services coming online all the time that aren't necessarily dependent on others. I imagine that as these safety- and performance-critical 'experiments' take off, you'll see other teams investing in a big way. (FD: I'm in the Windows org but don't have any sort of special knowledge of the decision calculus here.)
Microsoft has been using Rust in shipping products since at least 2018.
The reason may be that just like Mozilla Foundation, they may be tired of dealing with bugs such as buffer overflow, integer overflow, undefined behaviours and use-after-free which are responsible for most security vulnerabilities that still haunts C and C++.
Would be great if such materials go beyond console apps. I hope desktop/GUI topic gets more attention.
There needs to be a Rust translation of Learn Go With Tests[1]. It’s the best programming book i’ve ever used.
[1]: https://quii.gitbook.io/learn-go-with-tests/
[1]: https://quii.gitbook.io/learn-go-with-tests/
I’ve poked around with GUI code in Rust and it just feels strange without some flavor of OOP. To me it makes much more sense to develop GUI apps with a bit higher level of abstraction (or lower?) than a rather functional interface.
Traits are pretty decent for UI's.
There aren't any solid GUI solutions for Rust yet though.
If you are not afraid of unsafe blocks and extern "C" functions, it is possible to call a any C api directly including Win32 API for GUI graphical user interfaces. On Linux, one can call Gtk directly or call Qt through a custom C wrapper. The only problem is that both methods are not cross-platform. However, one with enough motivation can develop a cross-platform unified wrapper or interface that abstracts Gtk, X11 and/or Win32 API and MacOSX cocoa API.
Calling Qt5 widgets through a custom C-wrapper may be a better approach than reinventing the whell since Qt already abstracts Win32 API, Unix X11 (X Windows Systems), Unix-Wayland, and MacOSX Cocoa .
Calling Qt5 widgets through a custom C-wrapper may be a better approach than reinventing the whell since Qt already abstracts Win32 API, Unix X11 (X Windows Systems), Unix-Wayland, and MacOSX Cocoa .
There aren't any mature solutions yet, but you can find a list of GUI frameworks here:
http://www.areweguiyet.com/
http://www.areweguiyet.com/
I'm pretty sure Rust can run in the browser via WASM.
[deleted]
Microsoft really could be using their resources much better than this... Seriously..
Lifetimes! That's what I need help with! How do you learn lifetimes?
I am building my first "big" project in Rust, and went through this issue.
Lifetimes are actually pretty simple, although anonymous lifetimes and the compiler inserting implicit lifetimes at compile-time can make the actual behaviour hard to parse.
But if you are saying you don't get it, and you are in the middle of a project (my state a week ago) then the issue is your code. References everywhere gets messy very quickly with Rust's borrow checking, and lifetimes should be used sparingly.
I will also give my very imprecise definition: adding a lifetime to a struct means those references in the struct cannot die before the struct dies itself (and where this can go wrong is having some kind of mutable state composed of references...because when you try to mutate that state from an implementation, the data will be destroyed as you go out of scope, and you have a dangling pointer).
They seem like an unnecessary complication, they certainly did to me when I was wading through compiler errors...then I try to do something wrong, and I realised why they exist. It is really worth sticking with.
Lifetimes are actually pretty simple, although anonymous lifetimes and the compiler inserting implicit lifetimes at compile-time can make the actual behaviour hard to parse.
But if you are saying you don't get it, and you are in the middle of a project (my state a week ago) then the issue is your code. References everywhere gets messy very quickly with Rust's borrow checking, and lifetimes should be used sparingly.
I will also give my very imprecise definition: adding a lifetime to a struct means those references in the struct cannot die before the struct dies itself (and where this can go wrong is having some kind of mutable state composed of references...because when you try to mutate that state from an implementation, the data will be destroyed as you go out of scope, and you have a dangling pointer).
They seem like an unnecessary complication, they certainly did to me when I was wading through compiler errors...then I try to do something wrong, and I realised why they exist. It is really worth sticking with.
Honestly, the best way to learn is by diving in and implementing something.
Personally I learned how lifetimes work by implementing a zero-copy parser: it builds an AST that borrows from the original string instead of copying tokens out. This is one of those tasks where Rust really shines.
Personally I learned how lifetimes work by implementing a zero-copy parser: it builds an AST that borrows from the original string instead of copying tokens out. This is one of those tasks where Rust really shines.
Out of curiosity, what did you parse? Since in I imagine copying things is quite useful sometimes when generating an AST. On top of that, I think sometimes you can't avoiding copying (imagine a string with special backslash sequences like \x20, you probably copy parts of the string that don't need special interpolation)
That's right. At that point I learned about std::borrow::Cow (copy-on-write) and it worked pretty nicely. The unescaping is done lazily (on access) so it's indeed zero-copy unless strictly necessary.
The parser was for a tiny language we use to express references within graphs over at membrane.io. similar to URLs but typed and not ambiguous. It's simple enough. Perhaps writing a URL parser would be good for learning.
The parser was for a tiny language we use to express references within graphs over at membrane.io. similar to URLs but typed and not ambiguous. It's simple enough. Perhaps writing a URL parser would be good for learning.
Like all of his videos, Jon Gjengset's live coding session on lifetimes is excellent: https://www.youtube.com/watch?v=rAl-9HwD858
I've linked this on HN four or five times but it remains a great introduction to the specific quirks of working with Rust: https://rust-unofficial.github.io/too-many-lists/
Are you aware of this? https://doc.rust-lang.org/nomicon/lifetimes.html
You should read about it a bit first, but the only real way is to do some coding.
I'm really not a fan of it.
There's something not quite right in treating "conceptual learning" as if it were a sort of follow-these-steps "to tie a knot" problem.
Imagine https://www.youtube.com/watch?v=J7DzL2_Na80#t=2m20s as a series of 5min videos...
It also seems like Microsoft produces a lot of developer videos done in this style, as if the thing to be learned were a wizard ("next, next, next, next").
Consider the video: https://www.youtube.com/watch?v=ajvipmDMwAg . Each step is simply a "next step", and the narrator merely describes what is being done.
Gilbert would, I'd say begin with the problem: "Suppose we're looking a films. And what is a film? It's these things: ..... Now in Rust we model that with a struct -- ".
And so on: the learning here is illustrating the connection between the mindset of programming and the activity.
Quite a lot of what I've seen from Microsoft, and increasingly many 5-min-by-5min courses, is very little modelling of thought process. The very thing to be learned.