go-expert

🔷 Go Expert — Production-Grade Go

Philosophy: Go is about simplicity and clarity. If your Go code is clever, it's wrong. Write boring, obvious code that any engineer can debug at 2 AM.

1. When to Use This Skill

• Writing new Go services or CLI tools
• Reviewing Go code for idioms and best practices
• Designing concurrent systems with goroutines
• Structuring Go projects for maintainability
• Writing effective Go tests and benchmarks
• Debugging Go-specific issues (goroutine leaks, race conditions)

2. Go Idioms

Error Handling — The Go Way

// GOOD: Check errors immediately, add context
user, err := db.GetUser(ctx, userID)
if err != nil {
    return fmt.Errorf("get user %s: %w", userID, err)
}

// GOOD: Custom error types for programmatic handling
type NotFoundError struct {
    Resource string
    ID       string
}

func (e *NotFoundError) Error() string {
    return fmt.Sprintf("%s not found: %s", e.Resource, e.ID)
}

// Check error type
var nfe *NotFoundError
if errors.As(err, &nfe) {
    http.Error(w, nfe.Error(), http.StatusNotFound)
    return
}

// BAD: Ignoring errors
user, _ := db.GetUser(ctx, userID) // Bug waiting to happen

// BAD: Generic error without context
if err != nil {
    return err // Which step failed? Nobody knows.
}

Interfaces — Accept Interfaces, Return Structs

// GOOD: Small, focused interface
type UserStore interface {
    GetUser(ctx context.Context, id string) (*User, error)
    CreateUser(ctx context.Context, u *User) error
}

// GOOD: Concrete struct that implements the interface
type PostgresUserStore struct {
    db *sql.DB
}

func (s *PostgresUserStore) GetUser(ctx context.Context, id string) (*User, error) {
    // Implementation
}

// GOOD: Function accepts interface
func NewUserService(store UserStore) *UserService {
    return &UserService{store: store}
}

// BAD: Interface with 20 methods — too broad
type Repository interface {
    GetUser(...) ...
    CreateUser(...) ...
    DeleteUser(...) ...
    GetTeam(...) ...
    // ... 16 more methods
}