Move Bare Metal day after Concurrency.

[qwandor]

It assumes students are already familiar with Send and Sync at least, and is a more specialised topic so makes more sense to be later.

[mgeisler]

I've been hesitant to approve this since I've ordered the extra days in the A-B-C order (Android, Bare-metal, Concurrency) everywhere now...

However, it's of course also not good to teach people things in the wrong order, if they choose to do both days.

Is Send used anywhere outside of More traits in the bare-metal part? I cannot find any other reference to it, and the reference there is very minimal.

@djmitche and @rbehjati, you worked extensively on the concurrency chapter. Do you have opinions on this?

[djmitche]

These are intended to be taught separately, and regardless of the slide order students in the Bare Metal course likely haven't seen the Concurrency course.

If Bare Metal requires an understanding of send/sync, it should include that inline.

[mgeisler]

These are intended to be taught separately, and regardless of the slide order students in the Bare Metal course likely haven't seen the Concurrency course.

If Bare Metal requires an understanding of send/sync, it should include that inline.

That is a point I hadn't considered... thanks!

When I sat in on the first run of the bare-metal class, I don't recall Send or Sync being very important. I also didn't focus on them when teaching the class myself later. However, from later discussions with @qwandor, I understand that they do matter: for example for static variables. Perhaps a good solution would be to actually explain where Send matters on a new slide?

[rbehjati]

Is a deep knowledge of Rust concurrency required for understanding the use of Send in Bare Metal? If not, I agree that including a single slide to briefly introduce Send could be enough and possibly a better approach, as it can make the course more self-contained.

I've ordered the extra days in the A-B-C order (Android, Bare-metal, Concurrency) everywhere now...

I like the alphabetical ordering :)

[djmitche]

So next up are

• Data Science
• Error Handling
• FFI
• GPU Programming
• Higher Ordered Types

that's all I've got :)

[mgeisler]

I think we should close this: the deep-dives are not supposed to have dependencies on each other. I would like to see the structure like this, with no implied relationship between the pillars on top of the foundation:

┌───────┐  ┌───────┐  ┌───────┐
│   A   │  │   B   │  │   C   │
│   n   │  │   a   │  │   o   │
│   d   │  │   r   │  │   n   │
│   r   │  │   e   │  │   c   │
│   o   │  │   -   │  │   u   │
│   i   │  │   M   │  │   r   │
│   d   │  │   e   │  │   r   │
│       │  │   t   │  │   e   │
│       │  │   a   │  │   n   │
│       │  │   l   │  │   c   │
│       │  │       │  │   y   │
└───────┘  └───────┘  └───────┘

┌─────────────────────────────┐
│                             │
│      Rust Fundamentals      │
│                             │
└─────────────────────────────┘

[qwandor]

If you want that then I think we should move the basic concurrency content back into the main course.

[mgeisler]

If you want that then I think we should move the basic concurrency content back into the main course.

I don't like this idea since we now have a nicely well-rounded day about Concurrency. Splitting that seems like a step back.

[djmitche]

Maintaining the independence of the deep-dives is important to the structure of the course.

There will likely be a few minor inter-dependencies -- the one mentioned above was Send and Sync. Those can either be mentioned briefly in the "fundamentals" course with an advert for the deep-dive, or described in relation to the other deep-dive where they are required.

In the case of Send and Sync, it might make sense to briefly cover those in the "Important Traits" section of Fundamentals.

[mgeisler]

Maintaining the independence of the deep-dives is important to the structure of the course.

Yes, I think so too. When we started out, it was all lumped together and we could move things around as we pleased :smile: Now that we have more structure, we should be more careful about this.

In the case of Send and Sync, it might make sense to briefly cover those in the "Important Traits" section of Fundamentals.

That's a nice idea!

[mgeisler]

Let us close this now since we will want to avoid dependencies between the deep dives.