Reescrevendo Rust

Reescrevendo Rust

• A linguagem de programação Rust parece um produto de primeira geração
• O apelo inicial de Rust: tipos algébricos, segurança de memória, sem perda de desempenho, gerenciador de pacotes moderno
• Após 4 anos de uso, Rust nem sempre é perfeito
• A evolução da linguagem ficou muito lenta
• Muitos recursos instáveis não foram incluídos no Rust estável

Uma linguagem fantástica

• Quero fazer um fork do compilador de Rust e criar uma nova edição chamada "seph"
• Seria possível manter os recursos existentes de Rust enquanto se adicionam novos recursos

Traits de função (efeitos)

• Rust define traits para structs, mas também precisa definir traits para funções
• Isso permitiria representar várias características de funções
  • se a função entra em pânico ou não
  • se tem um tamanho de pilha fixo ou não
  • se a função executa até o fim ou se fica em espera no meio do caminho
  • se a função é pura
  • se a função executa código inseguro
  • se a função garante término

Recursos em tempo de compilação

• Muitos projetos em Rust usam muitos crates de terceiros
• Esses crates aumentam o risco da cadeia de suprimentos
• Há a proposta de adicionar um recurso que exija permissão explícita para chamadas de funções sensíveis à segurança
• Para chamar recursos como fs_write, seria necessário permitir isso explicitamente

Pin, Move e empréstimo de structs

• Pin é um hack complexo para resolver problemas do borrow checker de Rust
• Em vez de Pin, faz mais sentido usar uma marker trait Move
• Há a proposta de adicionar uma sintaxe para marcar campos de structs como em estado de empréstimo
• Propõe-se introduzir a marker trait Move e a trait Mover

Tempo de compilação

• Introduzir o recurso comptime de Zig para substituir a linguagem de macros de Rust
• Adicionar um pequeno interpretador capaz de executar código em tempo de compilação
• Usar o próprio Rust em vez da linguagem de macros de Rust

Pequenos ajustes

• Corrigir impl<T: Copy> for Range<T>
• Corrigir derive com tipos associados
• Suportar AND lógico em expressões if-let
• Melhorar a usabilidade de ponteiros brutos
• Adicionar um argumento Allocator a todos os tipos de coleção embutidos

Considerações finais

• Os recursos assíncronos também precisam de melhorias, mas isso exigiria um post separado
• A maioria das mudanças não é compatível com o Rust existente
• Pode ser necessária uma nova edição de Rust
• Estou considerando fazer um fork do compilador diretamente, em vez de me cansar ainda mais com o processo de RFC no GitHub

Resumo do GN⁺

• Rust não é perfeito, apesar do apelo inicial
• A evolução da linguagem ficou lenta, e muitos recursos instáveis não foram incluídos no Rust estável
• Há várias propostas, como traits de função, recursos em tempo de compilação e melhorias em Pin e Move
• Essas propostas podem melhorar bastante a usabilidade de Rust
• Zig é outra linguagem com recursos semelhantes

[GN⁺]

Comentários do Hacker News

• Opinião sobre o processo de RFC do Rust

  • É uma decisão correta a equipe central do Rust dificultar a adição de novos recursos para manter a consistência e a previsibilidade da linguagem
  • No caso do Swift, a introdução de muitos recursos novos o tornou complexo, e isso acabou levando ao abandono do Swift
  • É importante manter o Rust o mais enxuto possível

• Problema de dependências no Rust

  • Usando o crate Cargo-watch como exemplo, embora seja um aplicativo simples de monitoramento de arquivos, ele chega a 4 milhões de linhas de código por causa das dependências

• Estado atual do Rust

  • O Rust agora está na fase de "trabalho para adoção ampla"
  • O desenvolvimento lento de recursos é um fenômeno natural e saudável, e escolhas de design erradas podem causar danos maiores
  • O apelo do Rust está menos em novos recursos e mais em ser uma linguagem pronta para produção, com segurança de memória e sem GC

• Opinião sobre reescrever Rust

  • Reescrever Rust em Rust pareceu uma piada meta-satírica

• Insatisfação com o processo de decisão do Rust

  • Há reclamações sobre a lentidão no processo de decisão, mas isso é mais um problema de pessoas e tempo do que uma questão técnica
  • Alguns recursos antigos estão parados, mas muitos recursos não estão destinados a ser estabilizados

• Comentário de Josh Triplett

  • Ele apontou que um exemplo específico estava errado e compartilhou links relacionados

• Opinião sobre a complexidade do Rust

  • O Rust já tem muitos recursos, mas ainda há pessoas pedindo mais
  • Zig é mais simples, mais rápido e tem menos drama na comunidade

• Opinião sobre a velocidade do Rust

  • À medida que o projeto amadurece, é necessário muito esforço para refinar os recursos existentes
  • A colaboração entre equipes ficou mais difícil, e há metas de projeto para melhorar isso

• Opinião sobre melhorias em Mutex

  • Houve muito esforço para melhorar os primitivos de sincronização do Rust
  • Recursos como funções assíncronas foram adicionados, servindo de base para implementar funcionalidades mais complexas

• Opinião sobre a velocidade de desenvolvimento de recursos no Rust

  • Há pessoas que reclamam que a linguagem evolui rápido demais ou devagar demais
  • Alguns recursos avançam lentamente, mas muita atividade está em andamento

• Opinião sobre o design de recursos do Rust

  • Recursos como function traits passaram recentemente por uma grande exploração de design
  • Recursos de tempo de compilação não podem ser resolvidos no nível da linguagem, e soluções como WebAssembly parecem mais prováveis

• Problema do borrow checker no Rust

  • Entender estruturas autorreferenciais é um problema extremamente difícil
  • Já se sabe como oferecer suporte a empréstimos parciais, mas o problema é expor isso ao sistema de tipos

• Recursos de tempo de compilação no Rust

  • Foi escrito um RFC para tornar as regras de macro mais poderosas
  • É necessário mais trabalho para análise sintática programática

• Recursos instáveis do Rust

  • Há muitos recursos instáveis, e é necessário organizá-los

• Opinião sobre a velocidade de evolução do Rust

  • A saída da Mozilla desacelerou o projeto, mas isso ainda é melhor do que seguir pelo caminho errado