Veinte años no son nada

Lenguajes de implementación y “escrito en Rust”

• Debate repetido sobre por qué los proyectos anuncian “escrito en Rust”.
• Los defensores dicen que la elección del lenguaje señala:
  • Seguridad de memoria y velocidad sin GC.
  • Binarios estáticos y autocontenidos, y herramientas fluidas.
  • Una cultura de desarrollo que valora la corrección y el rendimiento.
• Los escépticos lo ven como marketing débil: si “escrito en Rust” es el titular, quizá haya poco más que diferencie el proyecto.
• Algunos señalan que el lenguaje es predictivo del estilo del proyecto y de su encaje en el ecosistema (por ejemplo, es más fácil contribuir si conoces Rust/Go que Python).
• Críticas a Python/JS por rendimiento y estabilidad a largo plazo; se menciona que Go es similar a Rust en distribución, pero no en garantías de tipos/propiedad.

Pijul, VCS basados en parches e ideas de CRDT

• Se destaca Pijul y Fossil como verdaderas alternativas a Git con diseños distintos; jj y Sapling se ven más como interfaces mejoradas para Git/Mercurial.
• El autor de Pijul explica:
  • El diseño se basa en parches/CRDT; los conflictos forman parte del modelo.
  • Las estructuras de datos se diseñaron “como teóricos”, y luego se optimizaron.
  • Un almacén clave-valor propio en Rust (Sanakirja) permite un almacenamiento rápido, genérico, amigable con mmap y bifurcaciones eficientes, superando a LMDB en sus benchmarks.
  • Rust se eligió pragmáticamente por el control de bajo nivel sin el dolor de depuración de C++; hoy quizá elegiría Zig debido a la evolución del lenguaje.
• Algunos argumentan que los VCS basados en parches pueden ser más rápidos que Git, basado en snapshots, para repos grandes, conflictos, blame y archivos binarios.

Fortalezas, debilidades y flujos de trabajo de Git

• Muy elogiado por:
  • Velocidad frente a herramientas más antiguas.
  • Flujo de trabajo distribuido y commits sin conexión.
  • Flexibilidad y un potente modelo de datos.
• Críticas:
  • La UX de la CLI es confusa; los conceptos filtran detalles de la implementación interna.
  • Rebase, reescritura de historial y flujos con commits apilados son difíciles; herramientas como Gerrit/Graphite/jj intentan mitigarlo.
  • Git almacena snapshots, no un historial explícito de cambios; los renombres/splits de archivos y las grandes refactorizaciones son difíciles de seguir.
  • No hay directorios vacíos; el historial de splits/merges de archivos y movimientos semánticos es débil.
  • Git LFS es visto por algunos como frágil y operativamente incómodo.

Centralización, tamaño del historial y clones parciales

• Debate sobre si los clones locales con historial completo eran “impensables” hace 20 años; algunos recuerdan CVS/SVN junto con scripts locales y discos lo bastante grandes, mientras otros enfatizan las limitaciones de red y almacenamiento de la época.
• Se señala que DVCS implica un límite práctico: el historial del repositorio debe caber en el portátil más pequeño de desarrollo.
• Algunos sostienen que la mayoría de las organizaciones son de facto centralizadas y se beneficiarían de clones jerárquicos/subordinados: historial parcial, árboles parciales, pero manteniendo ramas y commits locales.
• Se mencionan las funciones más recientes de Git partial clone y sparse-checkout como soluciones parciales.

Activos binarios y proyectos no textuales

• El modelo centrado en texto de Git funciona bien para la mayoría del software, pero:
  • Los videojuegos, el diseño de chips y las canalizaciones de medios siguen prefiriendo Perforce o SVN por los binarios grandes.
  • Git LFS es criticado por ser propenso a bugs, complejo operativamente y requerir componentes extra del servidor.
  • Se desea un VCS que entienda de forma nativa formatos binarios (por ejemplo, diffs semánticos para imágenes) y almacenamiento de archivos grandes; Pijul afirma tener soporte binario nativo.

Futuros semánticos, sensibles al AST y basados en CRDT

• Varios comentaristas sugieren:
  • Control de versiones sobre ASTs o estructuras específicas del dominio en lugar de texto bruto.
  • Mejores diffs/conflictos que entiendan movimientos, renombres y refactors.
• Una propuesta: un sucesor de Git que almacene historiales CRDT a nivel de carácter, con colaboración en tiempo real y commits semánticos; los problemas abiertos incluyen cómo mostrar conflictos y la eliminación de datos (secretos).
• Otros sostienen que esa granularidad puede añadir ruido y complejidad; los commits como puntos de control elegidos por humanos siguen siendo valiosos.

Herramientas históricas y perspectiva

• Numerosas reminiscencias de VSS, ClearCase, Perforce, CVS, SVN, RCS, BitKeeper y versionado improvisado con zip/tar.
• Los sistemas centralizados basados en bloqueos (VSS, algunas configuraciones de ClearCase/Perforce) se recuerdan como dolorosos, aunque alguna vez se consideraron “profesionales”; los flujos de código abierto con CVS/SVN se veían por delante de muchas empresas.
• Sensación general de que cada generación pensó que sus herramientas eran buenas hasta que el siguiente gran paso (SVN, luego Git/DVCS) expuso sus límites.

¿Reemplazará algo a Git?

• Algunos piensan que Git es una meseta evolutiva; los sucesores necesitarían:
  • Compatibilidad total con Git y uso transparente sobre repos existentes.
  • UX más simple y mejor semántica (renombres, operaciones sensibles al AST, commits apilados).
  • Mejor manejo de repos grandes y binarios.
• Otros esperan un desplazamiento eventual, citando la larga historia de rotación en los VCS; aun así, los efectos de red de Git y su estatus de “suficientemente bueno” podrían mantenerlo dominante durante mucho tiempo.