Programa Build It Yourself hecho por ti mismo

• Otra forma de pensar sobre las dependencias

  • Se propone una nueva perspectiva sobre las dependencias. Es necesario reducir el uso excesivo de dependencias y cambiar hacia una dirección de escribir código por cuenta propia.

• El problema de las dependencias

  • El "consumo de dependencias" es la repetición interminable de actualizaciones, parches, auditorías y dependencias transitivas que los desarrolladores instalan por productividad.
  • JavaScript y Rust son especialmente vulnerables al problema de las dependencias. Por ejemplo, un proyecto nuevo de Tokio incluye 28 crates, y un proyecto de Rocket aumenta a 172.

• El problema del tamaño de la terminal

  • El crate terminal_size ofrece una función simple para medir el tamaño de la terminal, pero requiere varios crates adicionales.
  • Esto provoca una situación en la que hay que compilar miles de otras funciones.

• La necesidad de las dependencias

  • Como se construye sobre bibliotecas de abstracción de plataforma, se necesitan actualizaciones para evitar duplicación de código y reducir tiempos de compilación.
  • A menudo son una causa principal de problemas de seguridad.

• El objetivo del código

  • El código debería escribirse de una forma que no necesite actualizaciones. En el ecosistema de Rust, el código estable sale perjudicado.

• Ventajas de escribir código directamente

  • Si escribes el código directamente, no se necesitan crates nuevos y disminuye la necesidad de mantenimiento.
  • Con herramientas como ChatGPT se pueden escribir rápidamente implementaciones sin dependencias.

• Código abierto y cultura corporativa

  • La cultura de revisión de código en las empresas influye en el software de código abierto.
  • Usar bibliotecas nuevas se considera algo positivo.

• La necesidad de una nueva perspectiva

  • Hay que elogiar a los ingenieros que escriben directamente funciones pequeñas.
  • Hay que mirar con sospecha los gráficos grandes de crates.

• Bibliotecas importantes

  • También existen bibliotecas importantes que resuelven problemas complejos. Por ejemplo, bibliotecas gráficas o implementaciones de protocolos.

• La importancia de construirlo uno mismo

  • Hay que celebrar cuando sea apropiado construirlo uno mismo.
  • Debe reconocerse el mérito de los autores de bibliotecas que crean bibliotecas de código abierto con pocas o ninguna dependencia.

• Conclusión

  • Hay que avanzar hacia una dirección de reducir dependencias y escribir código directamente.
  • minijinja es un ejemplo de minimizar dependencias, ya que solo depende de serde.

[GN⁺]

Comentarios en Hacker News

• Me gusta el lenguaje Rust, pero no me gustan los problemas de dependencias de Rust. La gestión de dependencias en C++ es mejor. En C++ puedes controlar las dependencias por tu cuenta, pero en Rust terminan apareciendo demasiadas dependencias y eso hace que uno se rinda. También desde el punto de vista de la seguridad no puedo saber qué estoy distribuyendo. Rust no tiene compatibilidad ABI y también carece de una cultura de bibliotecas compartidas. Eso rompe el modelo de distribución de paquetes del SO.

• La API de terminal no es estable. El ioctl TIOCGWINSZ no está estandarizado, y la función tcgetwinsize() se agregó a POSIX recién en 2024. Del lado de Windows es todavía más complicado.

• Reviví una web app que hice en 2006. Diseñé en exceso el proceso de despliegue de la app para aprender nuevas tecnologías de CI/CD. Usaba PHP y MySQL, y escribí la mayor parte del código yo mismo. Me tomó solo una hora revivir una app de 19 años. En cambio, la app de Spring Boot que usamos en mi trabajo actual es difícil de actualizar por problemas de dependencias.

• NodeJS tuvo un gran impacto en mi carrera, pero NPM causó muchos problemas. Cuando intento agregar una dependencia nueva, entra en conflicto con otras dependencias. En el caso de Expo, existe un problema en el que el proyecto base de React Native no compila en Android. Eso me da confianza al ver que incluso proyectos grandes pueden distribuir plantillas que no funcionan.

• El ecosistema de Rust tiene muchas dependencias en comparación con Go. En Go, las interfaces se satisfacen implícitamente, así que no se necesitan dependencias adicionales.

• La abstracción de las bibliotecas tiene costos ocultos. Cuando un paquete cambia el diseño, aparece inestabilidad. Lo simple es lo que sobrevive más tiempo. He visto problemas parecidos no solo en Rust, sino también en otros lenguajes.

• Es más rápido que ChatGPT o Cursor te generen rápidamente una implementación sin dependencias. Muchas dependencias de SaaS/servicios de terceros ya resuelven problemas que de por sí ya estaban resueltos.

• Flask y Bottle tenían funciones parecidas, pero Flask se volvió más popular. Bottle era un solo archivo y no tenía dependencias, así que era fácil copiarlo dentro de un proyecto. Sin embargo, como no siguió las prácticas modernas de Python, se siente anticuado.

• Se necesitan ingenieros capaces de desarrollar soluciones por sí mismos. Es fácil crear una solución mejor que una biblioteca existente. En un proyecto escribí un parser para una variante de Markdown, pero mis compañeros de equipo no quisieron usarlo por razones de mantenimiento.

• Es un problema compilar cientos de funciones cuando solo usas una. En un proyecto que actualizaba dependencias de terceros, solo se estaba usando un método de una biblioteca matemática. Le recomendé al ingeniero que consultara la página de Wikipedia y escribiera el método él mismo. El problema no es usar dependencias de terceros, sino que hace falta el concepto de traer solo una pequeña parte de una biblioteca. Un "microframework" podría ser la solución.