GopherCon 2023: Kaylyn Gibilterra - Idiomatic Go Tells a Story

It can be hard to put a finger on what makes some Go code idiomatic and some code functional, but not quite right. This talk will share a practice I have formed to consistently translate satisfactory Go code into delightful packages and type definitions worth bragging about.
This practice applies principles from storytelling to idiomatic Go code. We will cover how the Hero's Journey can be applied to rethinking your Go packages - complete with world design, character development, and plot points that will turn a potential drudgery of code refactoring into the creative world of story development.

[@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?