Guía de Go (Golang): De 0 a 100

¿Qué es Go?

Go (o Golang) es un lenguaje de programación compilado, de tipado estático y concurrente, creado en Google por Robert Griesemer, Rob Pike y Ken Thompson y lanzado públicamente en 2009. Su diseño prioriza la simplicidad, la legibilidad y la productividad del equipo por encima de la expresividad del lenguaje.

Filosofía:

• Compilación rápida, binarios estáticos sin dependencias
• Concurrencia nativa con goroutines y canales
• Tipado estático con inferencia
• Sin herencia de clases (composición sobre herencia)
• Sin genéricos hasta 1.18 (llegaron en 2022 con polémica)
• gofmt como estándar de formato — el formateo no es negociable

¿Dónde se usa?

• CLI y herramientas de sistema: Docker, Kubernetes, Terraform, Hugo, Prometheus, Caddy, Syncthing
• APIs REST y microservicios: net/http, Gin, Echo, Fiber, Chi
• Infraestructura cloud: Docker, Kubernetes, etcd, Consul, Vault, Traefik
• Bases de datos: InfluxDB, CockroachDB, TiDB, Dgraph, Badger
• Redes y proxies: Caddy, Traefik, Envoy (data plane), gRPC
• DevOps: Terraform, Packer, Vault, Consul, Nomad (todo HashiCorp)
• Blockchain: Hyperledger Fabric, go-ethereum

¿Quién lo usa? Google (YouTube, Chrome), Docker Inc, HashiCorp, Cloudflare, Uber, Twitch, Dropbox, Netflix (partes), PayPal, Mercado Libre, Salesforce.

Fuente: Go dev — About, Wikipedia — Go, Go at Google (Rob Pike)

Prerrequisitos

Antes de empezar, necesitas:

• Conocimientos básicos de terminal: navegar directorios, ejecutar comandos, usar un editor de texto
• El lenguaje/herramienta instalado en tu sistema (sigue la sección de Instalación si aún no lo tienes)

Si no cumples algún requisito, no te preocupes: cada sección te guiará paso a paso.

¿Cómo empezar? Instalación en todos los entornos

Linux (Debian/Ubuntu)

# Opción 1: paquete oficial
wget https://go.dev/dl/go1.24.2.linux-amd64.tar.gz
sudo rm -rf /usr/local/go && sudo tar -C /usr/local -xzf go1.24.2.linux-amd64.tar.gz
echo 'export PATH=$PATH:/usr/local/go/bin' >> ~/.bashrc
source ~/.bashrc
go version

# Opción 2: gestor de paquetes
sudo apt install golang-go  # versión del repo, suele ir atrasada

# Opción 3: snap
sudo snap install go --classic

macOS

# Homebrew (recomendado)
brew install go@1.24

# Binario oficial
wget https://go.dev/dl/go1.24.2.darwin-amd64.tar.gz
sudo tar -C /usr/local -xzf go1.24.2.darwin-amd64.tar.gz

Windows

1. Descarga el instalador MSI desde go.dev/dl
2. El instalador añade Go al PATH automáticamente
3. Verifica en PowerShell: go version
4. Alternativa vía winget: winget install GoLang.Go

gvm (Go Version Manager) — múltiples versiones

bash < <(curl -sSL https://raw.githubusercontent.com/moovweb/gvm/master/binscripts/gvm-installer)
source ~/.gvm/scripts/gvm

gvm install go1.24.2
gvm install go1.23.6
gvm use go1.24.2 --default

Docker multi-stage (producción)

# Build stage
FROM golang:1.24-alpine AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -o /app/server .

# Runtime stage — imagen mínima
FROM scratch
COPY --from=builder /app/server /server
EXPOSE 8080
CMD ["/server"]

Usa golang:1.24-alpine para build (~350 MB) y scratch o distroless para runtime (~5 MB). CGO_ENABLED=0 produce binarios estáticos que funcionan en cualquier Linux sin dependencias.

Alias útiles para el día a día

Añade a tu ~/.bashrc o ~/.zshrc:

alias grun='go run .'
alias gtest='go test -v ./...'
alias gmod='go mod tidy'
alias gbuild='go build -o bin/ ./...'
alias gfmt='gofmt -l -w .'
alias gvet='go vet ./...'
alias gall='go fmt ./... && go vet ./... && go mod tidy'

Fuente: Go dev — Download, gvm GitHub, Docker Official Images — Golang

Escala de aprendizaje: de 0 a 100

Cada nivel incluye lo que debes saber y un proyecto para fijar los conceptos. Las secciones nuevas de esta guía (Paradigmas, Tipos de datos, Control de flujo, Sistema de archivos, Algoritmos, Multimedia) se integran en los niveles según su dificultad conceptual.

Nivel 0–15: Fundamentos absolutos

Qué aprender:

• Sintaxis básica: package main, func main(), import, fmt.Println
• Variables: var, :=, tipos básicos (string, int, float64, bool)
• Control de flujo: if, else, for (único bucle), switch — ver sección Control de flujo y modularidad
• Funciones: func, parámetros, valores de retorno múltiples
• Zero values: Go inicializa todo a cero/nil automáticamente
• fmt.Printf() con %s, %d, %v, %+v, %T
• Conceptos clave: Go es compilado — necesitas go build o go run. Tipado estático: no puedes sumar int y float64 sin convertir. Las llaves { van en la misma línea que la declaración (gofmt no da opción). Variables no usadas = error de compilación.

Proyecto: Adivina el número — el programa elige un número aleatorio entre 1 y 100 (rand.Intn), el usuario intenta adivinarlo con pistas “mayor/menor”. Contador de intentos. Manejo de entrada con fmt.Scanf o bufio.Scanner. Reflexión: ¿por qué Go fuerza a manejar el error de Scanf aunque no te importe? (no hay excepciones, los errores son valores)

Nivel 15–30: Structs, slices, maps y punteros

Qué aprender:

• Slices: make([]int, 5), append, slicing[:3], copy — ver sección Tipos de datos y variables
• Maps: make(map[string]int), mapeo["key"], comprobar existencia
• Structs: type Usuario struct, campos, literales
• Punteros: *T, &, cuándo pasar puntero vs valor
• Métodos: receiver value vs pointer
• Strings: strings.Split, strings.Join, strconv.Atoi, fmt.Sprintf
• Archivos: os.Open, os.ReadFile, bufio.Scanner, io.Copy — ver sección Sistema de archivos
• defer para cleanup — ver sección Control de flujo y modularidad
• Algoritmos básicos: sort.Slice, slices.Sort, container/list — ver sección Algoritmos
• Conceptos clave: un slice NO tiene datos, es un descriptor (puntero, longitud, capacidad). append puede reasignar el slice si no cabe. Los maps devuelven zero value si la clave no existe — usa val, ok := m["key"]. Los strings son inmutables y UTF-8. range sobre slice devuelve índice y valor, sobre map devuelve clave y valor (orden aleatorio).

Proyecto: Gestor de tareas CLI — añadir (add "Comprar leche"), listar (list), completar (done 3), eliminar (rm 3). Persistencia en JSON (encoding/json). Usa flag para los comandos. Struct Tarea con ID, Texto, Hecho. Slice de tareas. Punteros para modificar tareas existentes.

Nivel 30–45: Interfaces, errores y paquetes

Qué aprender:

• Interfaces: definición, implementación implícita, io.Reader/io.Writer
• Type assertions y type switches
• Errores: error interface, fmt.Errorf, errors.Is, errors.As, errores personalizados
• Paquetes: exportación pública/privada, internal, go.mod — ver sección Control de flujo y modularidad
• Embedding de structs (composición) — ver sección Paradigmas
• init() functions
• encoding/json: marshal/unmarshal structs, tags json:
• Paradigmas en acción: POO sin clases (structs + métodos + interfaces), funcional parcial (closures, funciones como valores) — ver sección Paradigmas
• Conceptos clave: una interfaz es un tipo (valor + type descriptor). nil en una interfaz no es lo mismo que un puntero nil. La interfaz vacía interface{} (o any) es el “tope” del sistema de tipos. Go no tiene try/catch — cada error se maneja explícitamente. Las interfaces pequeñas (1 método) son la norma.

Proyecto: Sistema de inventario — tipos Producto, Inventario (map[string]*Producto). Interfaz Almacenable con métodos Guardar(), Cargar(). Implementación con JSON y otra con SQLite. Errores personalizados (ProductoNoExiste, StockInsuficiente). Embedding para ProductoFisico y ProductoDigital. Tests con table-driven tests.

Nivel 45–60: Testing, módulos y librerías estándar

Qué aprender:

• go test: _test.go, t.Run, table-driven tests, t.Helper
• go test -bench benchmarks
• go test -race detector de data races
• go mod, go mod tidy, go get, versionado semántico
• net/http: handlers, http.HandlerFunc, http.ServeMux, middleware
• context.Context: WithCancel, WithTimeout, WithDeadline, WithValue
• time: time.Now, time.After, time.Ticker, time.Sleep
• sync: WaitGroup, Mutex, RWMutex, Once
• Conceptos clave: los tests se colocan en el mismo paquete o en _test (black-box testing). El race detector es obligatorio en cualquier código concurrente. context.Background() es la raíz, context.TODO() marca pendiente, nunca almacenes context en structs. Los middlewares HTTP son funciones que envuelven un http.Handler.

Proyecto: API de recetas con net/http — servidor HTTP sin frameworks. Rutas /recetas (GET), /recetas/{id} (GET), /recetas (POST). Mux manual con http.ServeMux. Middleware de logging y CORS. Tests con httptest.NewRecorder. Context para timeouts. Mutex para acceso concurrente al slice de recetas.

Nivel 60–75: Frameworks web y bases de datos

Qué aprender:

• Gin, Echo o Chi para APIs REST
• GORM o sqlx para bases de datos
• Migraciones con golang-migrate
• Validación de datos (struct tags, validator)
• JWT: autenticación middleware
• Variables de entorno: os.Getenv, godotenv o viper
• slog (Go 1.21+): log estructurado nativo
• Conceptos clave: los frameworks Go son más finos que Django/FastAPI — no hay tanto magic. El tipado estático evita muchas clases de bugs. Los handlers reciben *gin.Context o echo.Context que unifican request/response. La inyección de dependencias se hace a mano (funciones que reciben dependencias como parámetros).

Proyecto: API de recetas con Gin + PostgreSQL — endpoints CRUD para recetas e ingredientes. GORM para ORM, golang-migrate para migraciones. Autenticación JWT. Búsqueda por ingrediente con SQL parametrizado. Tests con BD de prueba en memoria (SQLite para tests, PostgreSQL en producción). slog para logging estructurado.

Nivel 75–90: Concurrencia avanzada y producción

Qué aprender:

• Worker pools con errgroup
• Rate limiting con golang.org/x/time/rate
• Graceful shutdown de servidores HTTP
• Docker multi-stage para Go
• CI/CD: GitHub Actions con go build, go test, golangci-lint
• Redis: caché de endpoints, rate limiting, sesiones
• Pruebas de integración con testcontainers-go
• Profiling: pprof, trace, memory profiling
• Conceptos clave: signal.NotifyContext para graceful shutdown. errgroup para cancelar todas las goroutines si una falla. sync.WaitGroup + canales = worker pool. El binario estático de Go simplifica Docker enormemente (scratch image de ~10 MB). GOMAXPROCS por defecto = todos los cores.

Proyecto: Worker de procesamiento de imágenes — API que acepta URLs de imágenes, las encola en Redis, workers las procesan concurrentemente. errgroup para control de errores. Rate limiting por usuario. Graceful shutdown que espera a workers terminar. Docker multi-stage (imagen final ~15 MB). CI con golangci-lint, tests, race detector.

Nivel 90–100: Arquitectura y sistemas distribuidos

Qué aprender:

• gRPC: protobuf, servidores y clientes, streaming bidireccional
• Kafka: segmentio/kafka-go o confluent-kafka-go
• Arquitectura hexagonal / clean architecture en Go
• OpenTelemetry: tracing distribuido, métricas
• Fuzzing con go test -fuzz
• Go generics avanzados: constraints, type inference, patterns
• Plugins con plugin package o WASM
• Conceptos clave: gRPC es el protocolo RPC estándar en Go — Google lo usa internamente. Protobuf es más eficiente que JSON pero menos legible. Kafka ofrece garantías de entrega (at-least-once, exactly-once). Las arquitecturas hexagonales se implementan con interfaces: dominio puro, adaptadores de infraestructura. Los genéricos permiten librerías de colecciones, pipelines, y DSLs internos sin reflection.

Proyecto: Sistema de notificaciones distribuidas — microservicios con gRPC para comunicación interna. Kafka como event bus (servicio usuarios → servicio notificaciones → servicio email). OpenTelemetry para tracing. Arquitectura hexagonal: dominio (Notificacion, Usuario), puertos (interfaces), adaptadores (Kafka, gRPC, SMTP). Docker Compose con todos los servicios. Fuzzing en la validación de entrada.

Fuente: Go dev — doc, Gin docs, GORM docs, gRPC Go docs

Primeros pasos y configuración del entorno

Si prefieres ver directamente el “Hola Mundo” en Go, consulta El Atlas del Hola Mundo.

Estructura de proyecto con módulos

Go moderno usa módulos (go mod). El GOPATH es cosa del pasado desde Go 1.16.

# Inicializar un módulo
go mod init github.com/tu-usuario/mi-proyecto

# Añadir dependencias
go get github.com/gin-gonic/gin

# Limpiar dependencias no usadas
go mod tidy

Resultado: archivos go.mod (módulos y versiones) y go.sum (checksums de seguridad).

Hola Mundo

package main

import "fmt"

func main() {
    fmt.Println("Hola Mundo")
}

Ejecuta: go run main.go o go run . (todo el paquete).

Compilación

go build -o mi-programa .         # Binario para tu arquitectura
GOOS=linux GOARCH=amd64 go build  # Cross-compile para Linux
GOOS=windows GOARCH=amd64 go build  # Cross-compile para Windows

Go produce binarios estáticos: no necesitas runtime, ni JVM, ni nada. Copias el binario y funciona.

Herramientas del lenguaje

go fmt ./...      # Formatea todo el código (indentación, alineación)
go vet ./...      # Analiza bugs sospechosos (variable no usada, etc.)
go mod tidy       # Limpia go.mod y go.sum
go doc fmt.Println  # Documentación desde terminal
go env            # Variables de entorno del toolchain
go list ./...     # Lista todos los paquetes del módulo

Editores recomendados

Los IDEs y editores más usados son VSCode, JetBrains y Neovim. Extensiones y configuraciones recomendadas.

GOPATH vs módulos

Desde Go 1.16, GO111MODULE=on es el comportamiento por defecto. Si ves tutoriales que hablan de GOPATH, son anteriores a 2020.

Fuente: Go dev — Getting Started, Go dev — Modules, gopls

Paradigmas de programación en Go

Go es un lenguaje multiparadigma que combina lo mejor de varios mundos sin llegar a ser extremo en ninguno.

Imperativo / Procedural

El núcleo de Go es imperativo: el programa se ejecuta secuencialmente, instrucción tras instrucción.

func main() {
    var sum int
    for i := 1; i <= 10; i++ {
        sum += i
    }
    fmt.Println("Suma:", sum)
}

Concurrente (el paradigma estrella)

Go está diseñado desde sus cimientos para la concurrencia. Goroutines y canales son el modelo de comunicación entre tareas concurrentes, inspirado en los Communicating Sequential Processes (CSP) de Hoare.

func main() {
    ch := make(chan string)
    go func() {
        ch <- "Hola desde goroutine"
    }()
    fmt.Println(<-ch)
}

La filosofía de Go: “Do not communicate by sharing memory; instead, share memory by communicating.”

POO sin clases

Go no tiene clases ni herencia. En su lugar ofrece:

• Structs para definir tipos compuestos
• Métodos con receptores explícitos
• Interfaces implícitas (duck typing en tiempo de compilación)
• Embedding (composición sobre herencia)

type Animal struct{ Nombre string }
func (a Animal) Saludar() string { return "Soy " + a.Nombre }

type Perro struct{ Animal }
func (p Perro) Saludar() string { return "Guau, soy " + p.Nombre }

Funcional parcial

Go soporta programación funcional de forma limitada:

• First-class functions: las funciones son valores
• Closures: funciones que capturan variables del ámbito exterior
• Funciones como parámetros y retorno

func mapSlice(f func(int) int, nums []int) []int {
    result := make([]int, len(nums))
    for i, n := range nums {
        result[i] = f(n)
    }
    return result
}

func main() {
    doble := func(x int) int { return x * 2 }
    fmt.Println(mapSlice(doble, []int{1, 2, 3})) // [2, 4, 6]
}

Limitaciones: no hay genéricos hasta Go 1.18; no hay map/filter/reduce nativos en la stdlib; no hay tuplas; no hay pattern matching. La stdlib tiene slices y maps desde Go 1.21 con funciones utilitarias.

Lo que Go NO tiene

Fuente: Effective Go, Go FAQ, Rob Pike — Go at Google, Concurrency is not Parallelism (Rob Pike)

Tipos de datos y variables

Tipos built-in y zero values

¿Qué es?

Go tiene un conjunto pequeño de tipos built-in: booleanos, enteros (con/sin signo), flotantes, complejos y string. Todos tienen zero values automáticos sin necesidad de inicialización. Go no tiene null, solo nil para ciertos tipos.

🔗 Go dev — Spec types

Sintaxis básica

// Tipos built-in
var activo bool          // false
var edad int             // 0 (32 o 64 bits según arquitectura)
var peso float64         // 0.0
var nombre string        // ""
var puntero *int         // nil
var lista []string       // nil
var mapa map[string]int  // nil
var canal chan int       // nil

// byte y rune son alias
var b byte = 255         // uint8
var r rune = '世'         // int32 (code point Unicode)

// Zero values: no puedes usar variable sin inicializar
var s string
fmt.Println(s)           // "" (vacío, no panic)

🧪 Cómo probarlo

func TestZeroValues(t *testing.T) {
    var s string
    var i int
    var b bool
    if s != "" { t.Error("string zero value should be empty") }
    if i != 0 { t.Error("int zero value should be 0") }
    if b != false { t.Error("bool zero value should be false") }
}

💡 Memoria y rendimiento

• int/uint son tamaño de palabra nativa (64 bits en x86-64) — óptimo para la CPU
• byte y rune ocupan 1 y 4 bytes respectivamente
• string es un descriptor de 16 bytes (puntero + longitud) — el contenido está en heap
• nil en slices/maps/channels evita alocar hasta que se usan

✅ Buenas prácticas

• ✅ Usa int por defecto para enteros (no int8/int16 a menos que ahorres memoria)
• ✅ Usa float64 por defecto para flotantes
• ⚠️ No confundas byte (uint8) con rune (int32)
• ❌ No accedas a campos de un *struct que es nil — panic

🏗️ Metodología

• APIs: usa int y float64 para valores numéricos
• Serialización: int/float64 están optimizados en encoding/json
• Juegos/embebido: usa int8/int16/float32 para ahorrar memoria

🔗 Para saber más

• Go dev — Zero value

Declaración de variables e inferencia

¿Qué es?

Go soporta var (explícito, ámbito global o local) y := (corto, solo dentro de funciones). La inferencia de tipos siempre elige el tipo por defecto según el valor.

🔗 Go dev — Spec variables

Sintaxis básica

// Declaración explícita
var nombre string = "Ana"
var edad = 30  // inferido: int

// Short declaration (solo dentro de funciones)
nombre := "Ana"
edad := 30

// Múltiples variables
var x, y int = 1, 2
a, b := "hola", 42

// La inferencia elige tipos por defecto
var x = 42       // int
var y = 3.14     // float64
var z = 3 + 4i   // complex128

🧪 Cómo probarlo

func TestTypeInference(t *testing.T) {
    x := 42
    y := 3.14
    if fmt.Sprintf("%T", x) != "int" { t.Error("42 should be int") }
    if fmt.Sprintf("%T", y) != "float64" { t.Error("3.14 should be float64") }
}

✅ Buenas prácticas

• ✅ Usa := dentro de funciones para código conciso
• ✅ Usa var para valores zero explícitos (var i int)
• ⚠️ No uses := fuera de funciones — no compila
• ❌ No declares variables que no usas — error de compilación

Conversión explícita y tipos compuestos

¿Qué es?

Go no convierte implícitamente entre tipos. Incluso entre int y int32 necesitas cast explícito. Los tipos compuestos incluyen struct, array, slice, map, punteros, any y error.

🔗 Go dev — Conversions

Sintaxis básica

// Conversión explícita
var a int = 42
var b int32 = int32(a)
var c float64 = float64(a)
var d string = strconv.Itoa(a)  // int → string requiere strconv

// Struct
type Punto struct { X, Y float64 }
p := Punto{X: 3.0, Y: 4.0}

// Array (tamaño fijo) vs Slice (dinámico)
arr := [3]int{1, 2, 3}    // array fijo
sl := []int{1, 2, 3}      // slice dinámico
sl = append(sl, 4)

// Map
m := make(map[string]int)
m["clave"] = 42
val, ok := m["clave"]

// Punteros (sin aritmética)
var x int = 42
var p *int = &x
*p = 100  // modifica x

// any (interface{} genérico)
var v any = 42
v = "texto"

// error es una interfaz
type error interface { Error() string }

🧪 Cómo probarlo

func TestMapOk(t *testing.T) {
    m := map[string]int{"a": 1}
    v, ok := m["a"]
    if !ok { t.Error("key should exist") }
    if v != 1 { t.Error("value should be 1") }
}

func TestNilSlice(t *testing.T) {
    var s []int
    // nil slice: append funciona sin panic
    s = append(s, 1)
    if len(s) != 1 { t.Error("append should work on nil slice") }
}

💡 Memoria y rendimiento

• Structs son value types — se copian al asignar o pasar por parámetro
• Slice es un descriptor de 24 bytes (ptr + len + cap) — el array subyacente está en heap
• Map es un puntero a una tabla hash interna — pasarlo es barato
• any implica boxing para value types (como interface en C#/Java)

✅ Buenas prácticas

• ✅ Usa make() para maps y slices con capacidad inicial conocida
• ✅ Usa structs por puntero solo si necesitas mutación o el struct es grande (>64 bytes)
• ⚠️ No uses any a menos que sea estrictamente necesario — pierdes type safety
• ❌ No compares slices directamente con == (solo con nil) — usa reflect.DeepEqual o slices.Equal

🏗️ Metodología

• Datos inmutables: structs por valor
• Colecciones dinámicas: slices (no arrays de tamaño fijo)
• Lookups: maps con ok idiom
• Errores: siempre devuelve error como último valor

🔗 Para saber más

• Go dev — Effective Go

Strings (UTF-8)

¿Qué es?

Los strings en Go son inmutables y contienen UTF-8 (no ASCII). len(s) devuelve bytes, no caracteres. string es un slice de bytes de solo lectura.

🔗 Go dev — Strings

Sintaxis básica

s := "Hello, 世界"
fmt.Println(len(s))                    // 13 bytes
fmt.Println(utf8.RuneCountInString(s)) // 9 runas (caracteres)

// Convertir a bytes o runas
b := []byte(s)  // cada byte
r := []rune(s)  // cada code point Unicode

// Iteración correcta
for i, r := range s {
    fmt.Printf("%d: %c\n", i, r)  // i es offset en bytes
}

🧪 Cómo probarlo

func TestStringUTF8(t *testing.T) {
    s := "Hello, 世界"
    if len(s) != 13 { t.Error("len should be bytes, not chars") }
    if utf8.RuneCountInString(s) != 9 { t.Error("should be 9 runes") }
}

✅ Buenas prácticas

• ✅ Usa range para iterar strings (itera por runa, no por byte)
• ✅ Usa strings.Builder para concatenación en bucles
• ⚠️ No asumas que un carácter = 1 byte — UTF-8 es variable
• ❌ No modifiques un string directamente — son inmutables

Memoria: stack vs heap y GC

¿Qué es?

Go tiene escape analysis en compilación: decide si una variable va al stack o al heap. El GC es concurrente, no generacional, con pausas típicas <1ms desde Go 1.8.

🔗 Go dev — GC Guide

Sintaxis básica

// Stack: la variable no escapa
func enStack() int {
    x := 42
    return x
}

// Heap: la variable escapa (se referencia fuera)
func enHeap() *int {
    x := 42
    return &x
}

// Ver decisiones del compilador
// go build -gcflags='-m' ./...

💡 Memoria y rendimiento

• Escape analysis decide stack vs heap — no hay control manual como en C/C++
• El GC es concurrente (mark-sweep) con pausas de <1ms típicamente
• Pasar structs por puntero no siempre es más rápido — los structs pequeños pueden ser más rápidos por valor
• sync.Pool reusa objetos para reducir presión de GC

✅ Buenas prácticas

• ✅ Prefiere devolver valores por valor (no punteros) a menos que necesites mutación
• ✅ Usa -gcflags='-m' para diagnosticar fugas al heap inesperadas
• ⚠️ No obsesiones con stack vs heap — el compilador optimiza bien
• ❌ No uses punteros para “ahorrar memoria” en structs pequeños — suele ser peor

🔗 Para saber más

• Go dev — Escape analysis

Control de flujo, modularidad y funciones

Control de flujo

¿Qué es?

Go tiene if, switch, for (único bucle), defer (ejecución diferida al salir del ámbito) y panic/recover (sin try/catch). El switch no tiene fallthrough por defecto.

🔗 Go dev — Control flow

Sintaxis básica

// if con short statement
if err := f(); err != nil {
    return err
}

// switch sin expresión (if/else if)
switch {
case nota >= 9: fmt.Println("sobresaliente")
case nota >= 7: fmt.Println("notable")
default: fmt.Println("aprobado o suspenso")
}

// for — único bucle, 3 formas
for i := 0; i < 10; i++ { fmt.Println(i) }
for x < 100 { x *= 2 }                          // como while
for i, v := range []int{10, 20, 30} { }         // range sobre slice/map/chan/string

// defer — LIFO, se ejecuta al salir del ámbito
f, _ := os.Open("archivo.txt")
defer f.Close()

// panic / recover (sin try/catch)
defer func() {
    if r := recover(); r != nil { fmt.Println("panic:", r) }
}()
panic("algo terrible")

🧪 Cómo probarlo

func TestSwitchSinExpresion(t *testing.T) {
    nota := 85
    resultado := ""
    switch {
    case nota >= 90: resultado = "sobresaliente"
    case nota >= 70: resultado = "notable"
    case nota >= 50: resultado = "aprobado"
    default: resultado = "suspenso"
    }
    if resultado != "notable" {
        t.Errorf("esperado notable, got %s", resultado)
    }
}

func TestDeferEjecutaAlFinal(t *testing.T) {
    resultado := ""
    func() {
        defer func() { resultado += "mundo" }()
        resultado += "hola "
    }()
    if resultado != "hola mundo" {
        t.Errorf("esperado 'hola mundo', got %s", resultado)
    }
}

💡 Memoria y rendimiento

• defer tiene overhead mínimo (~50ns) — usa el patrón de cleanup siempre
• for range sobre slices es tan rápido como indexación manual
• switch compila a jump table cuando los casos son constantes
• panic/recover no deben usarse para flujo normal — son costosos

✅ Buenas prácticas

• ✅ Usa defer para todo cleanup (cerrar archivos, unlock mutex, cerrar BD)
• ✅ Usa for range para iterar slices, maps, canales y strings
• ⚠️ No uses panic para errores ordinarios — usa error
• ❌ No abuses de recover — solo en servidores HTTP para evitar caídas

🏗️ Metodología

• Errores predecibles: if err != nil idiom
• Errores irrecuperables: log.Fatal en main, panic en init
• Cleanup: siempre defer inmediatamente después de abrir recurso
• Múltiples condiciones: switch sin expresión (más legible que if/else if)

🔗 Para saber más

• Go dev — Effective Go: defer

Funciones

¿Qué es?

Las funciones en Go soportan múltiples retornos, valores nombrados, parámetros variádicos y closures. No hay sobrecarga ni parámetros con nombre.

🔗 Go dev — Spec functions

Sintaxis básica

// Múltiples retornos
func dividir(a, b float64) (float64, error) {
    if b == 0 { return 0, fmt.Errorf("división por cero") }
    return a / b, nil
}

// Retorno nombrado
func dividir(a, b float64) (result float64, err error) {
    if b == 0 { err = fmt.Errorf("división por cero"); return }
    result = a / b
    return
}

// Variádica
func sumar(nums ...int) int {
    total := 0
    for _, n := range nums { total += n }
    return total
}

🧪 Cómo probarlo

func TestMultiplesRetornos(t *testing.T) {
    _, err := dividir(10, 0)
    if err == nil { t.Error("esperaba error") }
}

func TestFuncionVariadica(t *testing.T) {
    if sumar(1, 2, 3) != 6 { t.Error("1+2+3 should be 6") }
}

✅ Buenas prácticas

• ✅ Usa retornos nombrados para documentar el propósito de cada valor
• ✅ Devuelve error como último valor de retorno
• ⚠️ No hagas sobrecarga de funciones — Go no lo soporta
• ❌ No ignores errores con _ sin pensar

Módulos y paquetes

¿Qué es?

Go organiza el código en paquetes (directorios). Cada archivo .go pertenece a un paquete. Un módulo es la unidad de versionado definida en go.mod. La exportación se controla por mayúscula/minúscula.

🔗 Go dev — Modules

Sintaxis básica

package usuario

type Usuario struct {   // exportado (mayúscula)
    Nombre string        // exportado
    email  string        // privado (minúscula)
}

func NuevoUsuario(nombre, email string) *Usuario {  // exportado
    return &Usuario{Nombre: nombre, email: email}
}

go mod init github.com/usuario/proyecto
go get github.com/gin-gonic/gin
go mod tidy

Internal packages (internal/) restringen importación al árbol padre del módulo. init() se ejecuta automáticamente al cargar el paquete.

🧪 Cómo probarlo

func TestExportacion(t *testing.T) {
    u := NuevoUsuario("Ana", "ana@test.com")
    if u.Nombre != "Ana" { t.Error("Nombre debería ser exportado") }
}

✅ Buenas prácticas

• ✅ Nombra paquetes en singular y cortos (user, no users o user_utils)
• ✅ Usa internal/ para código que no debe exponerse al exterior del módulo
• ⚠️ No uses init() para lógica que podría hacerse explícita
• ❌ No crees paquetes con nombres genéricos como utils o common

🔗 Para saber más

• Go dev — Package names

Conceptos clave explicados a fondo

Paquetes y exportación

¿Qué es?

Un paquete en Go es la unidad básica de organización del código. Todo archivo .go pertenece a un paquete. La visibilidad se controla por mayúscula (exportado) o minúscula (privado). Es como un archivador: cada cajón (paquete) tiene documentos, y solo los que tienen el nombre en mayúscula pueden verse desde fuera.

🔗 Go dev — Package reference

Sintaxis básica

package models   // El directorio se llama models/, el paquete se llama models

// Exportado: empieza con mayúscula — visible fuera del paquete
type Usuario struct {
    Nombre string  // Exportado
    email  string  // No exportado (privado al paquete)
}

// No exportado: solo visible dentro del paquete
func validarEmail(e string) bool {
    return strings.Contains(e, "@")
}

// Exportado
func NuevoUsuario(nombre, email string) *Usuario {
    return &Usuario{Nombre: nombre, email: email}
}

Convenciones:

• package main → genera un ejecutable con func main()
• Cualquier otro nombre → librería
• El nombre del paquete coincide con el último segmento del directorio (models/models.go)
• El directorio internal/ es especial: sus paquetes solo son importables por el árbol padre

El directorio internal:

// project/api/handler.go
import "project/internal/crypto"
// ✅ permitido — internal/ está dentro de project/

// otro-project/main.go
import "project/internal/crypto"
// ❌ error de compilación — internal/ no es accesible desde fuera

internal es el mecanismo de Go para crear APIs privadas dentro de un módulo. No hay private como en otros lenguajes: internal es la barrera de visibilidad entre módulos.

🧪 Cómo probarlo

func TestExportacion(t *testing.T) {
    // Probar acceso a símbolos exportados
    u := NuevoUsuario("Ana", "ana@test.com")
    if u.Nombre != "Ana" {
        t.Errorf("Nombre debería ser 'Ana', got %s", u.Nombre)
    }
    // email es privado — no se puede acceder desde otro paquete
}

💡 Memoria y rendimiento

• Los paquetes se cargan una sola vez en go.mod y se cachean
• internal no tiene overhead en runtime — solo es una restricción de compilación
• Los import cíclicos se detectan en compilación — no pueden ocurrir en runtime
• El paquete main no es importable por otros paquetes

✅ Buenas prácticas

• ✅ Nombra paquetes en singular y cortos (user, no users o user_utils)
• ✅ Usa internal/ para código que no debe exponerse al exterior del módulo
• ⚠️ No uses init() para lógica que podría hacerse explícita
• ❌ No crees paquetes con nombres genéricos como utils o common

🏗️ Metodología

• APIs públicas: solo exporta lo que el usuario necesita, todo lo demás privado
• Módulos grandes: divide en subpaquetes, usa internal/ para implementación
• Librerías: paquete raíz con API pública, subpaquetes con implementación
• Ejecutables: package main mínimo que delega en otros paquetes

🔗 Para saber más

• Go dev — Package names
• Go dev — Internal packages
• Go dev — Modules

Variables, tipos y zero values

¿Qué es?

Go es de tipado estático con inferencia de tipos mediante :=. Toda variable tiene un tipo conocido en compilación y un zero value automático (no hay null o undefined). Es como una taquilla numerada: sabes exactamente qué tamaño tiene cada compartimento y siempre está limpio aunque no metas nada.

🔗 Go dev — Variables

Sintaxis básica

// Declaración explícita
var nombre string = "Ana"
var edad int = 30
var activo bool = true

// Inferencia (short declaration — solo dentro de funciones)
nombre := "Ana"
edad := 30

// Zero values — Go inicializa todo a cero automáticamente
var s string    // "" (cadena vacía)
var i int       // 0
var f float64   // 0.0
var b bool      // false
var p *int      // nil (punteros, slices, maps, canales, interfaces)
var sl []string // nil
var m map[string]int // nil

// Múltiples variables
var x, y int = 1, 2
a, b := "hola", 42

// Tipos básicos
var entero int8     // -128 a 127
var entero32 int32  // -2^31 a 2^31-1
var entero64 int64  // -2^63 a 2^63-1
var sinSigno uint   // 0 a 2^64-1 (según arquitectura)
var decimal float32 // ~6 dígitos precisión
var decimal64 float64 // ~15 dígitos precisión
var texto string    // UTF-8, inmutable
var caracter rune   // alias de int32, representa un code point Unicode
var byte byte       // alias de uint8
var comaComplejo complex128 // números complejos

Conversiones explícitas — no hay coerciones automáticas:

var i int = 42
var f float64 = float64(i)   // ✅ explícita
var u uint = uint(f)          // ✅ explícita (pierde decimales)

// ❌ Esto no compila: Go no convierte implícitamente
// var f float64 = i

Incluso entre tipos numéricos del mismo tamaño, debes convertir explícitamente. Go prefiere la seguridad a la conveniencia.

iota — enumeradores automáticos:

type Estado int

const (
    Pendiente Estado = iota // 0
    Activo                  // 1
    Inactivo                // 2
    Archivado               // 3
)

type Permiso int

const (
    Leer Permiso = 1 << iota // 1 (1 << 0)
    Escribir                 // 2 (1 << 1)
    Ejecutar                 // 4 (1 << 2)
)

🧪 Cómo probarlo

func TestZeroValues(t *testing.T) {
    var s string
    var i int
    var b bool
    var p *int
    if s != "" { t.Error("string zero value debe ser vacío") }
    if i != 0 { t.Error("int zero value debe ser 0") }
    if b != false { t.Error("bool zero value debe ser false") }
    if p != nil { t.Error("pointer zero value debe ser nil") }
}

func TestIota(t *testing.T) {
    const (
        A = iota
        B
        C
    )
    if A != 0 || B != 1 || C != 2 {
        t.Errorf("iota esperado 0,1,2, got %d,%d,%d", A, B, C)
    }
}

func TestConversionExplicita(t *testing.T) {
    var a int = 42
    var b float64 = float64(a)
    if b != 42.0 { t.Errorf("esperado 42.0, got %f", b) }
}

💡 Memoria y rendimiento

• int es tamaño de palabra nativa (64 bits en x86-64) — óptimo para la CPU
• byte y rune ocupan 1 y 4 bytes respectivamente
• string es un descriptor de 16 bytes (puntero + longitud) — contenido en heap
• nil en slices/maps/channels evita alocar hasta que se usan
• iota se evalúa en compilación — zero overhead en runtime

✅ Buenas prácticas

• ✅ Usa := dentro de funciones para código conciso
• ✅ Usa var para valores zero explícitos (var i int)
• ⚠️ No confundas byte (uint8) con rune (int32)
• ❌ No declares variables que no usas — error de compilación

🏗️ Metodología

• Valores por defecto: Go inicializa a cero — no necesitas constructor
• Conversión: siempre explícita — Go prioriza seguridad sobre conveniencia
• Enumeraciones: iota para secuencias, bitsets con 1 << iota
• APIs: usa int y float64 para valores numéricos genéricos

🔗 Para saber más

• Go dev — iota
• Go dev — The zero value
• Go dev — Short declaration

Structs, métodos y embedding

¿Qué es?

Los structs son la forma de Go de definir tipos compuestos. No hay clases. Los métodos son funciones con un receptor explícito (value o pointer). El embedding permite componer structs dentro de otros, promocionando sus campos y métodos. Es como una mochila modular: en vez de heredar una mochila entera, acoplas los compartimentos que necesitas.

🔗 Go dev — Structs

Sintaxis básica

type Direccion struct {
    Calle   string
    Ciudad string
    CP      string
}

type Usuario struct {
    Nombre    string
    Email     string
    Edad      int
    Direccion Direccion // composición: Usuario "tiene una" Direccion
    activo    bool      // campo privado al paquete
}

Métodos — funciones con receptor (receiver):

// Receptor por valor
func (u Usuario) Saludar() string {
    return "Hola, soy " + u.Nombre
}

// Receptor por puntero — puede modificar el struct
func (u *Usuario) Activar() {
    u.activo = true
}

// Convención: si un método tiene receptor puntero, todos deben tenerlo
func (u *Usuario) CambiarEmail(email string) {
    u.Email = email
}

Embedding — composición sobre herencia:

type Animal struct {
    Nombre string
}

func (a Animal) Sonido() string {
    return "..."
}

// Perro "extiende" Animal via embedding
type Perro struct {
    Animal          // embedding (sin nombre de campo)
    Raza string
}

// Override: Perro sobreescribe Sonido
func (p Perro) Sonido() string {
    return "Guau"
}

// Uso
p := Perro{Animal: Animal{Nombre: "Max"}, Raza: "Labrador"}
fmt.Println(p.Nombre)    // "Max" — campo promovido desde Animal
fmt.Println(p.Sonido())  // "Guau" — propio
fmt.Println(p.Animal.Sonido()) // "..." — acceso directo al embedido

El embedding NO es herencia. No hay polimorfismo de subtipos. Perro no es un Animal. Pero los métodos y campos del struct embebido se “promocionan” al struct contenedor. Es composición con sintaxis conveniente.

Tags de struct (metadata para serialización/validación):

type Usuario struct {
    ID        int       `json:"id" db:"id" validate:"required"`
    Nombre    string    `json:"nombre" validate:"min=2,max=100"`
    Email     string    `json:"email" validate:"email"`
    CreatedAt time.Time `json:"created_at" db:"created_at"`
}

Las tags son strings que las librerías interpretan via reflect. encoding/json, database/sql, validator las usan.

🧪 Cómo probarlo

func TestMetodoValorVsPuntero(t *testing.T) {
    u := Usuario{Nombre: "Ana"}
    if u.Saludar() != "Hola, soy Ana" {
        t.Errorf("saludo incorrecto: %s", u.Saludar())
    }
    u.Activar()
    // activo es privado — no podemos acceder directamente
}

func TestEmbedding(t *testing.T) {
    p := Perro{Animal: Animal{Nombre: "Max"}, Raza: "Labrador"}
    if p.Nombre != "Max" { t.Errorf("esperado Max, got %s", p.Nombre) }
    if p.Sonido() != "Guau" { t.Errorf("esperado Guau, got %s", p.Sonido()) }
}

💡 Memoria y rendimiento

• Structs son value types — se copian al asignar o pasar por parámetro
• Métodos con value receiver reciben una copia — seguros pero más caros para structs grandes
• Métodos con pointer receiver reciben el original — eficientes pero permiten mutación
• Embedding no añade overhead — es solo promoción de campos en compilación
• Tags son strings guardadas como metadata en tiempo de compilación

✅ Buenas prácticas

• ✅ Usa pointer receiver si el método modifica el struct
• ✅ Usa value receiver si el método no modifica y el struct es pequeño (<64 bytes)
• ⚠️ Embedding no es herencia — no esperes polimorfismo de subtipos
• ❌ No abuses de tags para lógica de negocio — son metadata, no validadores

🏗️ Metodología

• DTOs: structs con tags json:"..." para serialización
• Entidades: structs con métodos de negocio (pointer receiver)
• Composición: embedding para reutilizar comportamiento
• Configuración: structs con tags yaml/env para configuración

🔗 Para saber más

• Go dev — Methods
• Go dev — Effective Go: Embedding
• Go dev — Struct tags

Interfaces (duck typing estructural)

¿Qué es?

Las interfaces en Go son implícitas y estructurales: no necesitas declarar que implementas una — si tienes los métodos, la implementas. Es como un enchufe universal: cualquier cable que tenga la clavija adecuada funciona, sin importar la marca.

🔗 Go dev — Interfaces

Sintaxis básica

// Definición de interfaz
type Saludador interface {
    Saludar() string
}

// Perro implementa Saludador implícitamente
type Perro struct{ Nombre string }
func (p Perro) Saludar() string {
    return "Guau, soy " + p.Nombre
}

// Gato también
type Gato struct{ Nombre string }
func (g Gato) Saludar() string {
    return "Miau, soy " + g.Nombre
}

// Función polimórfica
func Festejar(s Saludador) {
    fmt.Println(s.Saludar() + "! 🎉")
}

// Uso
Festejar(Perro{Nombre: "Max"})  // Guau, soy Max! 🎉
Festejar(Gato{Nombre: "Luna"})  // Miau, soy Luna! 🎉

Interfaz vacía (interface{} y any):

// Desde Go 1.18, 'any' es un alias de interface{}
var x any = 42
x = "hola"
x = true
x = []int{1, 2, 3}

any es útil cuando realmente necesitas aceptar cualquier tipo, pero pierdes seguridad de tipos. Prefiere interfaces específicas.

Type assertions:

var val any = "texto"

s, ok := val.(string)     // ok=true, s="texto"
n, ok := val.(int)        // ok=false, n=0 (no panic)
// n := val.(int)         // ❌ panic si no es int

// Sin el ok, si falla → panic

Type switch:

func describir(v any) string {
    switch v.(type) {
    case string:
        return "Cadena de longitud " + strconv.Itoa(len(v.(string)))
    case int:
        return "Entero: " + strconv.Itoa(v.(int))
    case bool:
        if v.(bool) {
            return "Verdadero"
        }
        return "Falso"
    case []int:
        return fmt.Sprintf("Slice de %d enteros", len(v.([]int)))
    default:
        return "Tipo desconocido"
    }
}

Interfaces pequeñas son la norma en Go:

• io.Reader: Read(p []byte) (n int, err error)
• io.Writer: Write(p []byte) (n int, err error)
• fmt.Stringer: String() string
• error: Error() string

La filosofía Go es: “cuanto más pequeña la interfaz, mejor”. Una interfaz de un solo método es idiomática.

🧪 Cómo probarlo

func TestInterfazImplicita(t *testing.T) {
    p := Perro{Nombre: "Max"}
    g := Gato{Nombre: "Luna"}

    var s Saludador
    s = p
    if s.Saludar() != "Guau, soy Max" {
        t.Errorf("esperado Guau, got %s", s.Saludar())
    }
    s = g
    if s.Saludar() != "Miau, soy Luna" {
        t.Errorf("esperado Miau, got %s", s.Saludar())
    }
}

func TestTypeAssertion(t *testing.T) {
    var val any = "texto"
    s, ok := val.(string)
    if !ok || s != "texto" {
        t.Errorf("type assertion falló")
    }
    _, ok = val.(int)
    if ok {
        t.Errorf("no debería ser int")
    }
}

💡 Memoria y rendimiento

• Las interfaces se representan como un itable (tabla de métodos) + puntero al valor — 16 bytes
• El type assertion hace una comparación de itable en tiempo constante
• interface{} / any tiene el mismo costo que cualquier otra interfaz
• Las type assertions con ok evitan panics — no hay overhead extra

✅ Buenas prácticas

• ✅ Define interfaces pequeñas (1-3 métodos) — es idiomático en Go
• ✅ Acepta interfaces, devuelve structs (conocido como “Go proverb”)
• ✅ Usa any para valores genéricos no tipados (JSON, logging)
• ⚠️ No declares interfaces en el paquete que las consume — decláralas donde se usan
• ⚠️ Type assertion sin ok puede panic — siempre usa la forma segura
• ❌ No crees interfaces antes de necesitarlas (YAGNI)

🏗️ Metodología

• Contratos: las interfaces definen comportamiento, no datos
• Mocking: interfaces pequeñas son fáciles de mockear en tests
• Composición: io.ReadWriter combina io.Reader + io.Writer
• Dependency injection: las funciones aceptan interfaces, no implementaciones concretas

🔗 Para saber más

• Effective Go — Interfaces
• Go dev — Type assertions
• Go dev — Type switches

Genéricos (Go 1.18+)

¿Qué es?

Los genéricos permiten escribir funciones y tipos parametrizados por tipos. Llegaron en Go 1.18 (marzo 2022). Son como una máquina de hacer moldes: en vez de fabricar una función para cada tipo, creas un molde ajustable.

🔗 Go dev — Generics tutorial

Sintaxis básica

// Función genérica
func Min[T constraints.Ordered](a, b T) T {
    if a < b {
        return a
    }
    return b
}

// Uso
fmt.Println(Min[int](5, 3))     // 3 (explícito)
fmt.Println(Min(5, 3))          // 3 (inferido)
fmt.Println(Min("a", "b"))      // "a" (también funciona)

Constraints (restringen qué tipos se aceptan):

// Constraint personalizada
type Numeric interface {
    ~int | ~int8 | ~int16 | ~int32 | ~int64 |
        ~uint | ~uint8 | ~uint16 | ~uint32 | ~uint64 |
        ~float32 | ~float64
}

func Suma[N Numeric](vals ...N) N {
    var total N
    for _, v := range vals {
        total += v
    }
    return total
}

// ~int significa "cualquier tipo cuyo tipo subyacente sea int"
type MiInt int
Suma(MiInt(1), MiInt(2))  // ✅ MiInt tiene ~int

Constraints predefinidas en golang.org/x/exp/constraints:

import "golang.org/x/exp/constraints"

// constraints.Ordered → tipos comparables con <, >, <=, >=
// constraints.Signed → int, int8, ..., int64
// constraints.Unsigned → uint, uint8, ..., uint64
// constraints.Integer → Signed + Unsigned
// constraints.Float → float32, float64
// constraints.Complex → complex64, complex128

comparable — constraint para tipos comparables:

func Contains[T comparable](slice []T, val T) bool {
    for _, v := range slice {
        if v == val {
            return true
        }
    }
    return false
}

Estructuras genéricas:

type Stack[T any] struct {
    items []T
}

func (s *Stack[T]) Push(item T) {
    s.items = append(s.items, item)
}

func (s *Stack[T]) Pop() (T, bool) {
    if len(s.items) == 0 {
        var zero T
        return zero, false
    }
    item := s.items[len(s.items)-1]
    s.items = s.items[:len(s.items)-1]
    return item, true
}

// Uso
s := Stack[string]{}
s.Push("hola")
s.Push("mundo")
val, ok := s.Pop()  // val="mundo", ok=true

Limitaciones de los genéricos en Go:

1. No puedes usar operadores en tipos genéricos sin constraints (excepto == y != con comparable)
2. No puedes hacer switch v.(type) directamente (necesitas reflexión)
3. Type inference no siempre funciona con tipos complejos
4. El rendimiento es bueno, pero no igual que monomorfización manual

🧪 Cómo probarlo

func TestGenericoMin(t *testing.T) {
    if Min(5, 3) != 3 { t.Error("Min(5,3) debería ser 3") }
    if Min("a", "b") != "a" { t.Error(`Min("a","b") debería ser "a"`) }
}

func TestStack(t *testing.T) {
    s := Stack[int]{}
    s.Push(1)
    s.Push(2)
    val, ok := s.Pop()
    if !ok || val != 2 { t.Errorf("Pop esperado 2, got %d", val) }
    val, ok = s.Pop()
    if !ok || val != 1 { t.Errorf("Pop esperado 1, got %d", val) }
    _, ok = s.Pop()
    if ok { t.Error("Pop de stack vacío debería dar false") }
}

func TestContains(t *testing.T) {
    nums := []int{1, 2, 3, 4, 5}
    if !Contains(nums, 3) { t.Error("debería contener 3") }
    if Contains(nums, 99) { t.Error("no debería contener 99") }
}

💡 Memoria y rendimiento

• Go compila una copia especializada por cada conjunto único de tipos (monomorfización)
• Las funciones genéricas pueden ser más lentas en compilación, pero en runtime son casi idénticas a versiones manuales
• any en genéricos evita boxing (a diferencia de interface{})
• Las constraints se verifican en compilación, zero overhead en runtime
• El tamaño del binario crece con cada especialización única

✅ Buenas prácticas

• ✅ Usa comparable para funciones que necesitan == / !=
• ✅ Usa any como el tipo más permisivo
• ✅ Prefiere interfaces específicas a genéricos en APIs públicas simples
• ⚠️ No uses genéricos donde interfaces + type switch son más claros
• ⚠️ Los genéricos no son para todo — YAGNI también aplica aquí
• ❌ No abuses de genéricos anidados — el código se vuelve ilegible

🏗️ Metodología

• Estructuras de datos: Stack[T], Queue[T], Tree[T] con genéricos
• Algoritmos: funciones de ordenación/búsqueda genéricas
• Helpers: Contains, Map, Filter, Reduce (cuando no uses slices / maps)
• APIs: genéricos para mantener tipado fuerte sin duplicar código

🔗 Para saber más

• Go dev — Generics
• Proposal — Type Parameters
• Go dev — Constraints

Punteros

¿Qué es?

Un puntero almacena la dirección de memoria de un valor. Go tiene punteros pero no aritmética de punteros (a diferencia de C). Es como una nota adhesiva que te dice dónde está el objeto, no el objeto en sí.

🔗 Go dev — Pointer types

Sintaxis básica

var x int = 42
var p *int = &x  // p es un puntero a int, &x obtiene la dirección

fmt.Println(*p)  // 42 — desreferenciación
*p = 100         // Modifica x a través del puntero
fmt.Println(x)   // 100

¿Cuándo usar punteros vs valores?

Escape analysis (compilador decide heap vs stack):

El compilador de Go decide automáticamente si una variable va al stack o al heap. No necesitas new vs malloc — Go lo hace por ti.

func crearUsuario() *Usuario {
    u := Usuario{Nombre: "Ana"} // ¿stack o heap?
    return &u                    // ❗ Escapa al heap — se usa fuera de la función
}

func procesar() {
    var u Usuario               // Stack — no escapa
    u.Nombre = "Ana"
    _ = u.Nombre
}

Puedes ver las decisiones del compilador:

go build -gcflags='-m' ./...

Si el compilador ve que una variable debe sobrevivir a la función que la crea, la asigna al heap. Si no, la asigna al stack — mucho más rápido.

🧪 Cómo probarlo

func TestPunteros(t *testing.T) {
    x := 42
    p := &x
    if *p != 42 { t.Errorf("esperado 42, got %d", *p) }
    *p = 100
    if x != 100 { t.Errorf("esperado 100, got %d", x) }
}

func TestEscapeAnalysis(t *testing.T) {
    u := crearUsuario()
    if u.Nombre != "Ana" { t.Errorf("esperado Ana, got %s", u.Nombre) }
    // crearUsuario aloca en heap porque devuelve puntero
}

💡 Memoria y rendimiento

• Los punteros ocupan 8 bytes en x86-64 (una dirección de memoria)
• Stack es rápido (asignación barata); heap requiere GC
• Escape analysis decide automáticamente stack vs heap
• go build -gcflags='-m' para inspeccionar decisiones
• Pasar structs grandes por puntero es más barato que copiarlos
• Enteros pequeños por valor suelen ser más rápidos que por puntero

✅ Buenas prácticas

• ✅ Usa punteros para structs grandes y receptores mutables
• ✅ Usa valores para enteros, booleanos, strings, y structs pequeños
• ⚠️ No uses punteros para evitar copias prematuras — el compilador optimiza
• ❌ No hay null pointer safety — siempre checkea nil antes de dereferenciar
• ❌ No compartas punteros entre goroutines sin sincronización

🏗️ Metodología

• Receptores: pointer receiver si mutas, value receiver si no
• Campos opcionales: puntero indica nil = ausencia
• Constructores: devuelven *T para indicar ownership
• Caches y pools: punteros evitando copias innecesarias

🔗 Para saber más

• Go dev — Escape analysis
• Go dev — Stack vs heap

Errores

¿Qué es?

Go trata los errores como valores, no como excepciones. No hay try/catch. Es como un semáforo: en vez de lanzar una sirena cuando algo falla, simplemente devuelves una señal (error) que quien te llama debe revisar.

🔗 Go dev — Errors (blog)

Sintaxis básica

// error es una interfaz predefinida
type error interface {
    Error() string
}

// Función que puede fallar — devuelve error
func Dividir(a, b float64) (float64, error) {
    if b == 0 {
        return 0, fmt.Errorf("división por cero")
    }
    return a / b, nil // nil = no error
}

// Uso idiomático
resultado, err := Dividir(10, 0)
if err != nil {
    fmt.Println("Error:", err)
    return
}
fmt.Println(resultado)

Wrapping errores (Go 1.13+):

import "errors"
import "fmt"

// Envolver un error con contexto
if err != nil {
    return fmt.Errorf("leer archivo %s: %w", filename, err)
}

// Desenvolver con errors.Is y errors.As
if errors.Is(err, os.ErrNotExist) {
    fmt.Println("El archivo no existe")
}

var pathError *os.PathError
if errors.As(err, &pathError) {
    fmt.Println("Path:", pathError.Path)
}

fmt.Errorf("%w") envuelve el error para que errors.Is y errors.As puedan atravesar la cadena. Usa %v en lugar de %w si no necesitas desenvolver.

errors.Join (Go 1.20+):

var errs error
for _, op := range operaciones {
    if err := op(); err != nil {
        errs = errors.Join(errs, err) // acumula errores
    }
}
return errs // devuelve todos los errores combinados

Errores personalizados:

type ErrorValidacion struct {
    Campo string
    Valor any
    Motivo string
}

func (e *ErrorValidacion) Error() string {
    return fmt.Sprintf("validación: %s con valor %v — %s", e.Campo, e.Valor, e.Motivo)
}

// Uso
return nil, &ErrorValidacion{Campo: "email", Valor: "", Motivo: "no puede estar vacío"}

Sentinel errors vs error types:

🧪 Cómo probarlo

func TestErrorBasico(t *testing.T) {
    _, err := Dividir(10, 0)
    if err == nil { t.Fatal("debería haber error") }
    if err.Error() != "división por cero" {
        t.Errorf("mensaje incorrecto: %s", err.Error())
    }
    res, err := Dividir(10, 2)
    if err != nil { t.Fatal("no debería haber error") }
    if res != 5 { t.Errorf("esperado 5, got %f", res) }
}

func TestErrorWrapping(t *testing.T) {
    base := errors.New("error base")
    envuelto := fmt.Errorf("contexto: %w", base)
    if !errors.Is(envuelto, base) {
        t.Error("errors.Is debería encontrar el error envuelto")
    }
}

func TestErrorJoin(t *testing.T) {
    e1 := errors.New("error 1")
    e2 := errors.New("error 2")
    joined := errors.Join(e1, e2)
    if !errors.Is(joined, e1) || !errors.Is(joined, e2) {
        t.Error("errors.Join debería contener ambos errores")
    }
}

💡 Memoria y rendimiento

• error es una interfaz de 16 bytes (itable + puntero)
• errors.New aloca una vez — reutiliza la misma string
• fmt.Errorf("%w") aloca un nuevo wrapping error cada vez
• errors.Is y errors.As recorren la cadena — O(n) en número de wraps
• errors.Join evita anidar múltiples niveles — eficiente para batches

✅ Buenas prácticas

• ✅ Siempre checkea err != nil — es idiomático en Go
• ✅ Usa %w para wrapping con intención de desenvolver después
• ✅ Usa errors.Is para sentinel errors, errors.As para custom types
• ⚠️ No uses _ = err para ignorar errores — al menos loguea
• ❌ No uses panic como sustituto de errores — panics son para bugs, no para validación

🏗️ Metodología

• APIs: devuelve (resultado, error) como último valor de retorno
• Validación: errores personalizados con datos estructurados
• Fallos de sistema: errors.New para errores simples y conocidos
• Capas: cada capa añade contexto con %w sin duplicar información

🔗 Para saber más

• Dave Cheney — Don’t just check errors, handle them gracefully
• Go dev — Working with Errors

Defer, panic y recover

¿Qué es?

defer programa una función para ejecutarse al salir del ámbito actual (LIFO). panic detiene el flujo normal (error irrecuperable). recover captura un panic dentro de un defer. Es como una red de seguridad: el defer es el arnés que siempre se activa al saltar, el panic es la alarma, y recover la red que atrapa la caída.

🔗 Go dev — Defer

Sintaxis básica

defer — ejecuta una función al salir del ámbito actual:

func leerArchivo(nombre string) error {
    f, err := os.Open(nombre)
    if err != nil {
        return err
    }
    defer f.Close() // se ejecuta cuando leerArchivo termina

    // procesar archivo...
    return nil
}

Los defer se ejecutan en orden LIFO (last in, first out):

func ejemplo() {
    defer fmt.Println("tercero")
    defer fmt.Println("segundo")
    fmt.Println("primero")
}
// Output:
// primero
// segundo
// tercero

panic — error irrecuperable (equivalente a lanzar excepción):

func init() {
    if config == nil {
        panic("config no inicializada — el programa no puede continuar")
    }
}

Usa panic solo para casos que no deberían ocurrir (bugs, estado imposible). No uses panic para errores normales — para eso está error.

recover — captura un panic (como un catch):

func proteger() {
    defer func() {
        if r := recover(); r != nil {
            fmt.Println("Recuperado de panic:", r)
            // Log, cleanup, etc.
        }
    }()
    // código que podría paniquear
    panic("algo salió mal")
}

recover solo funciona dentro de un defer. Si llamas recover fuera de un defer, devuelve nil.

Cuándo usar panic/recover:

• Panic: inicialización que falla, errores de programación (nil dereference), casos imposibles
• Error: todo lo demás (IO, validación, red, BD)
• Recover: en el borde del programa (middleware HTTP, worker supervisor, entrada de goroutine)

// Middleware HTTP que captura panics
func recoveryMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        defer func() {
            if r := recover(); r != nil {
                log.Printf("panic capturado: %v", r)
                http.Error(w, "Internal Server Error", http.StatusInternalServerError)
            }
        }()
        next.ServeHTTP(w, r)
    })
}

🧪 Cómo probarlo

func TestDeferLIFO(t *testing.T) {
    var orden []string
    func() {
        defer func() { orden = append(orden, "segundo") }()
        defer func() { orden = append(orden, "primero") }()
    }()
    if len(orden) != 2 || orden[0] != "primero" || orden[1] != "segundo" {
        t.Errorf("orden LIFO incorrecto: %v", orden)
    }
}

func TestRecoverPanic(t *testing.T) {
    func() {
        defer func() {
            if r := recover(); r == nil {
                t.Error("debería haber capturado el panic")
            }
        }()
        panic("test panic")
    }()
}

💡 Memoria y rendimiento

• defer tiene overhead pequeño (~50ns por llamada en Go 1.14+)
• defer en un closure captura variables por referencia — cuidado con bucles
• panic/recover tienen costo alto (~1µs) — no uses para control de flujo
• Los defer se evalúan en el momento del registro (argumentos se copian), no al ejecutarse

✅ Buenas prácticas

• ✅ Usa defer para cleanup (cerrar archivos, liberar mutexes, cerrar conexiones)
• ✅ Usa panic solo para bugs o estados imposibles
• ✅ Usa recover en el borde del programa (middleware HTTP, goroutines main)
• ⚠️ No uses panic para errores esperables (IO, validación, red)
• ❌ No uses recover para control de flujo normal

🏗️ Metodología

• Cleanup: defer f.Close() justo después de os.Open
• Middleware HTTP: recover en el handler más externo para evitar crashes
• Workers: recover en cada goroutine para aislar fallos
• Inicialización: panic si el programa no puede continuar sin configuración válida

🔗 Para saber más

• Go dev — Panic/Recover (blog)
• Go dev — Effective Go: Defer

Goroutines y canales

¿Qué es?

Las goroutines son hilos ligeros gestionados por el runtime de Go (~4KB de stack vs ~1MB de thread SO). Los canales son tuberías tipadas para comunicación entre goroutines. Es como tener 1000 mensajeros (goroutines) que se pasan notas (canales) sin pisarse.

🔗 Go dev — Goroutines

Sintaxis básica

func decir(texto string) {
    for i := 0; i < 5; i++ {
        time.Sleep(100 * time.Millisecond)
        fmt.Println(texto)
    }
}

func main() {
    go decir("hola")   // goroutine — se ejecuta concurrentemente
    go decir("mundo")  // otra goroutine
    time.Sleep(1 * time.Second) // espera a que terminen (mala práctica)
}

Canales — tuberías tipadas para comunicación entre goroutines:

// Crear canal
ch := make(chan int)       // unbuffered — bloquea hasta que alguien recibe
buf := make(chan int, 10)  // buffered — buffer de 10 elementos

// Enviar
ch <- 42

// Recibir
valor := <-ch
valor, ok := <-ch  // ok=false si el canal está cerrado

// Cerrar canal
close(ch)

Canales unbuffered (sincrónicos):

func main() {
    ch := make(chan string)

    // Goroutine que envía
    go func() {
        fmt.Println("Goroutine: enviando...")
        ch <- "mensaje"  // Bloquea hasta que main recibe
        fmt.Println("Goroutine: enviado!")
    }()

    time.Sleep(500 * time.Millisecond)
    fmt.Println("Main: recibiendo...")
    msg := <-ch          // Bloquea hasta que la goroutine envía
    fmt.Println("Main:", msg)
}

Canales buffered (asíncronos):

ch := make(chan int, 3)  // buffer de 3

ch <- 1  // No bloquea (buffer no está lleno)
ch <- 2  // No bloquea
ch <- 3  // No bloquea
// ch <- 4 // ❌ Bloquearía — buffer lleno

fmt.Println(<-ch)  // 1
fmt.Println(<-ch)  // 2
fmt.Println(<-ch)  // 3

range sobre canales:

func main() {
    ch := make(chan string)

    go func() {
        defer close(ch) // importante: cerrar el canal
        for _, m := range []string{"a", "b", "c"} {
            ch <- m
        }
    }()

    for msg := range ch { // itera hasta que el canal se cierra
        fmt.Println(msg)
    }
}

select — espera múltiples canales (como switch pero para canales):

func main() {
    ch1 := make(chan string)
    ch2 := make(chan string)

    go func() {
        time.Sleep(1 * time.Second)
        ch1 <- "uno"
    }()
    go func() {
        time.Sleep(2 * time.Second)
        ch2 <- "dos"
    }()

    select {
    case msg := <-ch1:
        fmt.Println("Recibido de ch1:", msg)
    case msg := <-ch2:
        fmt.Println("Recibido de ch2:", msg)
    case <-time.After(500 * time.Millisecond):
        fmt.Println("Timeout") // si ninguno responde
    default:
        fmt.Println("Ningún canal listo") // select no bloqueante
    }
}

Patrón fan-out/fan-in (distribuir trabajo):

// Fan-out: múltiples workers leen del mismo canal
func worker(id int, jobs <-chan int, results chan<- int) {
    for job := range jobs {
        results <- job * 2
    }
}

func main() {
    jobs := make(chan int, 100)
    results := make(chan int, 100)

    // Lanzar 3 workers
    for w := 1; w <= 3; w++ {
        go worker(w, jobs, results)
    }

    // Enviar 9 jobs
    for j := 1; j <= 9; j++ {
        jobs <- j
    }
    close(jobs)

    // Recibir resultados
    for r := 1; r <= 9; r++ {
        <-results
    }
}

🧪 Cómo probarlo

func TestCanalUnbuffered(t *testing.T) {
    ch := make(chan string)
    go func() {
        ch <- "hola"
    }()
    msg := <-ch
    if msg != "hola" { t.Errorf("esperado hola, got %s", msg) }
}

func TestCanalBuffered(t *testing.T) {
    ch := make(chan int, 3)
    ch <- 1; ch <- 2; ch <- 3
    if <-ch != 1 { t.Error("esperado 1") }
    if <-ch != 2 { t.Error("esperado 2") }
    if <-ch != 3 { t.Error("esperado 3") }
}

func TestCanalCerrado(t *testing.T) {
    ch := make(chan int)
    close(ch)
    val, ok := <-ch
    if ok { t.Error("canal cerrado debería dar ok=false") }
    if val != 0 { t.Error("canal cerrado debería dar zero value") }
}

func TestSelect(t *testing.T) {
    ch := make(chan string)
    go func() {
        ch <- "mensaje"
    }()
    select {
    case msg := <-ch:
        if msg != "mensaje" { t.Errorf("esperado mensaje, got %s", msg) }
    case <-time.After(time.Second):
        t.Error("timeout")
    }
}

💡 Memoria y rendimiento

• Las goroutines empiezan con ~4KB de stack, crecen y se reutilizan
• El scheduler M:N mapea N goroutines a M OS threads (GOMAXPROCS)
• Canales unbuffered sincronizan --- buffered desacoplan
• select con default es no bloqueante
• Cerrar un canal libera a los receivers bloqueados en range
• Los canales tienen overhead pequeño --- pero enviar valores grandes por puntero es más rápido

✅ Buenas prácticas

• ✅ Usa go func() en main para tareas concurrentes
• ✅ Siempre cierra los canales desde el emisor, no desde el receptor
• ✅ Usa range para consumir canales hasta que se cierren
• ✅ Usa select con time.After para timeouts
• ⚠️ No uses time.Sleep para sincronizar --- usa canales o sync.WaitGroup
• ⚠️ Las goroutines filtradas (leak) no se recolectan --- asegúrate de que terminen
• ❌ No compartas memoria entre goroutines --- usa canales para comunicar

🏗️ Metodología

• Pipeline: generator → worker → collector con canales
• Workers: fan-out con workers fijos, fan-in con resultados
• Timeouts: select con time.After en operaciones de red
• Señales: canal chan struct{} como señal ligera (zero bytes)
• Tareas programadas: time.Ticker + select

🔗 Para saber más

• Go dev — Channels
• Go by Example — Channels
• Go dev — Share memory by communicating

Context

¿Qué es?

context.Context lleva deadlines, cancelaciones y valores a través de la cadena de llamadas. Es el mecanismo estándar para controlar el ciclo de vida de operaciones concurrentes. Es como un walkie-talkie: desde la base (main) le dices a cada explorador (goroutine) “vuelve en 5 segundos” o “cancelado, todos a casa”.

🔗 Go dev — Context (blog)

Sintaxis básica

import "context"

// Función que acepta context y respeta cancelación
func operacionLarga(ctx context.Context) error {
    select {
    case <-time.After(2 * time.Second):
        return nil
    case <-ctx.Done():
        return ctx.Err() // context.Canceled o context.DeadlineExceeded
    }
}

Contextos padre/hijo:

// Con cancelación manual
ctx, cancel := context.WithCancel(context.Background())
defer cancel() // importante: siempre llama a cancel para liberar recursos

go func() {
    time.Sleep(100 * time.Millisecond)
    cancel() // cancela todas las operaciones que usen ctx
}()

err := operacionLarga(ctx)

// Con timeout automático
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel()

// Con deadline absoluto
deadline := time.Now().Add(5 * time.Second)
ctx, cancel := context.WithDeadline(context.Background(), deadline)
defer cancel()

// Con valores (tipo map, scope limitado al contexto)
ctx = context.WithValue(ctx, "requestID", "abc-123")
reqID := ctx.Value("requestID").(string) // type assertion necesaria

Buenas prácticas con context:

1. El context es siempre el primer parámetro de una función
2. Nunca almacenes un context en un struct — pásalo como argumento
3. Siempre llama a cancel() cuando crees un context cancelable
4. Usa context.Background() para el root, context.TODO() cuando aún no sabes qué usar
5. No uses context.WithValue para cosas que deberían ser parámetros

func Handler(ctx context.Context, req *Request) (*Response, error) {
    ctx, cancel := context.WithTimeout(ctx, 10*time.Second)
    defer cancel()

    data, err := fetchFromDB(ctx, req.ID)
    if err != nil {
        return nil, err
    }
    return &Response{Data: data}, nil
}

🧪 Cómo probarlo

func TestContextCancel(t *testing.T) {
    ctx, cancel := context.WithCancel(context.Background())
    cancel() // cancelación inmediata

    select {
    case <-ctx.Done():
        if ctx.Err() != context.Canceled {
            t.Errorf("esperado Canceled, got %v", ctx.Err())
        }
    case <-time.After(time.Second):
        t.Error("timeout")
    }
}

func TestContextTimeout(t *testing.T) {
    ctx, cancel := context.WithTimeout(context.Background(), 10*time.Millisecond)
    defer cancel()

    <-ctx.Done()
    if ctx.Err() != context.DeadlineExceeded {
        t.Errorf("esperado DeadlineExceeded, got %v", ctx.Err())
    }
}

func TestContextValue(t *testing.T) {
    ctx := context.WithValue(context.Background(), "key", "value")
    if v := ctx.Value("key").(string); v != "value" {
        t.Errorf("esperado value, got %s", v)
    }
}

💡 Memoria y rendimiento

• context.Background() y context.TODO() son singletons — zero alloc
• WithCancel/WithTimeout alocan un nuevo contexto cada vez
• WithValue usa una linked list interna — O(n) en búsqueda
• ctx.Done() devuelve el mismo canal cada vez — no aloca
• Llamar cancel() más de una vez es seguro (no-op en la segunda)

✅ Buenas prácticas

• ✅ El context es siempre el primer parámetro — convención del lenguaje
• ✅ Siempre llama a cancel() con defer para evitar leaks
• ✅ Usa context.WithTimeout para operaciones con límite de tiempo
• ⚠️ No almacenes context en structs — pásalo como argumento
• ⚠️ No uses WithValue como sustituto de parámetros normales
• ❌ No pases context.Background() a funciones — pasa el context que recibes

🏗️ Metodología

• HTTP handlers: context.WithTimeout(ctx, 10s) para cada request
• DB queries: pasa context a db.QueryContext(ctx, ...)
• Goroutines: pasa context a cada goroutine lanzada
• Propagación: extiende deadlines, nunca los ignores
• Cleanup: cancel() libera resources del contexto padre

🔗 Para saber más

• Go dev — pkg context
• Go dev — Context patterns

Sincronización (sync)

¿Qué es?

El paquete sync proporciona primitivas de sincronización básicas: WaitGroup para esperar goroutines, Mutex/RWMutex para exclusión mutua, Once para inicialización única, y Map para maps concurrentes. Es como un semáforo en una intersección: coordina quién pasa y quién espera.

🔗 Go dev — sync

Sintaxis básica

sync.WaitGroup — esperar a que un grupo de goroutines termine:

func main() {
    var wg sync.WaitGroup

    for i := 1; i <= 5; i++ {
        wg.Add(1) // incrementa contador
        go func(id int) {
            defer wg.Done() // decrementa contador
            fmt.Printf("Worker %d terminado\n", id)
        }(i)
    }

    wg.Wait() // bloquea hasta que contador llegue a 0
    fmt.Println("Todos los workers terminaron")
}

sync.Mutex — exclusión mutua:

type Contador struct {
    mu    sync.Mutex
    valor int
}

func (c *Contador) Incrementar() {
    c.mu.Lock()
    defer c.mu.Unlock()
    c.valor++
}

func (c *Contador) Valor() int {
    c.mu.Lock()
    defer c.mu.Unlock()
    return c.valor
}

sync.RWMutex — lectores concurrentes, escritor exclusivo:

type Cache struct {
    mu   sync.RWMutex
    data map[string]string
}

func (c *Cache) Get(key string) (string, bool) {
    c.mu.RLock() // múltiples lecturas concurrentes
    defer c.mu.RUnlock()
    v, ok := c.data[key]
    return v, ok
}

func (c *Cache) Set(key, value string) {
    c.mu.Lock() // escritura exclusiva
    defer c.mu.Unlock()
    c.data[key] = value
}

sync.Once — ejecuta algo exactamente una vez (singletons, inicialización):

var (
    config   *Config
    configMu sync.Once
)

func GetConfig() *Config {
    configMu.Do(func() {
        fmt.Println("Inicializando configuración (solo una vez)")
        config = &Config{
            DBUrl:  os.Getenv("DB_URL"),
            Puerto: 8080,
        }
    })
    return config
}

sync.Map — map concurrente optimizado (cuando las claves se escriben una vez y se leen muchas):

var m sync.Map

m.Store("key", "value")
val, ok := m.Load("key")
m.LoadOrStore("key", "default") // si existe, devuelve el existente
m.Delete("key")

m.Range(func(key, value any) bool {
    fmt.Println(key, value)
    return true // continuar iterando
})

⚠️ sync.Map está optimizado para patrones específicos (escritura una vez, lectura frecuente). Para la mayoría de casos, un map con sync.RWMutex es mejor opción.

🧪 Cómo probarlo

func TestWaitGroup(t *testing.T) {
    var wg sync.WaitGroup
    for i := 0; i < 10; i++ {
        wg.Add(1)
        go func() {
            defer wg.Done()
        }()
    }
    wg.Wait()
    // si llegamos aquí sin deadlock, el test pasa
}

func TestMutex(t *testing.T) {
    c := Contador{}
    var wg sync.WaitGroup
    for i := 0; i < 100; i++ {
        wg.Add(1)
        go func() {
            defer wg.Done()
            c.Incrementar()
        }()
    }
    wg.Wait()
    if c.Valor() != 100 { t.Errorf("esperado 100, got %d", c.Valor()) }
}

func TestOnce(t *testing.T) {
    var count int
    var o sync.Once
    for i := 0; i < 10; i++ {
        o.Do(func() { count++ })
    }
    if count != 1 { t.Errorf("Once debería ejecutarse 1 vez, count=%d", count) }
}

💡 Memoria y rendimiento

• sync.Mutex es ligero (~8 bytes), sync.RWMutex un poco más
• Mutex.Lock() con contención hace system calls — caro pero necesario
• sync.Once usa atomic operations internamente — overhead mínimo
• sync.WaitGroup usa atomics + futex — eficiente para cientos de goroutines
• sync.Map tiene overhead interno pero brilla en lecturas sin contención
• Siempre usa defer para unlock — previene deadlocks si hay panic

✅ Buenas prácticas

• ✅ Usa defer c.mu.Unlock() justo después de Lock()
• ✅ Prefiere sync.RWMutex cuando hay más lecturas que escrituras
• ✅ Usa sync.Once para inicialización perezosa
• ⚠️ No copies un sync.Mutex — pasa siempre por puntero
• ⚠️ No uses sync.Map para casos generales — map + RWMutex suele ser mejor
• ❌ No mezcles canales y mutexes en la misma goroutine — difícil de razonar

🏗️ Metodología

• WaitGroup: esperar que N goroutines terminen
• Mutex: proteger estado compartido con acceso concurrente
• RWMutex: caches, configs (más lecturas que escrituras)
• Once: singletons, inicialización perezosa
• Pool: sync.Pool para reutilizar objetos alocados frecuentemente

🔗 Para saber más

• Go dev — sync.Pool
• Go dev — Atomic
• Go dev — The Go Memory Model

io.Reader y io.Writer

¿Qué es?

io.Reader y io.Writer son las interfaces más ubicuas de Go después de error. Representan fuentes y destinos de datos en streaming. Es como una manguera: por un lado entra agua (Reader), por el otro sale (Writer), y puedes conectar mangueras entre sí.

🔗 Go dev — io

Sintaxis básica

type Reader interface {
    Read(p []byte) (n int, err error)
}

type Writer interface {
    Write(p []byte) (n int, err error)
}

Composición de readers/writers:

// Leer todo de un reader
data, _ := io.ReadAll(reader)

// Copiar de reader a writer
io.Copy(writer, reader)

// TeeReader: escribe lo que lee a otro writer (como `tee` en Unix)
io.Copy(os.Stdout, io.TeeReader(file, os.Stderr))

// LimitedReader: lee solo N bytes
limited := io.LimitReader(reader, 1024)

// MultiReader: concatenar múltiples readers
combined := io.MultiReader(file1, file2)

// MultiWriter: escribir a múltiples writers a la vez
writers := io.MultiWriter(file, os.Stdout)

// PipeReader/PipeWriter: conexión síncrona entre goroutines
pr, pw := io.Pipe()

Ejemplo práctico — servidor de archivos con io.Copy:

func serveFile(w http.ResponseWriter, path string) {
    f, err := os.Open(path)
    if err != nil {
        http.Error(w, err.Error(), http.StatusNotFound)
        return
    }
    defer f.Close()

    // Detecta Content-Type automáticamente
    buf := make([]byte, 512)
    f.Read(buf)
    w.Header().Set("Content-Type", http.DetectContentType(buf))

    f.Seek(0, io.SeekStart) // vuelve al principio
    io.Copy(w, f)           // copia eficiente del archivo a la response
}

🧪 Cómo probarlo

func TestReaderWriter(t *testing.T) {
    var buf bytes.Buffer
    writer := &buf
    n, err := writer.Write([]byte("hola"))
    if err != nil { t.Fatal(err) }
    if n != 4 { t.Errorf("esperado 4 bytes escritos, got %d", n) }

    reader := &buf
    data, err := io.ReadAll(reader)
    if err != nil { t.Fatal(err) }
    if string(data) != "hola" { t.Errorf("esperado hola, got %s", string(data)) }
}

func TestCopy(t *testing.T) {
    var src bytes.Buffer
    var dst bytes.Buffer
    src.WriteString("test data")
    n, err := io.Copy(&dst, &src)
    if err != nil { t.Fatal(err) }
    if n != 9 { t.Errorf("esperado 9 bytes copiados, got %d", n) }
    if dst.String() != "test data" { t.Errorf("esperado 'test data', got '%s'", dst.String()) }
}

func TestLimitedReader(t *testing.T) {
    src := strings.NewReader("contenido largo")
    limited := io.LimitReader(src, 5)
    data, _ := io.ReadAll(limited)
    if string(data) != "conte" { t.Errorf("esperado 'conte', got '%s'", string(data)) }
}