What should we cover next?

[mgeisler]

Hi all, thanks so much for all the PRs you've sent me and the team in the last 24 hours!

I've discussed with people a bit on Reddit and on Hacker News about what topics we should still cover in the course. The main ones that come to my mind are

• Async Rust. We only cover traditional thread-based concurrency in the course.
• Interior or shared mutability. We don't cover Cell and RefCell in the course.

Other things on your mind?

One thing that we've discussed in the team (and it was actually brought up during a class) is that it would be helpful to have a section with an opinionated guide to "Real World Rust". Something that tells you how to solve common problems, guides you towards useful libraries, and otherwise helps new developers on their way.

[mgeisler]

We also have #34 where we get a new section on how to call Rust from Java. I'm thinking we could add an ad-hoc section at the end of the course for such extra topics — extra in the sense that they might not fit in directly in the four days we currently use for the course.

[mgeisler]

We should include a page on https://docs.rs/crate/googletest/latest.

[Luosuu]

Actually I think we need more explanation about why we need and when to use. Rust is built with years of experience in software engineering but not every learner knows where these smart designs of Rust come from...

[mgeisler]

That is a good point! So you think we should put more emphasis on explaining why Rust is a good language to use? And perhaps also explain when it is not a good choice?

I wrote the course from the perspective of someone who already knows they want to use Rust, but you're right that we should also cover the other audience to make sure everybody can get up to speed.

[rbutarascu]

I would very much be interested in finding out why Rust is a good language, when to use it and when not to use it. Thank you!

[mgeisler]

Great, I created #132 for this!

[mgeisler]

@brandonpollack23, as we discussed on chat: we should add a section with suggested libraries for solving common tasks.

[brandonpollack23]

Yeah, as we mentioned in chat some suggestions I had were:

• clap command like parser (macro and non macro versions)
• build.rs scripting
• I also removed this section, but we might want to mention dealing with runtime evaluated constants with crates like OnceCell or lazy_static.
• closed source cargo package registry
• Various important other packages in blessed.rs
• Async Rust (Tokio/async std) and how futures work under the hood (Pinning and code generation with async await, etc. There are some good talks to point people to for this)

And some lower priority ones:

• Unbounded lifetimes in unsafe
• Undefined behaviour in unsafe
• Custom allocators/switching allocators
• nostd rust intro and links to book

After I'm done with my review of the book and adding what I can that is useful I'll start on those and have them reviewed as well :)

[mgeisler]

• Async Rust (Tokio/async std) and how futures work under the hood (Pinning and code generation with async await, etc. There are some good talks to point people to for this)

This is now being worked on by @djmitche, @rbehjati, and @sakex in #181.

[Mandragorian]

I believe a collection of common rust patterns might be useful. I was thinking of snippets of code that might not be that common to be included in stdlib, but also are quite common that are worth knowing. Some examples I was thinking:

• Using an enum with two variants instead of bool for better readability
• Preventing struct literals by including a private field
• Using generics for dependency injection

This will probably not be a homogeneous list since "common but not that common". But I think having a small list of cool tricks can be motivational, plus it might give incentive to students to explore other aspects of the language on their own.

[sakex]

Some top of mind ideas

• const methods and const generics
• More standard collections like BTreeMap
• WASM
• build.rs
• Structure of a large project
• features

[djmitche]

That all sounds like a lot to pack into 4 days!

I wonder if we shouldn't have a collection of "things to explore next" that aren't actually covered in the class, but with links to start?

If that comes at the end, then a class that gets done witih an hour or two remaining could select one to explore together.

[mgeisler]

That all sounds like a lot to pack into 4 days!

I wonder if we shouldn't have a collection of "things to explore next" that aren't actually covered in the class, but with links to start?

Yes, that would be a good model.

The way I'm starting to think of things is that we'll have a Rust Fundamentals part which is ~3 days in duration. Follow this, we will offer 1-day courses on a vararity of topics such as the ones @Mandragorian and @sakex mention above.

We're already starting on this path with your changes to Day 4 and with @qwandor's bare-metal Rust day.

[rbehjati]

On Thu, Apr 13, 2023 at 10:31 AM Martin Geisler ***@***.***> wrote: That all sounds like a lot to pack into 4 days! I wonder if we shouldn't have a collection of "things to explore next" that aren't actually covered in the class, but with links to start? Yes, that would be a good model. The way I'm starting to think of things is that we'll have a Rust Fundamentals part which is ~3 days in duration. Follow this, we will offer 1-day courses on a vararity of topics such as the ones @Mandragorian <https://github.com/Mandragorian> and @sakex <https://github.com/sakex> mention above.

I like that way of splitting the course. It also helps with splitting the work between instructors. If a session ends early, I think it is more effective to use the remaining time to go deeper into the already discussed topics, instead of starting a new one. The other topics could potentially be additional extension courses.

…

We're already starting on this path with your changes to Day 4 and with @qwandor <https://github.com/qwandor>'s bare-metal Rust day <https://google.github.io/comprehensive-rust/welcome-bare-metal.html>. — Reply to this email directly, view it on GitHub <#32 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADCXZ5M5B54RUJKVFKOH5GLXA7BWZANCNFSM6AAAAAATGY2TMU> . You are receiving this because you were mentioned.Message ID: ***@***.*** com>

[mgeisler]

Exactly, it's much more flexible that way. I hope we can have regular sessions with the basics and then offer the more specialized topics on a more irregular basis.