- El nuevo sistema de control de versiones jj es un proyecto escrito en Rust que complementa las limitaciones de Git existente y tiene una estructura que permite una adopción gradual
- El autor, basándose en su experiencia previa analizando el potencial de crecimiento de Rust, evalúa que jj también tiene un potencial similar en términos de encaje de mercado, equipo especializado y base de usuarios
- jj es compatible con repositorios Git y al mismo tiempo ofrece un flujo de trabajo más simple, por lo que resulta especialmente accesible para desarrolladores que no están familiarizados con la estructura interna de Git
- Su uso real se está expandiendo en Google y Oxide, entre otros, y se está formando una comunidad entusiasta y un equipo de desarrollo comprometido
- El autor se une a ERSC, que desarrolla una plataforma de colaboración basada en jj, con el plan de impulsar directamente el crecimiento del ecosistema de jj, como en los primeros días de Rust
Por qué elegí Rust
- El autor se interesó en el lenguaje cuando vio en Hacker News la noticia de “Rust 0.5 released” en la Navidad de 2012
- En ese momento era desarrollador de Ruby on Rails, pero desde la universidad ya tenía interés en compiladores y programación de sistemas
- Al evaluar las posibilidades de éxito de Rust, consideró tres factores: encaje de mercado, equipo de desarrollo y base de usuarios
- No había un lenguaje confiable que reemplazara a C/C++, y Rust proponía un enfoque innovador al ofrecer seguridad de memoria sin garbage collection
- Como Mozilla lo respaldaba y tenía planes de introducir Rust en Firefox, concluyó que había altas probabilidades de asegurar una base de uso real
- El ambiente amable y colaborativo de la comunidad de Rust también fue un factor atractivo
- Más adelante, el autor escribió el tutorial “Rust for Rubyists” y terminó participando como coautor de la documentación oficial
La aparición de jj
- jj (Jujutsu) no es un lenguaje de programación, sino un nuevo sistema de control de versiones (VCS) implementado en Rust
- Es compatible con Git y puede adoptarse gradualmente mientras se siguen usando los repositorios existentes tal como están
- El autor comenzó a explorar jj a partir de la recomendación de Rain, una desarrolladora con gustos técnicos similares
- Rain formó parte del equipo de gestión de código fuente de Meta, por lo que su recomendación fue tomada como una señal confiable
- Durante un fin de semana probó jj por su cuenta e inició un proyecto para escribir un tutorial
- Igual que cuando aprendió Rust, lo abordó organizando los conceptos mientras escribía
- Como resultado, el tutorial recibió una respuesta positiva de la comunidad
Perspectivas de futuro para jj
- El autor ve en jj un patrón de crecimiento similar al de los primeros años de Rust
- El encaje de mercado, la capacidad del equipo y el potencial de expansión entre usuarios se ven positivos
- En términos de encaje de mercado, aunque Git mantiene una ventaja absoluta, jj puede trabajar directamente con repositorios Git, lo que permite una adopción parcial
- Dentro de Oxide también su uso se ha ido expandiendo a partir de Rain, hasta el punto de abrirse un canal dedicado por el alto interés
- jj también se usa dentro de Google, lo que se interpreta como una señal similar a cuando Mozilla adoptó Rust
- Incluso en el gran monorepo de Google, basado en el backend de Piper, algunos proyectos ya usan jj, lo que funciona como prueba social
- Existe una curva de aprendizaje, pero para usuarios que no están familiarizados con la estructura interna de Git ofrece una experiencia más intuitiva y simple
- Cuanto más experto se es en Git, más adaptación requieren los conceptos nuevos, pero los desarrolladores en general se acostumbran rápido
- La comunidad de jj está creciendo con un ambiente entusiasta y amigable, lo que recuerda a la comunidad temprana de Rust
El equipo y la comunidad de jj
- Su creador, Martin, ha estado dedicado al desarrollo de jj durante mucho tiempo y recientemente trasladó el proyecto de una cuenta personal a una cuenta oficial de la organización, además de ordenar la gobernanza
- Los miembros del equipo son expertos con amplia experiencia desarrollando herramientas de control de código fuente, y muestran fortalezas en dirección técnica y control de calidad
- La comunidad está creciendo rápidamente gracias al feedback activo y la colaboración, recreando la energía positiva de la comunidad inicial de Rust
Un nuevo desafío: unirme a ERSC
- El autor decidió dejar Oxide y unirse a la startup ERSC, que desarrolla una plataforma de colaboración basada en jj
- Oxide era un gran lugar para trabajar, pero el deseo de participar más a fondo en el ecosistema de jj fue el factor decisivo
- ERSC planea construir una plataforma de colaboración para desarrolladores sobre jj, y menciona el caso de GitHub, que empezó con la razón social Logical Awesome, para describir una etapa inicial parecida
- El autor planea cerrar su trabajo en Oxide, tomarse un descanso y después dedicarse de lleno a la actividad en la comunidad de jj y a terminar el tutorial
- Adelanta una mayor actividad en Discord, una serie de publicaciones en el blog y más contribuciones a la comunidad
- Considera 2025 como un nuevo punto de inflexión y expresa su gratitud por poder asumir un proyecto que realmente le apasiona
Conclusión
- El autor está convencido de que jj tiene el potencial de reproducir la trayectoria de crecimiento de Rust
- La compatibilidad con Git, la posibilidad de adopción gradual, un equipo comprometido y una comunidad activa son la base de esa convicción
- jj muestra potencial para evolucionar más allá de una simple herramienta y convertirse en una plataforma innovadora para la colaboración entre desarrolladores
- El recorrido del autor, que comenzó con Rust, ahora continúa con un nuevo capítulo junto a jj
2 comentarios
Es algo que ya había salido varias veces, pero creo que debería echarle un vistazo.
Comentarios de Hacker News
Probé usar jj en serio un par de veces. El concepto de conflictos de primera clase está genial, pero en la práctica hago staging/commit mucho más seguido que resolver conflictos. Como vengo de magit, la división y selección de hunks en jj se me hizo demasiado incómoda. Yo hago rebase con frecuencia, así que con los atajos de rebase de magit ya estaba aprovechando la mayoría de las ventajas de jj. Para alguien como yo, jj tendría que mejorar muchísimo la UX de selección de hunks para superar a magit
git_head. Yo uso un alias para hacer commit con cambios staged (ejemplo de config.toml)Cada vez que veo una alternativa a Git, me sale un poco de sentimiento ludita. Ya hay demasiados lenguajes, frameworks y herramientas. Al menos me tranquiliza que, por lo menos en VCS, exista una solución casi universal como Git. Puede que jj resuelva problemas, pero pensando en la carga de que la industria tenga que soportar ambos sistemas, no creo que el balance neto sea positivo
git-svn. jj parece seguir un enfoque parecido. Aunque no conozcas jj, el CI y las herramientas existentes siguen funcionando igualProbé jj, pero yo ya estoy acostumbrado a Sublime Merge. Cuando haces control de versiones por CLI, hay mucha escritura repetitiva y es fácil perder el estado. En una GUI, el estado siempre está visible y con un clic puedes ver el diff o escribir el mensaje de commit. No quiero volver a seleccionar hunks con el teclado nunca más. SM es realmente comodísimo. Ojalá la GUI de jj evolucione o jj se integre en SM
La verdadera noticia es que la gente ya empezó a hacer cosas como “jjhub” (ersc.io)
Dicen que jj se está expandiendo dentro de Google, pero Google tiene la costumbre de cambiar periódicamente de VCS interno. En 7 años pasaron por git wrapper, una versión extendida de mercurial, y ahora jj
Me pregunto si jj maneja archivos binarios grandes mejor que git. En desarrollo de videojuegos, Perforce sigue siendo el rey. git no alcanza, incluso con LFS
Seguí el tutorial de Jujutsu durante más o menos un día y me pareció bastante bueno. Aun así, sentí que faltaba una pieza del rompecabezas. Por ejemplo, me preguntaba si el change id realmente ayuda cuando subes un PR a GitHub. Da la impresión de que muestra su verdadero valor solo con el backend Piper interno de Google. Me da curiosidad cuál es el plan de ERSC. Personalmente, me gustaría un workflow distribuido con revisión de código offline integrada
change-id, así que aunque GitHub no conozca jj, entre usuarios de jj sí se puede rastrear el rebase. Se puede ver congit cat-file -p HEADLlevo 1 o 2 meses usando jj en proyectos personales y estoy bastante satisfecho. Eso sí, al modificar revisiones antiguas puede pasar que se incluyan por error archivos agregados recientemente a
.gitignore. Fuera de eso, está bien. Aun así, por ahora sé mucho más de Git, así que pienso introducirlo en la empresa poco a pocoEste año me uní a la empresa de Sapling/Subversion y todavía no he usado jj. Aun así, Sapling se siente mucho más intuitivo, y las pilas de commits son más fáciles de entender que las branches. Aunque me pregunto cómo funciona sin soporte como la UI de revisión de Meta. Este tipo de proyectos hace mucha falta
Como sea que se llame, East River Source Control es un nombre realmente genial