Git: anunciada a adoção de Rust e sua exigência no sistema de build

 (lore.kernel.org)
15 pontos por GN⁺ 2025-09-21 | 1 comentários | Compartilhar no WhatsApp
  • O projeto Git anunciou oficialmente que vai adotar Rust no núcleo e que, a partir do Git 3.0, Rust se tornará um requisito obrigatório de build
  • Esta série de patches avança com o caráter de adoção experimental (test balloon), como ocorreu no passado com a introdução de recursos do C99, com o objetivo de preparar gradualmente a infraestrutura para incorporar Rust
  • Como primeiro passo, o módulo varint.c, que quase não tem dependências, foi convertido para Rust para validar a interoperabilidade entre C e Rust e o tooling de build
  • No momento, há suporte apenas para build com Meson; no futuro, devem ser adicionados suporte a Makefile e, no CI, validação de build com Rust e verificação de consistência de formatação baseada em cargo format
  • Trata-se de uma mudança importante de longo prazo para aumentar a segurança e a escalabilidade do código, ao mesmo tempo em que dá à comunidade Git e aos distribuidores tempo para se adaptar aos novos requisitos da toolchain Rust

Contexto da adoção de Rust

  • O Git vem avaliando uma evolução de linguagem para reforçar a estabilidade e a manutenção
  • A adoção de Rust significa reforço da segurança de memória, uso de toolchains modernas e possibilidade de otimização de desempenho
  • Além disso, a ideia é construir uma base de código mais robusta por meio da adoção de uma linguagem moderna
  • O objetivo de avisar com antecedência que Rust será obrigatório no lançamento do Git 3.0 é garantir tempo de preparação para o ecossistema
  • O plano é ampliar gradualmente o escopo de aplicação do código Rust e, no fim, até reimplementar em Rust parte de funcionalidades centrais

Série experimental de patches

  • O varint.c foi escolhido como primeiro módulo a receber Rust
    • É muito simples e não tem dependências
    • Permite validar a interop entre C ↔ Rust
    • Dá para experimentar sem impactar o conjunto de funcionalidades do Git
  • Todos os testes passaram na versão varint.rs

Mudanças no sistema de build

  • Atualmente, o suporte a Rust foi adicionado apenas ao sistema de build Meson
  • No futuro, também há planos de adicionar suporte a Rust no Makefile
  • Também será preciso preparar trabalhos relacionados ao CI
    • Validação de build e funcionamento com Rust
    • Garantia de consistência do estilo de código com cargo format
    • Outras automações de tooling e manutenção

Próximos passos

  • Este trabalho está mais focado em experimentar o processo de adoção do que nos recursos de Rust em si
  • Depois, mais funcionalidades internas do Git, incluindo o módulo xdiff, poderão ser reescritas em Rust
  • A ideia é expandir gradualmente o uso de Rust e levar todo o ecossistema a se adaptar a um ambiente de build baseado em Rust

Implicações

  • O Git está se preparando para a transição de linguagem mais importante de sua história
  • Tornar Rust obrigatório pode garantir segurança, manutenibilidade e potencial de evolução de longo prazo
  • Para distribuidores e desenvolvedores, montar um ambiente de desenvolvimento Rust passará a ser essencial no ecossistema do Git

Leituras relacionadas

1 comentários

 
GN⁺ 2025-09-21
Comentários do Hacker News
  • Em outra thread sobre tornar Rust obrigatório, o autor opina que, em vez de torná-lo obrigatório imediatamente, seria melhor introduzi-lo como dependência opcional e depois torná-lo obrigatório quando o gcc adicionar suporte a Rust
    Link para a discussão relacionada
    • Destaca que o compilador gcc carece de consistência; por exemplo, quase ninguém usa o gcj (gcc para Java)
      Como o suporte a Rust também é para uma linguagem sem um padrão formal, suspeita que com o tempo a implementação pode ficar bastante defasada, como aconteceu no passado com Java
  • Pergunta por que querem introduzir Rust no Git
    O Git já parece ser uma ferramenta bastante madura, precisando apenas de manutenção e melhorias, e não parece haver necessidade de uma grande quantidade de código novo a ponto de justificar a introdução de uma nova linguagem
    Ao contrário do Linux, que precisa continuamente de novos drivers, não vê um motivo equivalente no Git
    Gostaria que alguém explicasse se há algo que ele não está percebendo
    • O Git continua recebendo novas funcionalidades de forma constante, embora isso não seja muito visível
      As mudanças no Git podem ser vistas nas RelNotes ou, de forma mais acessível, na categoria Git do blog do GitHub
    • Se você usar ferramentas como jj ou git-branchless, pode mudar de ideia sobre o Git estar “completo”
      No caso do git-branchless, há recursos como merge em memória escritos em Rust
    • Vale a pena consultar este post, que reúne várias respostas
      Há mais conteúdo relacionado a Rust nessa mailing list
      (Não está avaliando diretamente se é bom ou ruim; apenas diz que alguém provavelmente fará isso)
    • Projetos antigos em C estão tendo cada vez mais dificuldade para atrair novos desenvolvedores
      Quase ninguém quer desenvolver Git em C, enquanto desenvolvedores interessados em reescrevê-lo em Rust demonstram entusiasmo para participar
    • C não é segura
  • Questiona por que continuam tentando introduzir Rust em tantos lugares
    O Git é maduro e não parece que muito código novo será adicionado
    Rust é muito mais complexa que C
    Se realmente forem necessários recursos de orientação a objetos, usar algo como C++98 já seria muito mais simples e fácil de entender do que C++ moderno ou Rust
  • O título é um pouco enganoso
    Rust não será obrigatório para futuros patches, e sim no sistema de build
    • Agradece pela observação e diz que refletiu isso no título
      Se estiver errado, ainda pode corrigir de novo
    • Em seguida, surge a pergunta sobre o que isso significa exatamente
      Quer saber se isso é necessário para compilar o próprio sistema de build ou se também será obrigatório para compilar a aplicação
  • Diz que está ficando velho e talvez seja a hora de aceitar mudanças, mas reclama que antes bastava conhecer C para participar do desenvolvimento do Git ou do kernel, enquanto agora também será preciso saber Rust, e que a toolchain cada vez mais complexa aumenta a barreira de entrada
    Investiu muito no Git e criou vários projetos, então não quer perder a possibilidade de hackear o Git
    • Acha que não querer aprender coisas novas não é uma postura adequada para este setor
      Na prática, Rust é mais fácil de aprender do que C “comum” (especialmente C cheio de bugs), e certamente mais fácil do que entender o código-fonte do Git ou do Linux
    • Mesmo que você tenha feito seu próprio cliente Git e servidor web, isso não afeta a possibilidade de hackear, porque o formato do repositório Git não vai mudar
    • Vale lembrar que o Git já é composto por várias linguagens
      Segundo o GitHub, é 50% C, 38% Shell, 4% Perl, e o restante TCL/Python etc.
      Perl/TCL é que são mais excepcionais
      Conforme o projeto cresceu, acumulou muitos hacks espalhados, e agora chegou a hora de melhorar segurança/desempenho e limpar hacks antigos
      Considera Rust adequada para isso
    • Afirma que, para um engenheiro de software, saber lidar com várias linguagens é algo normal, então adicionar mais uma não é um grande problema
    • Diz que, entre os desenvolvedores jovens, inclusive ele, há muitos que preferem Rust e não querem aprender C
      Acha que o fato de o Git usar um pouco de Rust não vai atrapalhar o desenvolvimento de clientes ou servidores Git feitos por ele mesmo
  • Há um pedido para explicar melhor a opinião de que a adoção de Rust é impossível em algumas plataformas e difícil em outras
    • Em sistemas Linux, qualquer biblioteca deve ser usada como biblioteca de sistema, mas Rust não tem ABI estável, então não pode ser usada como uma biblioteca compartilhada de verdade
      As notas de lançamento do Debian também mencionam problemas relacionados a pacotes Rust/Go
      Ao compilar pacotes Rust, rebuilds frequentes são necessários por causa de problemas com linkagem estática, o que causa inconvenientes no uso prático
      Se o lado do Rust continuar ignorando a questão essencial de ABI estável/bibliotecas compartilhadas para sistemas Linux, isso pode acabar gerando mais reclamações do que C
      Acha que seria preciso mais cautela em arquiteturas de software de grande porte
    • Em plataformas proprietárias pouco visíveis, há suporte interno a compilador C, mas não é possível oferecer suporte a LLVM
      Se procurar pela palavra-chave NonStop neste artigo, verá um exemplo
    • É porque o compilador Rust não oferece suporte a certas plataformas (combinações de SO/arquitetura)
      Em grupos como o RESF, costuma-se dizer que “a plataforma não suporta Rust”, mas, na prática, o que precisa existir é suporte do compilador Rust para que funcione de fato
    • Como Rust é baseada em LLVM, ela é mais limitada do que as plataformas suportadas pelo GCC
    • Indica consultar a seção 'Tier 3' na lista de suporte de plataformas da documentação oficial do Rust
  • Pergunta que mudanças podem vir no git 3.0
    O git parece estabilizado na série 2.x, então não vê motivo para quebrar compatibilidade
  • No passado, assumia-se como premissa básica que build, execução e edição de código seriam diferentes em ambientes de cross-compilation
    Questiona se a cultura de desenvolvimento recente não se afastou desse tipo de uso de toolchain
    Controle de versão, build e ambiente de execução eram diferentes entre si, exigindo cópia remota ou execução remota, e as regras de build precisavam necessariamente detectar a plataforma de destino
    • Pelo contrário, considera que a toolchain do Rust torna cross-compilation mais fácil do que em qualquer outra linguagem compilada
      Com apenas a flag --target, é possível compilar para cerca de 100 plataformas sem grandes problemas
      Acha que o problema real é que parte dos desenvolvedores do Git insiste em manter as limitações de suas máquinas de desenvolvimento antigas/fixas
    • Acha que a maioria dos desenvolvedores simplesmente nunca aprendeu cross-compilation de verdade
      Cross-compilation sempre foi tratada como cidadã de segunda classe, e em projetos externos nem se espera que funcione direito
      Há distribuições Linux que, no caso de Raspberry Pi etc., só constroem no hardware real
      Por isso, ninguém se esforça de fato para dar suporte adequado a isso
    • Independentemente de Rust, o estado atual da cross-compilation é quase um “desastre”
      O Linux é especialmente problemático, porque a estrutura do glibc envelheceu a ponto de tornar difícil mirar até mesmo uma versão mínima de glibc em qualquer hardware
      A maioria dos projetos nem sequer tenta oferecer suporte a cross-compilation
      O Zig está tentando melhorar isso
  • Defende que seria melhor adiar a adoção até que o frontend Rust relacionado ao gcc esteja maduro o suficiente
    Como o Git é uma ferramenta central do projeto, vê risco alto na mudança e considera perigoso torná-la uma dependência obrigatória em um prazo curto, como seis meses
  • Diz que Rust, assim como linguagens funcionais, tem uma curva de aprendizado íngreme e é complexa
    Essa complexidade existe para capturar mais erros em tempo de compilação, mas, como resultado, a própria linguagem se torna bastante complexa
    Por isso, não recomenda sua adoção
    Também acha que o kernel rejeitou Rust pela mesma razão
    Acrescentar um sistema de tipos no nível de Haskell e um sistema de macros no nível de Lisp a um kernel já complexo aumentaria ainda mais a complexidade
    Rastrear código Rust via serde é difícil
    Em contraste, o Unmarshal do Go é muito mais fácil de rastrear
    • Eu, pelo contrário, acho linguagens funcionais e Rust mais claras do que C ou Go
      Isso porque elas permitem carregar mais informação no compilador
      Nunca tive grandes problemas com Serde; na verdade, já precisei depurar o Unmarshal do Go com mais frequência
      A alegação de que o kernel rejeitou Rust também não corresponde aos fatos; na prática, foi um conflito entre dois desenvolvedores sobre onde armazenar headers
    • C é simples, mas C seguro e com bom desempenho é extremamente complexo
      Rust tem uma barreira de entrada mais alta que C, mas a distância entre “o mínimo de Rust” e “Rust rápido e seguro” é muito menor do que em C
    • Dizem que Rust é complexa, mas apontam que C também está longe de ser simples
    • Essa conveniência das verificações em tempo de compilação é justamente o diferencial do Rust
      Consideram isso tão importante quanto o borrow checker
    • Para quem tem experiência com Typescript e já aprendeu com linters sobre referências ou desempacotamento de Result/tratamento de erros, Rust é relativamente fácil de aprender
      A sintaxe também é tolerante
      O kernel Linux, na verdade, não rejeitou Rust