Depender, empaquetar o reescribir
El cierre de los acompañantes: las tres opciones frente a una funcionalidad que no está en tu código, con sus costes reales y el criterio que decide.
Las tres, con sus costes
La lectura importante está en la segunda columna, que es la que casi nadie mira al decidir: empaquetar es barato de empezar y caro de mantener; escribirlo es lo contrario. Y como una aplicación publica muchas versiones, el coste recurrente acaba dominando.
El criterio
La pregunta 1 es la que más se salta y la que más ahorra: buena parte de lo que la gente resuelve lanzando procesos —comprimir, convertir imágenes, leer formatos, calcular hashes, manejar archivos— tiene bibliotecas de Rust maduras que eliminan el problema entero.
Cuándo cambiar de opción
Las tres decisiones son reversibles, y hay señales concretas:
- De depender a empaquetar: cuando el soporte de «no lo tengo instalado» supera al trabajo de empaquetar. Se nota en las incidencias.
- De empaquetar a escribir: cuando el acompañante se usa para algo pequeño y su mantenimiento pesa más que la función. Empaquetar una herramienta de cien megas para calcular una miniatura es la señal.
- Y de escribir a usar una biblioteca: cuando aparece una madura que hace lo tuyo mejor. Pasa, y no hay orgullo que valga.
Lo que esta fase deja claro
Antes de seguir con la red y la integración con el sistema, la conclusión de los dos niveles:
Un proceso externo es la herramienta más potente y más cara del catálogo. Potente porque puede hacer cualquier cosa; cara porque cada uso trae ámbitos, argumentos, salida, límites, limpieza, entorno, arquitectura, firma y licencia. Nada de eso es difícil por separado y todo junto es una parte notable del trabajo de mantener una aplicación.
Y por eso la mejor decisión suele ser la que evita el proceso. No por miedo, sino por cuentas.