3.3 Type assertion - assumes interfaces and structs understood

[composer22]

You introduce the idea of type assertion with examples of interfaces and structures.

1. these are complicated syntactical examples that are difficult to understand in the realm of the basic language. Dot notation with some shit in-between parens:

y.(map[string]interface{})
value.(type)

2. the reader has not been introduced to the concepts of interfaces or structs yet so it cannot be understood in this sequence.

Consider moving this section to advanced concepts and perhaps referencing this:

ex 3.3 Type assertion

"for more advanced subject of type conversion, please see section 2001.1" etc

EDIT: I think the whole document could use a good edit so that the examples and subjects flow with what is learned. Throughout the book, examples are presented using concepts and techniques that have not yet been introduced and explained, therefore it frustrates.

[mattetti]

These are very valid arguments. I'll leave this ticket open until I have time to take care of it or get a PR. Thanks a lot

[composer22]

I should mentioned positive points to you though. I like how you introduce "hints" on what to avoid or take advantage of, such as named params. Another example of something interesting thing I learned today was [...]string{ } when loading string vars. and another, how structs and interffaces really work. I never saw this before. I also like how you cross reference the doc to external documentation from other sites.

All in all this is a great continuation over the basic documentation tour with golang. We really need something like this so we can dig down into the langauge and come up with easy to understand best practice of patterned use. Thanks!

[iartarisi]

I just came here to raise the same issue. I just reached the Type assertion section and have been scratching my head for half an hour at what interfaces are and especially what an empty interface is.