Type assertions should be taught earlier than the errors talk

[stellentus]

Since they are different than errors, they should be taught earlier, or else have their own section in the errors talk before errors are introduced. (It should clearly be indicated as an aside.)

But since they are so important for checking errors, it's important to also have an exercise to try using them, so perhaps they should have their own very short talk. (Or we should consider interspersing exercises in a single talk.)

Alternatively, we could remove type assertions from the errors talk. For beginners, it's probably fine if we don't teach about how to check an error type. Creating a custom error is probably also not necessary. I write a lot of go, and I rarely define my own error types. That's partly laziness, but it's still probably not an essential topic.

So I guess my conclusion is actually that type assertions and user-defined errors should be removed to leave more time to work on the exercises.

[grrtrr]

I talked with @torbiak about this, and @nathany also warned me when he reviewed the slides.

The decision is either

• keep them out entirely (so as not to load too much on people on a one-day workshop), or
• along the lines of your suggestion, keep them in, but perhaps plan for a longer workshop format.

I personally like the second choice better, since with type assertions much nicer error handling is possible.
The interfaces talk was fairly short, perhaps type assertions could be part of it?