El coste de una proc-macro y cuándo vale la pena

Terminamos el nivel con la pregunta que un ingeniero maduro se hace antes de escribir la macro: ¿de verdad hace falta? Una macro procedural es la herramienta más potente del arsenal de metaprogramación de Rust, y precisamente por eso es la más cara. Cuesta un crate separado, arrastra syn y quote —dos de las dependencias más pesadas del ecosistema— y ese coste no lo pagas solo tú una vez, sino cada usuario de tu librería en cada compilación. Sus alternativas, macro_rules! y escribir el código a mano, son a menudo más que suficientes y órdenes de magnitud más baratas. Este cierre no te disuade de las proc-macros: te da el marco para elegirlas cuando su poder justifique su precio, y para no alcanzarlas por reflejo cuando una herramienta más humilde bastaba.

El coste estructural: un crate aparte

La primera factura es organizativa y no es negociable: una proc-macro debe vivir en un crate propio marcado con proc-macro = true, y ese crate solo puede exportar macros procedurales, nada más. No puede ofrecer también los tipos o traits que acompañan a la macro. Por eso el patrón universal en el ecosistema es la pareja de crates: uno normal con la API pública —serde, tokio— y otro -derive o -macros con la maquinaria —serde_derive, tokio-macros—, reexportado desde el primero para que el usuario no lo vea. Es una complejidad de proyecto que un macro_rules! no impone: una macro declarativa vive en cualquier módulo del crate que ya tienes.

# El crate de la macro: aislado, y solo exporta proc-macros.
[package]
name = "mi_cosa_derive"

[lib]
proc-macro = true

[dependencies]
syn = "2"
quote = "1"
proc-macro2 = "1"

El coste continuo: tiempo de compilación

La segunda factura es la que de verdad duele a escala, y se paga en tiempo de compilación. Son tres sumandos. Primero, tu crate de macro depende de syn y quote, y syn —un parser completo de Rust— es notoriamente costoso de compilar, sobre todo con la feature full. Segundo, esa dependencia se inyecta en el grafo de cada proyecto que use tu librería: alguien que solo quería tu tipo acaba compilando syn la primera vez. Tercero, y más sutil, la macro se ejecuta en cada compilación: cada vez que se recompila un módulo que la invoca, tu función corre otra vez, parsea otra vez, genera otra vez. Un derive aplicado a doscientos structs es doscientas ejecuciones de parseo y generación en cada build incremental que los toque.

Las tres herramientas, comparadas

Antes de escribir una proc-macro, sitúala frente a sus dos alternativas. La pregunta decisiva casi siempre es una: ¿necesitas introspección —leer la forma del tipo, sus campos, sus tipos—? Si la respuesta es no, rara vez necesitas una proc-macro.

La regla práctica se ordena de menor a mayor coste. Si el patrón aparece pocas veces, escríbelo a mano: nada supera en claridad y baratura a código explícito. Si se repite mucho pero es sustitución sintáctica sin necesidad de mirar dentro de los tipos, usa macro_rules!. Solo cuando necesites inspeccionar la estructura de tipos arbitrarios —un derive genérico, un framework, un DSL con validación en compilación— sube el último escalón hasta la proc-macro, porque es lo único que puede leer la forma de un dato que aún no existe.

flowchart TD
A[Necesito generar codigo repetido] --> B{Necesito leer campos o tipos del dato}
B -->|No y aparece poco| C[Escribelo a mano]
B -->|No pero se repite mucho| D[Usa macro_rules]
B -->|Si introspeccion real| E[Usa una proc-macro]
E --> F[Acota el coste con features y precompilacion]
style C fill:#a6e3a1,color:#11111b
style D fill:#89b4fa,color:#11111b
style E fill:#cba6f7,color:#11111b
style F fill:#f9e2af,color:#11111b

Cuándo sí, y cómo acotar el coste

Hay casos donde la proc-macro no solo se justifica, sino que es la única respuesta sensata: un trait que decenas de tipos deben implementar mecánicamente (Serialize, Debug), la ergonomía de un framework que reescribe funciones en manejadores, o un DSL que valida su sintaxis en compilación como sqlx::query!. En todos, el valor —código correcto generado por miles, errores atrapados antes de ejecutar— desborda con creces el coste de compilación. Cuando ese sea tu caso, acótalo: activa en syn solo las features que uses, evitando full si no parseas ítems completos; apóyate en cargo expand para depurar viendo el código real generado; y considera, para macros muy usadas, técnicas de precompilación que evitan recompilar el motor de la macro en cada proyecto. El objetivo no es rehuir la herramienta pesada, sino pagarla con conciencia.

# Acota syn a lo imprescindible: cada feature se paga en compilacion.
syn = { version = "2", default-features = false, features = ["derive", "parsing", "printing"] }