Vinte anos não são nada

Linguagens de implementação e “escrito em Rust”

• Debate recorrente sobre por que projetos anunciam “escrito em Rust”.
• Os defensores dizem que a escolha da linguagem sinaliza:
  • Segurança de memória e velocidade sem GC.
  • Binários estáticos e autocontidos, além de ferramentas fluídas.
  • Uma cultura de desenvolvimento que se importa com correção e desempenho.
• Os céticos veem isso como marketing fraco: se “escrito em Rust” é a manchete, talvez haja pouco mais para diferenciar.
• Alguns observam que a linguagem é preditiva do estilo do projeto e do encaixe no ecossistema (por exemplo, é mais fácil contribuir se você conhece Rust/Go do que Python).
• Críticas a Python/JS por desempenho e estabilidade de longo prazo; Go é citado como semelhante ao Rust na distribuição, mas não nas garantias de tipo/propriedade.

Pijul, VCS baseado em patches e ideias de CRDT

• Pijul e Fossil são destacados como verdadeiras alternativas ao Git, com designs diferentes; jj e Sapling são vistos mais como interfaces aprimoradas para Git/Mercurial.
• O autor do Pijul explica:
  • O design é baseado em patch/CRDT; conflitos fazem parte do modelo.
  • As estruturas de dados foram projetadas “como teóricos”, depois otimizadas.
  • Um armazenamento customizado key–value em Rust (Sanakirja) permite armazenamento rápido, genérico, amigável a mmap e bifurcação eficiente, superando o LMDB nos testes deles.
  • Rust foi escolhido pragmaticamente pelo controle de baixo nível sem a dor de depuração do C++; hoje talvez escolheria Zig por causa da evolução da linguagem.
• Alguns argumentam que VCS baseados em patches podem ser mais rápidos do que o Git baseado em snapshots para repositórios grandes, conflitos, blame e arquivos binários.

Pontos fortes, fracos e fluxos de trabalho do Git

• Amplamente elogiado por:
  • Velocidade em comparação com ferramentas mais antigas.
  • Fluxo de trabalho distribuído e commits offline.
  • Flexibilidade e modelo de dados poderoso.
• Críticas:
  • A UX do CLI é confusa; conceitos vazam a implementação interna.
  • Rebase, reescrita de histórico e fluxos com commits empilhados são difíceis; ferramentas como Gerrit/Graphite/jj tentam mitigar isso.
  • O Git armazena snapshots, não histórico explícito de mudanças; renomeações/divisões de arquivos e grandes refatorações são difíceis de rastrear.
  • Não há diretórios vazios; o histórico de divisões/fusões de arquivos e movimentos semânticos é fraco.
  • Git LFS é visto por alguns como frágil e operacionalmente complicado.

Centralização, tamanho do histórico e clones parciais

• Debate sobre se clones locais com histórico completo eram “impensáveis” há 20 anos; alguns lembram de CVS/SVN junto com scripts locais e discos suficientemente grandes, enquanto outros enfatizam as limitações de rede e armazenamento da época.
• O ponto de que DVCS implica um limite prático: o histórico do repositório precisa caber no menor laptop de desenvolvimento.
• Alguns argumentam que a maioria das organizações é, de fato, centralizada e se beneficiaria de clones hierárquicos/subordinados: histórico parcial, árvores parciais, mas ainda com branching e commits locais.
• Recursos mais recentes do Git como partial clone e sparse-checkout são mencionados como soluções parciais.

Ativos binários e projetos não textuais

• O modelo centrado em texto do Git funciona bem para a maior parte do software, mas:
  • Jogos, design de chips e pipelines de mídia ainda preferem Perforce ou SVN devido a binários grandes.
  • Git LFS é criticado por ser bugado, operacionalmente complexo e exigir componentes extras de servidor.
  • Há desejo por um VCS que entenda nativamente formatos binários (por exemplo, diffs semânticos para imagens) e armazenamento de arquivos grandes; o Pijul afirma ter suporte binário nativo.

Futuros semânticos, com AST e baseados em CRDT

• Vários comentaristas sugerem:
  • Controle de versão sobre ASTs ou estruturas específicas do domínio em vez de texto bruto.
  • Diffs/conflitos melhores que entendam movimentos, renomeações e refatorações.
• Uma proposta: um sucessor do Git que armazene históricos em CRDT no nível de caractere, suportando colaboração em tempo real e commits semânticos; questões em aberto incluem como expor conflitos e como apagar dados (segredos).
• Outros argumentam que essa granularidade pode adicionar ruído e complexidade; commits como pontos de verificação escolhidos por humanos continuam valiosos.

Ferramentas históricas e perspectiva

• Muitas reminiscências de VSS, ClearCase, Perforce, CVS, SVN, RCS, BitKeeper e versionamento ad hoc com zip/tar.
• Sistemas centralizados baseados em lock (VSS, algumas configurações de ClearCase/Perforce) são lembrados como dolorosos, embora já tenham sido considerados “profissionais”; fluxos de trabalho open source com CVS/SVN eram vistos como mais avançados do que os de muitas empresas.
• A sensação geral é que cada geração achou suas ferramentas boas até que o próximo grande salto (SVN, depois Git/DVCS) expôs seus limites.

Algo vai substituir o Git?

• Alguns acham que o Git é um platô evolutivo; sucessores precisariam de:
  • Compatibilidade total com Git e uso transparente em repositórios existentes.
  • UX mais simples e semântica melhor (renomeações, operações com AST, commits empilhados).
  • Melhor suporte a repositórios grandes e binários.
• Outros esperam deslocamento eventual, citando a longa história de renovação dos VCS; ainda assim, os efeitos de rede do Git e seu status de “bom o suficiente” podem mantê-lo dominante por muito tempo.