go-typeslisted

# Go Types Go's type system rewards restraint. The most common mistakes — large interfaces, premature generics, type assertions without comma-ok — all come from over-engineering. Prefer concrete types until abstraction earns its place. ## Interfaces Interfaces are satisfied implicitly. No `implements` keyword — if a type has the methods, it satisfies the interface. This makes interfaces powerful and dangerous: it's easy to define one that nobody actually satisfies. **Keep interfaces small.** The standard library's best interfaces have one or two methods: `io.Reader`, `io.Writer`, `fmt.Stringer`. One method = one behavior = easy to satisfy, easy to compose. ```go // Good: focused, composable type Reader interface { Read(p []byte) (n int, err error) } // Bad: eight methods means eight things your mock, stub, or test double must implement type UserService interface { GetUser(id string) (*User, error) ListUsers() ([]*User, error) CreateUser(u *User) error UpdateUser(u *User) error DeleteUser(id string) error SearchUsers(query string) ([]*User, error) GetUserByEmail(email string) (*User, error) CountUsers() (int, error) } ``` **Define interfaces at the point of use, not the point of definition.** The package that *uses* an abstraction should own the interface. The package that *implements* it should expose a concrete type. This avoids unnecessary coupling and import cycles. ```go // Bad: defined in the implementing package — forces calle