Domina el sistema de importación y paquetes en Go

Cuando trabajas en Go, no estás simplemente “añadiendo librerías” como en otros lenguajes; estás declarando rutas precisas hacia código que reside en otros lugares. Un import path es la dirección única que le dice al compilador exactamente dónde buscar un paquete. Si intentas usar un nombre que no existe o una ruta mal escrita, el compilador fallará inmediatamente porque no sabe si ese nombre es un paquete local, uno de la librería estándar o un módulo externo.

El sistema de Go está diseñado para evitar la ambigüedad. Por eso, las rutas se dividen en dos grandes mundos: los paquetes de la standard library (como fmt o os), que se acceden por su nombre corto porque el compilador ya sabe que están en la raíz de la instalación de Go, y los paquetes de terceros, que requieren la ruta completa del módulo (por ejemplo, github.com/google/uuid). Esta distinción es fundamental: si intentas importar un paquete de GitHub usando solo su nombre corto, el compilador no tendrá idea de dónde buscarlo.

Usarás estas rutas cada vez que necesites funcionalidad que no hayas escrito tú mismo. Si lo haces mal —por ejemplo, si intentas usar un alias de forma incorrecta o importas algo que no existe— el programa ni siquiera llegará a compilar. Lo más crítico ocurre cuando importas paquetes de forma ambigua, lo que puede provocar colisiones de nombres que hacen que tu código sea imposible de mantener o que use funciones de la librería equivocada sin que te des cuenta.

package main

import (
	"fmt"      // Importación estándar (standard library)
	"math"     // Importación estándar
	"math/cmplx" // Importación de un subpaquete
	_ "runtime/debug" // Blank import: se ejecuta su init() pero no se usa el paquete
)

// Imaginemos que queremos usar un alias para evitar conflictos
// En un archivo real, esto se usaría si hubiera otro paquete con nombre similar
import m "math" 

func main() {
	// 1. Uso estándar de fmt
	fmt.Println("--- Iniciando programa ---")

	// 2. Uso de un paquete estándar sin alias
	valor := 25.0
	raiz := math.Sqrt(valor)
	fmt.Printf("La raíz de %.2f es %.2f\n", valor, raiz)

	// 3. Uso de un alias (m) definido arriba
	// Si hubiéramos importado "math" como "m", usaríamos m.Sin(x)
	// Aquí usamos math directamente porque el alias es una alternativa
	fmt.Printf("Seno de pi: %v\n", math.Sin(math.Pi))

	// 4. Uso de un paquete con funciones para números complejos
	complejo := cmplx.Rect(1, 1)
	fmt.Printf("Número complejo creado: %v\n", complejo)

	// El blank import de "runtime/debug" se ejecutó silenciosamente
	// permitiendo que el paquete configure estados internos del runtime
	// antes de que llegáramos aquí.
}

Desglose del ejemplo

En el código anterior, fmt y math se importan de forma directa. El compilador busca estos nombres en la carpeta de la librería estándar de tu instalación de Go.

Fíjate en la línea _ "runtime/debug". El uso del guion bajo (_) es un blank import. Esto es crucial: le indica al compilador que queremos que el paquete se cargue y se ejecute su función init(), pero no queremos usar ninguna de sus funciones en nuestro código. Esto es muy común en drivers de bases de datos (como los de SQL) que necesitan registrarse con el motor principal mediante efectos secundarios.

También hemos definido import m "math". Esto es un alias de importación. Si en un proyecto complejo tuvieras dos paquetes llamados math (uno propio y uno externo), podrías usar m.Sqrt para referirte específicamente al de la librería estándar, evitando que el compilador se confunda.

Finalmente, el paquete math/cmplx nos muestra cómo se navegan las jerarquías; es un paquete que vive dentro de otro, y su ruta es su identidad completa.

El error frecuente

Un error muy común en principiantes es el uso del dot import (import . "math"). Si hicieras esto, todas las funciones de math (como Sqrt, Sin, Pi) se importarían directamente en el espacio de nombres de tu archivo, sin necesidad de usar el prefijo math..

import . "math"

func main() {
    // Esto es legal, pero extremadamente peligroso
    fmt.Println(Sqrt(16)) 
}

¿Por qué es una mala idea? Porque ensucia tu código. Si más adelante defines una variable llamada Pi o una función llamada Sin en tu propio paquete, habrás creado una colisión. El compilador podría confundirse de Pi (el valor matemático) o de tu Pi (tu variable), y el error será muy difícil de rastrear en archivos grandes. La regla de oro es: usa siempre el nombre del paquete (math.Sqrt) para que el código sea legible y predecible.

N° 13