Paquetes Esenciales en Go: Código Rápido, Limpio y sin Exceso

La paradoja del paquete

Go tiene una librería estándar minimal. Eso es intencional. Es también por qué los desarrolladores se enfrentan a 10,000 paquetes de terceros intentando decidir cuál usar.

La paradoja: la simplicidad de Go atrae a desarrolladores que quieren construir con tan pocas dependencias como sea posible. Pero cada proyecto de Go termina con dependencias. La pregunta nunca es si usar paquetes. La pregunta es cuáles usar.

Usa demasiados paquetes y tu base de código se vuelve inmantenible. Cada dependencia transitiva es un cambio que rompe potencial. Cada paquete es un pasivo si el mantenedor lo abandona.

Usa muy pocos paquetes e inventas la rueda mil veces. Escribes código de validación que otros escribieron mejor. Escribes manejo de errores que otros resolvieron más limpiamente. Escribes logging que otros construyeron más rápido.

El balance no es sobre usar la menor cantidad de paquetes. Es sobre usar los paquetes correctos — aquellos que han sido probados en batalla, se mantienen activamente, resuelven problemas reales e integran bien con el resto del ecosistema de Go.

Esta guía mapea los paquetes que cruzan ese umbral. No los de moda. No los con más estrellas en GitHub. Los que realmente mejoran tu código.

Parte 1: Manejo de errores — La base

El manejo explícito de errores de Go es una de sus mayores fortalezas. Toda función que puede fallar retorna un error. Lo manejas. Sin excepciones ocultas. Sin desenrollado sorpresivo de stack.

Pero el tipo bare error es minimal. Para sistemas de producción, necesitas contexto.

El caso para errors/pkg/errors

Durante años, el paquete errors de la librería estándar fue básico. Go 1.13 añadió errors.Is() y errors.As(), lo que ayudó. Pero el paquete de error más útil en Go no está en la librería estándar.

import "github.com/pkg/errors"

func processUser(userID string) error {
	user, err := getUser(userID)
	if err != nil {
		// errors.Wrap añade contexto sin perder el error original
		return errors.Wrap(err, "failed to get user")
	}

	if err := validateUser(user); err != nil {
		return errors.Wrap(err, "user validation failed")
	}

	return nil
}

// Cuando llamas esta función:
func main() {
	err := processUser("123")
	if err != nil {
		// errors.Cause extrae el error raíz
		fmt.Println(errors.Cause(err))

		// errors.WithStack captura el stack trace completo
		fmt.Printf("%+v\n", err)
	}
}

Por qué pkg/errors importa:

Apilamiento de contexto — cada capa añade contexto sin perder el error original
Stack traces — %+v muestra dónde se originó el error
Desempaquetamiento — errors.Cause() encuentra la causa raíz
Compatible estándar — funciona con errors.Is() y errors.As()

Cuándo usarlo: En cualquier lugar donde tu código pueda fallar y necesites entender por qué. Lo que es casi en todas partes en producción.

Errores centinela para lógica del dominio

Para errores específicos del dominio, defínelos como errores centinela en tu paquete de dominio:

// domain/errors.go
package domain

import "errors"

var (
	ErrUserNotFound = errors.New("user not found")
	ErrInvalidEmail = errors.New("invalid email format")
	ErrDuplicate    = errors.New("record already exists")
)

// usage.go
func getUser(id string) (*User, error) {
	if id == "" {
		return nil, ErrInvalidEmail
	}

	user, found := findInDB(id)
	if !found {
		return nil, ErrUserNotFound
	}

	return user, nil
}

// En handlers
if err == domain.ErrUserNotFound {
	return c.JSON(404, "not found")
}

Los errores centinela son simples, explícitos y conscientes del dominio. No son sobre rendimiento o características. Son sobre claridad.

Parte 2: JSON — Codificación y más allá

El encoding/json de la librería estándar es sólido para uso básico. Pero el ecosistema de JSON de Go está fragmentado, y la elección incorrecta crea problemas.

Librería estándar para casos simples

Para codificación y decodificación JSON simple, la librería estándar es suficiente:

type User struct {
	ID    int    `json:"id"`
	Name  string `json:"name"`
	Email string `json:"email,omitempty"`
}

user := User{ID: 1, Name: "Alice", Email: "alice@example.com"}

// Codificación
data, err := json.Marshal(user)
// {"id":1,"name":"Alice","email":"alice@example.com"}

// Decodificación
var u User
err := json.Unmarshal(data, &u)

El JSON de la librería estándar es suficiente para la mayoría de APIs. No es el más rápido, pero es confiable y no tiene dependencias.

Sonic para rutas críticas de rendimiento

Si la codificación de JSON es un cuello de botella — estás serializando millones de objetos por segundo — considera bytedance/sonic.

import "github.com/bytedance/sonic"

// Sonic es 3-5x más rápido que la librería estándar para objetos complejos
data, err := sonic.Marshal(user)
u := User{}
err := sonic.Unmarshal(data, &u)

Sonic logra velocidad a través de instrucciones SIMD y algoritmos ingeniosos. La API es idéntica a encoding/json, lo que la hace un reemplazo directo.

Cuándo usar Sonic: Cuando el profiling muestra que la serialización de JSON está consumiendo CPU significativa. Si no es un cuello de botella, la librería estándar es más simple.

Serialización personalizada para control

Cuando necesitas lógica de serialización personalizada que la librería estándar no puede expresar:

func (u *User) MarshalJSON() ([]byte, error) {
	type Alias User
	return json.Marshal(&struct {
		CreatedAt string `json:"created_at"`
		*Alias
	}{
		CreatedAt: u.Created.Format(time.RFC3339),
		Alias:     (*Alias)(u),
	})
}

Este enfoque es explícito y evita una dependencia adicional.

Parte 3: Logging — Señal en el ruido

Logging es cómo entiendes el comportamiento en producción. El logging malo desperdicia tu tiempo. El logging bueno te salva la vida a las 3 AM.

Logging estructurado con slog

Go 1.21 añadió log/slog, un estándar de logging estructurado. Úsalo:

import "log/slog"

handler := slog.NewJSONHandler(os.Stdout, nil)
logger := slog.New(handler)

logger.Info("user created",
	"user_id", user.ID,
	"email", user.Email,
)

logger.Error("database query failed",
	"query", query,
	slog.String("error", err.Error()),
	slog.Int("retries", 3),
)

Por qué slog importa:

Output estructurado — JSON por defecto, fácil de parsear
Niveles built-in — Debug, Info, Warn, Error
Propagación de contexto — slog.With() añade campos persistentes
Librería estándar — sin dependencia externa
Extensible — handlers personalizados para diferentes salidas

slog es un momento clave para logging en Go. Úsalo en lugar de paquetes más antiguos.

Cuando necesitas más características

slog cubre el 90% de necesidades de logging. Para el 10% restante, considera uber/zap:

import "go.uber.org/zap"

logger, _ := zap.NewProduction()
defer logger.Sync()

logger.Info("user created",
	zap.String("user_id", user.ID),
	zap.String("email", user.Email),
)

Zap es más rápido que slog para logging de alto volumen y tiene un ecosistema más grande de integraciones. Vale la pena agregarlo si logging es una parte significativa de tu sistema.

Parte 4: Validación — Corrección en el límite

La validación ocurre en el límite donde la entrada externa entra en tu sistema. Hazlo mal e datos inválidos corrompen tu dominio.

El paquete Validator

Para validación de struct con reglas basadas en tags:

import "github.com/go-playground/validator/v10"

type RegisterRequest struct {
	Email    string `validate:"required,email"`
	Password string `validate:"required,min=8,max=128"`
	Name     string `validate:"required,min=1,max=255"`
}

validate := validator.New()

req := RegisterRequest{Email: "invalid", Password: "short"}
if err := validate.Struct(req); err != nil {
	// manejar errores de validación
	for _, fieldError := range err.(validator.ValidationErrors) {
		fmt.Printf("field %s failed: %s\n", fieldError.Field(), fieldError.Tag())
	}
}

Por qué validator importa:

Reglas declarativas — la validación está en tags de struct, no dispersa en código
Conjunto rico de validadores — email, URL, UUID, tarjeta de crédito, y docenas más
Validadores personalizados — extiende con tu propia lógica de validación
Mensajes de error claros — entiende por qué falló la validación

Validator es el estándar de Go para validación de entrada. Es casi obligatorio en sistemas de producción.

Parte 5: Testing — Haciendo tests buenos

El paquete testing de Go es minimal pero potente. Sin embargo, para escenarios de test complejos, algunos paquetes merecen su espacio.

Testify para aserciones

El testing de librería estándar requiere código de aserciones verboso:

// Sin testify
if result != expected {
	t.Fatalf("expected %v, got %v", expected, result)
}

Testify lo hace legible:

import "github.com/stretchr/testify/assert"

assert.Equal(t, expected, result)
assert.Contains(t, list, item)
assert.Error(t, err)
assert.NoError(t, err)

Testify es pequeño, añade claridad y es universalmente usado en proyectos de Go. Vale la dependencia.

Testify/Require para aserciones fatales

Cuando un fallo de aserciones debe detener el test:

import "github.com/stretchr/testify/require"

func TestUserCreation(t *testing.T) {
	user, err := createUser("alice@example.com")
	require.NoError(t, err) // Falla el test inmediatamente si error

	require.NotNil(t, user)
	assert.Equal(t, "alice@example.com", user.Email)
}

Usa require para precondiciones, assert para la lógica de test actual.

sqlc para testing de base de datos

Si testas código de base de datos, sqlc genera funciones de query type-safe desde SQL:

-- query.sql
-- name: GetUser :one
SELECT id, name, email FROM users WHERE id = $1;

// Código generado
user, err := queries.GetUser(ctx, userID)
if err != nil {
	return nil, err
}

Sin queries basadas en strings. Sin errores en tiempo de ejecución. El SQL y tipo de Go están sincronizados por el generador de código.

Cuándo usar sqlc: Cuando la corrección de queries de base de datos es crítica. Cuando tienes SQL complejo.

Parte 6: Bases de datos — El driver correcto y herramientas

Librería estándar sql con pgx

Para PostgreSQL, usa la interfaz estándar database/sql con pgx como driver:

import (
	"database/sql"
	_ "github.com/jackc/pgx/v5/stdlib"
)

db, err := sql.Open("pgx", "postgres://localhost/mydb")

row := db.QueryRow("SELECT id, name FROM users WHERE id = $1", userID)
var name string
if err := row.Scan(&id, &name); err != nil {
	return nil, err
}

pgx es performante, tiene excelente manejo de errores y funciona con la interfaz de la librería estándar. Sin sobrecarga de ORM.

Cuándo considerar un ORM: gorm

Los ORMs añaden abstracción. Ese es su propósito y su costo. Para modelos de dominio complejos con relaciones, gorm puede reducir boilerplate:

import "gorm.io/gorm"

var user User
db.Where("email = ?", email).First(&user)

// Las relaciones son automáticas
var posts []Post
db.Model(&user).Association("Posts").Find(&posts)

Cuándo gorm tiene sentido:

Gran número de tablas relacionadas
Queries complejas que se repiten
Equipo familiarizado con patrones de ORM

Cuándo gorm es excesivo:

Operaciones CRUD simples
Lógica de dominio compleja que las queries necesitan soportar
El rendimiento es crítico y necesitas control

La mayoría de proyectos de Go se sirven mejor con sql estándar con un query builder. Gorm puede esconder detalles importantes.

Parte 7: Rendimiento — Profiling y optimización

pprof para entender cuellos de botella

Go tiene profiling built-in. El paquete net/http/pprof expone endpoints de profiling:

import _ "net/http/pprof"

go func() {
	log.Println(http.ListenAndServe("localhost:6060", nil))
}()

// Ahora visita http://localhost:6060/debug/pprof/

Puedes ver perfiles de CPU, asignaciones de memoria, goroutines y más. Esto es invaluable para entender dónde tu código gasta tiempo.

Benchmarking con testing.B

Para código sensible al rendimiento, escribe benchmarks:

func BenchmarkJSONMarshal(b *testing.B) {
	user := User{ID: 1, Name: "Alice", Email: "alice@example.com"}

	b.ResetTimer()
	for i := 0; i < b.N; i++ {
		json.Marshal(user)
	}
}

Ejecuta benchmarks para comparar implementaciones:

go test -bench=. -benchmem

Esto muestra throughput y asignaciones por operación. Es cómo decides si esa optimización ingeniosa es realmente más rápida.

Parte 8: La matriz de decisión de dependencias

Cada paquete que añades es una decisión. Usa esta matriz para decidir:

Pregunta	Respuesta	Acción
¿La librería estándar resuelve esto?	Sí	Usa stdlib, salta el paquete
¿Este paquete se mantiene activamente?	No	Encuentra una alternativa
¿Tiene pocas dependencias?	No	Sé escéptico
¿Se usa ampliamente?	Sí, miles de proyectos	Probablemente seguro
¿Uso el 50%+ de sus características?	No	Usa una alternativa más pequeña
¿Usa go modules?	No	Es antiguo, encuentra opción más nueva
¿Hay una brecha de mantenimiento de 2+ años?	Sí	Riesgo, encuentra alternativa activa
¿Escribir esto toma >4 horas?	No	Escríbelo tú mismo

Un paquete debe pasar al menos 4 de estos obstáculos para valer la dependencia.

Parte 9: El ecosistema de paquetes de Go por caso de uso

Para APIs (REST, gRPC)

Esencial:

chi o gin — routing
pkg/errors — manejo de errores
go-playground/validator — validación de entrada
testify — testing

Opcional:

slog — logging (si no usas servicio de logging externo)

Para CLIs y herramientas

Esencial:

spf13/cobra — parsing de comandos
spf13/viper — configuración
testify — testing

Opcional:

fatih/color — output coloreado
rodapto/progressbar — indicación de progreso

Para procesamiento de datos

Esencial:

encoding/csv — procesamiento de CSV (stdlib suficiente)
sqlc — queries de base de datos type-safe
testify — testing

Opcional:

bytedance/sonic — si JSON es un cuello de botella
uber/zap — logging de alto volumen

Para microservicios

Esencial:

chi — routing
pkg/errors — manejo de errores
slog — logging estructurado
sqlc o pgx — base de datos

Opcional:

grpc o connect-go — comunicación entre servicios
prometheus/client_golang — métricas

Parte 10: La verdad incómoda sobre dependencias

Cada paquete que añades incrementa:

Tiempo de compilación — más código para compilar
Tamaño del binario — más código para incluir
Superficie de seguridad — más código para auditar
Carga de mantenimiento — más código mantenido por otros

La mayoría de proyectos de Go añaden dependencias demasiado libremente. Recurren a un paquete cuando 10 minutos de trabajo bastarían.

Pero esto no significa escribir todo tú mismo. Significa:

Usa la librería estándar para funcionalidad central
Usa paquetes probados en batalla para problemas comunes (errores, validación, logging)
Escribe tú mismo para lógica específica del dominio
Evalúa paquetes por estado de mantenimiento, no popularidad

Las bases de código de Go mejores no son las con fewest dependencias. Son las con dependencias más meditadas.

Un paquete no es un pasivo si resuelve un problema real mejor que tu alternativa. Es un pasivo si usas el 10% de él, o si mantenerlo se vuelve tu responsabilidad porque el mantenedor desapareció.