Microsoft's Introduction to Rust Video Course
youtube.com
youtube.com
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.
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.
People are willing to dig in and learn deep concepts. But they have to get past analysis paralysis first, and start doing something.
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 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.
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".
(I have watched that concurrency pycon session previously - it is good.)
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).
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
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 :)
tldr; let them make this stuff, it doesnt teach everything but learners will figure that out anyway once they are engaged.
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.
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.
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.
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.
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.
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
- 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 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.
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.)
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 .
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.
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.
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.