15 puntos por GN⁺ 2025-09-21 | 1 comentarios | Compartir por WhatsApp
  • El proyecto Git anunció oficialmente que de ahora en adelante incorporará Rust en el núcleo y que, a partir de Git 3.0, Rust será un requisito obligatorio de compilación
  • Esta serie de parches avanzará con el carácter de una introducción experimental (test balloon), similar a la adopción previa de funciones de C99, con el objetivo de preparar gradualmente la infraestructura para incorporar Rust
  • Como primer paso, se convirtió a Rust el módulo varint.c, que casi no tiene dependencias, para validar la interoperabilidad entre C y Rust y el tooling de compilación
  • Por ahora solo se admite la compilación con Meson, y más adelante se planea añadir soporte para Makefile y validación de compilaciones con Rust en CI, además de verificaciones de consistencia de formato basadas en cargo format
  • Este es un cambio importante que da tiempo a la comunidad de Git y a los distribuidores para adaptarse a los nuevos requisitos del toolchain de Rust, mientras a largo plazo mejora la seguridad y la capacidad de expansión del código

Contexto de la adopción de Rust

  • Git ha estado evaluando una evolución del lenguaje para mejorar la estabilidad y el mantenimiento
  • La adopción de Rust implica reforzar la seguridad de memoria, aprovechar un toolchain moderno y asegurar posibilidades de optimización de rendimiento
  • Además, busca construir una base de código más robusta mediante la incorporación de un lenguaje moderno
  • Al anunciar con antelación que Rust será obligatorio en el momento del lanzamiento de Git 3.0, se busca dar tiempo de preparación al ecosistema
  • El plan es ampliar de forma gradual el alcance del código en Rust y, en última instancia, reimplementar también algunas funciones centrales en Rust

Serie experimental de parches

  • Se eligió varint.c como el primer módulo al que se aplicará Rust
    • Es muy simple y no tiene dependencias
    • Permite verificar la interop entre C y Rust
    • Se puede experimentar sin afectar el funcionamiento general de Git
  • Todas las pruebas pasaron en la versión varint.rs

Cambios en el sistema de compilación

  • Actualmente el soporte de Rust solo se añadió al sistema de compilación Meson
  • Más adelante se planea añadir soporte de Rust también a Makefile
  • También hace falta preparar trabajo relacionado con CI
    • Validación de compilación y funcionamiento con Rust
    • Consistencia del estilo de código mediante cargo format
    • Otras automatizaciones de tooling y mantenimiento

Próximos pasos

  • Este trabajo se enfoca más en experimentar el proceso de adopción que en las funciones de Rust en sí
  • Después podrían reescribirse en Rust más funciones internas de Git, incluido el módulo xdiff
  • Se prevé expandir Rust de forma gradual para que todo el ecosistema se adapte a un entorno de compilación basado en Rust

Implicaciones

  • Git se está preparando para la transición de lenguaje más importante de su historia
  • Hacer obligatorio Rust puede asegurar seguridad, mantenibilidad y posibilidades de evolución a largo plazo
  • Para distribuidores y desarrolladores, configurar un entorno de desarrollo con Rust pasará a ser un requisito indispensable dentro del ecosistema de Git

1 comentarios

 
GN⁺ 2025-09-21
Comentarios en Hacker News
  • En otro hilo sobre hacer obligatorio Rust, el autor opina que sería mejor introducirlo primero como una dependencia opcional y, más adelante, volverlo obligatorio cuando se agregue soporte para Rust en gcc
    Enlace a la discusión relacionada
    • Se enfatiza que el compilador gcc es inconsistente; por ejemplo, gcj (gcc para Java) casi nadie lo usa
      También se sospecha que, como Rust es un lenguaje sin un estándar formal, con el tiempo su implementación podría quedarse bastante rezagada, como pasó antes con Java
  • Hay curiosidad por saber por qué quieren introducir Rust en Git
    Git ya parece una herramienta muy madura, y da la impresión de que solo necesita mantenimiento o mejoras, no una gran cantidad de código nuevo que justifique introducir otro lenguaje
    A diferencia de Linux, donde continuamente se necesitan drivers nuevos, no parece haber una razón similar en Git
    Pide que alguien le explique si se está perdiendo de algo
    • Git sigue agregando funciones de forma constante, aunque no siempre sea evidente
      Los cambios de Git pueden verse en las RelNotes o, de forma más fácil de leer, en la categoría Git del blog de GitHub
    • Si pruebas herramientas como jj o git-branchless, cambia la idea de que git ya está “terminado”
      En el caso de git-branchless, incluye funciones como merges en memoria escritas en Rust
    • Vale la pena revisar este texto, donde hay varias respuestas
      También se puede buscar más contenido sobre Rust en esa lista de correo
      (Aclara que no está emitiendo una valoración a favor o en contra, sino que alguien más seguramente lo hará)
    • En los proyectos viejos de C cada vez entran menos desarrolladores
      Casi no hay gente interesada en desarrollar Git en C, mientras que sí hay entusiasmo entre quienes quieren participar en una reescritura en Rust
    • C no es seguro
  • Se cuestiona por qué se sigue intentando meter Rust en tantos lugares
    Git está bastante maduro y no parece que vaya a recibir mucho código nuevo
    Rust es mucho más complejo que C
    Si realmente se necesitan funciones orientadas a objetos, incluso usar solo C++98 sería mucho más simple y fácil de entender que C++ moderno o Rust
  • Se señala que el título es algo engañoso
    Rust no será obligatorio para futuros parches, sino que pasará a ser obligatorio dentro del sistema de compilación
    • Agradece la aclaración y dice que ya reflejó eso en el título
      Si está mal, todavía puede volver a corregirlo
    • Después preguntan de nuevo qué significa exactamente eso
      Quieren saber si es necesario para compilar el propio sistema de build o si también será obligatorio para compilar la aplicación
  • Aunque piensa que, por la edad, ya toca aceptar cambios, se queja de que antes bastaba con saber C para participar en el desarrollo de Git o del kernel, y ahora también habría que aprender Rust; además, la toolchain se vuelve cada vez más compleja, lo que sube la barrera de entrada
    Ha invertido mucho en Git y ha creado varios proyectos, así que no quiere perder la posibilidad de hackearlo
    • Se responde que no querer aprender cosas nuevas no parece una buena actitud en esta industria
      De hecho, Rust es más fácil de aprender que C en general (sobre todo que el C lleno de bugs), y desde luego más fácil que familiarizarse con el código fuente de Git o de Linux
    • Aunque hayas creado tu propio cliente Git y tu propio servidor web, el formato del repositorio Git no va a cambiar, así que la posibilidad de hackearlo no se vería afectada
    • Además, Git ya está hecho en varios lenguajes
      Según GitHub, es 50% C, 38% Shell, 4% Perl, y el resto TCL/Python, etc.
      Perl y TCL incluso son más excepcionales
      A medida que el proyecto creció, se fueron acumulando muchos hacks agregados por todas partes, y ahora hace falta mejorar seguridad/rendimiento y limpiar esos hacks viejos
      Rust parece adecuado para eso
    • Si eres ingeniero de software, normalmente deberías poder manejar varios lenguajes, así que sumar otro no debería ser un gran problema
    • Mucha gente joven, incluyéndome, prefiere Rust y no quiere aprender C
      Que Git use algo de Rust no debería impedirme desarrollar mi propio cliente o servidor Git
  • Al comentario de que adoptar Rust es imposible en algunas plataformas y difícil en otras, se le pide una explicación adicional
    • En sistemas Linux, cualquier biblioteca debería poder usarse como biblioteca del sistema, pero Rust no tiene un ABI estable, así que no puede usarse como una verdadera biblioteca compartida
      Las notas de lanzamiento de Debian también mencionan problemas relacionados con paquetes Rust/Go
      Al compilar paquetes en Rust, por temas de enlace estático, a menudo hay que reconstruirlos con frecuencia, lo cual resulta incómodo en uso real
      Si desde Rust se sigue ignorando el problema del ABI estable y de las bibliotecas compartidas, que son esenciales en Linux, podría generar incluso más quejas que C
      Cree que en arquitectura de software a gran escala hay que ser más cuidadosos
    • En plataformas propietarias menos visibles, sí hay soporte interno para compiladores C, pero no es posible soportar LLVM
      Si buscas la palabra clave NonStop en este artículo, puedes ver un caso
    • Se debe a que el compilador de Rust no soporta ciertas plataformas (combinaciones de SO/arquitectura)
      En RESF y similares se dice que “la plataforma no soporta Rust”, pero en realidad tiene que soportarla el compilador de Rust para que de verdad funcione
    • Como Rust se basa en LLVM, está más limitado que las plataformas que soporta GCC
    • Recomiendan consultar la sección "Tier 3" en la lista de plataformas soportadas de la documentación oficial de Rust
  • Hay curiosidad por saber qué cambios habrá en git 3.0
    git da la impresión de haberse estabilizado en la serie 2.x, así que no parece haber motivos para romper compatibilidad
  • Antes se daba por sentado que en entornos de compilación cruzada construir, ejecutar y editar código ocurrían en contextos distintos
    Existe la duda de si la cultura de desarrollo actual se ha alejado de saber usar este tipo de toolchains
    El control de código fuente, la compilación y el entorno de ejecución eran distintos, así que hacían falta copias remotas o ejecución remota, y en las reglas de build también era imprescindible detectar la plataforma objetivo
    • De hecho, siente que la toolchain de Rust hace la compilación cruzada más fácil que cualquier otro lenguaje compilado
      Con solo la bandera --target se puede compilar para cerca de 100 plataformas sin mayores problemas
      Cree que el problema real es que parte del equipo de Git insiste en las limitaciones de sus máquinas de desarrollo antiguas o fijas
    • Cree que la mayoría de los desarrolladores realmente no aprendieron bien compilación cruzada
      La compilación cruzada siempre ha sido ciudadana de segunda categoría y, en proyectos externos, ni siquiera se espera que funcione bien
      Incluso hay distribuciones Linux que, para Raspberry Pi y casos similares, hacen que la compilación se realice solo en el hardware real
      Por eso nadie se esfuerza en darle buen soporte
    • Independientemente de Rust, hoy el estado de la compilación cruzada le parece cercano a un “desastre”
      Linux está especialmente mal, porque la estructura de glibc ya envejeció tanto que se volvió difícil apuntar siquiera a una glibc mínima en cualquier hardware
      La mayoría de los proyectos ni siquiera intentan soportar compilación cruzada
      Zig está intentando mejorar esto
  • Se sostiene que sería mejor aplazar la adopción hasta que el frontend de Rust para gcc esté lo bastante maduro
    Git es una herramienta central del proyecto, así que los cambios implican mucho riesgo, y volverlo una dependencia obligatoria en tan poco tiempo, como seis meses, se considera riesgoso
  • Rust tiene una curva de aprendizaje pronunciada y una complejidad parecida a la de los lenguajes funcionales
    Esa complejidad busca atrapar más errores en tiempo de compilación, pero como resultado el lenguaje en sí se vuelve bastante complejo
    Por eso no recomienda adoptarlo
    Entiende que con el kernel pasó lo mismo y que también rechazó Rust
    Agregar a un kernel ya complejo un sistema de tipos al nivel de Haskell y un sistema de macros al estilo Lisp aumenta la complejidad
    Seguir código Rust a través de serde es difícil
    En cambio, en Go, Unmarshal es mucho más fácil de rastrear
    • En cambio, hay quien siente que los lenguajes funcionales y Rust son más claros que C o Go
      Porque permiten expresar más información en el compilador
      Nunca ha tenido grandes problemas con Serde y, de hecho, le ha tocado depurar más Unmarshal de Go
      La afirmación de que el kernel rechazó Rust tampoco sería exacta: en realidad fue un conflicto entre dos desarrolladores sobre dónde guardar los headers
    • C es simple, pero C seguro y de buen rendimiento es extremadamente complejo
      Rust tiene una barrera de entrada más alta que C, pero la distancia entre el “Rust mínimo” y el “Rust rápido y seguro” es mucho menor que en C
    • Se señala que, aunque se diga que Rust es complejo, C tampoco se queda atrás
    • Esa conveniencia de las comprobaciones en tiempo de compilación es justamente lo que diferencia a Rust
      Lo consideran tan importante como el borrow checker
    • Para alguien con experiencia en Typescript y acostumbrado por el linter a referencias, desempaquetado de Result y manejo de errores, Rust es bastante fácil de aprender
      La sintaxis también es tolerante
      El kernel de Linux en realidad no rechazó Rust