Idiomatic Go Tells a Story - Kaylyn Gibilterra

[@soberhippie]

I still can't get over the imperative of naming the receiver by the first letter of its name. First of all, it's much cleaner when you see a consistent name for a receiver and don't have to think about what that `t` stands for. Second, what happens if I want to rename my struct? Do I have to go over the whole file and change those letters? Why do I have to do that useless work and why do I have to put my code reviewers through the task of looking through the modified lines that didn't have to change anyway? What if there's already another var `t` in that function, especially considering that 1 letter names are considered good practice in Go? It makes me so irritated that I write youtube comments about it.

[@dawnrazor]

Your comment about where interfaces needs clarification because I think what u r claiming only applies to a specific use case. If a component requires a callback then the interface has to be defined with the component. However, if the interface is for facade purposes then it can be left to the client to define

[@sealoftime]

Great talk, thank you! A code example would really facilitate understanding in my opinion. Majority of enterprise Go projects I've worked with look like this: ./internal ./internal/api ./internal/models ./internal/services (the actual application logic) ./internal/db Would this storytelling approach encourage the developer to put HTTP handlers, specific database queries and domain logic in one package?