Conforme solicitado, aqui estão minhas sugestões para o desenvolvimento do Rust a partir de 2019.

Devo dizer que falo apenas por mim e não sou nem um participante muito ativo no projeto. Além disso, essas propostas estão relacionadas, em grande parte, a muitos projetos. A ferrugem é um caso especial, mas é ele quem agora leva a alguns pensamentos.

Devo também observar que, em geral, estou satisfeito com o desenvolvimento do Rust, e esta proposta é feita apenas para manter uma maior prosperidade, a fim de evitar alguns dos problemas que agora observo de fora.

TL; DR: É importante reconhecer o problema e planejar mecanismos explícitos para limitar o crescimento de duas coisas:

1. Artefatos técnicos gerais obrigatórios, especialmente a própria definição de um idioma.
2. A carga sobre as pessoas envolvidas na discussão desses artefatos.

Em particular, quero chamar a atenção para a impossibilidade e indesejabilidade do crescimento ilimitado em ambas as direções. Existem limites naturais. Como em todos os sistemas naturais que atingiram os limites do crescimento, é melhor se preparar para esse evento e conduzi-lo de maneira controlada e planejada.

Observe que não estou escrevendo sobre os limites de crescimento de muitas outras áreas. Por exemplo, um índice de pacote, tamanho do site ou até uma comunidade de usuários. Não está claro que tipo de ameaça isso representa para o Rust; portanto, estamos falando apenas de dois problemas específicos acima.

Fatores limitantes e vôo

Todo sistema natural tem limites para o crescimento. É por isso que o Universo não é (por exemplo) uma única ameba que se expande à velocidade da luz. O sistema cresce (e geralmente a velocidade de expansão também aumenta!) Até encontrar fatores limitantes e, gradualmente, o crescimento diminui até que o tamanho geral do sistema atinja um platô. Os padrões de crescimento típicos neste caso parecem aproximadamente com uma sigmoide ou uma “curva em forma de S”, aproximando-se gradualmente de algumas assíntotas. Pelo menos se os fatores limitantes ocorrerem gradualmente e de maneira controlada.



Quando um sistema encontra um limite de maneira descontrolada ou repentina , pode ocorrer um fenômeno que se parece mais com o vôo de um alvo ou mesmo com um retorno: o limite ainda existe, mas seu efeito é mais como um colapso ou crise. A curva S aumenta para um pico, seguida por um colapso. Eu gostaria de evitar isso.

Bons exemplos de controle

O projeto Rust possui várias formas de controle de processo que essencialmente limitam a taxa de mudança e / ou crescimento. Penso que estas medidas são muito razoáveis: em parte graças a elas, o projeto ainda é bem sucedido. Por analogia com eles, quero formular as seguintes recomendações. Formas atuais de gerenciamento:

• A fila Bors ignora as alterações de correção do programa.
• A cratera pula os lançamentos de correção do ecossistema.
• É preferível que releases planejados sejam lançados no prazo, mesmo que o recurso planejado não esteja pronto. A decisão é tomada dentro do prazo e tudo o que não está preparado é cortado.

Além disso, estruturas sociais importantes foram criadas dentro do projeto para limitar o número de participantes do projeto.

• Código de Conduta . Nem todo mundo se lembra, mas ele não apenas postula justiça social e assim por diante. Ele também define limites na relação sinal-ruído nas conversas, exploração da atenção e do tempo de outra pessoa e busca compromissos (afinal de contas, nem todas as decisões dão valor zero).
• Processo RFC . Regras sobre forma, conteúdo, época, recrutamento de participantes, formas de discurso permitidas e esperadas ao discutir mudanças significativas.
• Modelo de gestão . Delineamento de responsabilidades, delegação hierárquica, quando necessário, funções e expectativas dos participantes e assim por diante.

Tudo isso, em essência, é o reconhecimento de que, na ausência de controle, problemas e crises podem ocorrer: pelo menos caos e disfunções em certa medida. Se possível, o controle é automático e completamente imparcial (para minimizar a má vontade e a avaliação subjetiva, a tentação de cortar custos, etc.) Se a subjetividade não puder ser evitada, pelo menos as regras e os processos serão claramente formulados por escrito, em locais bem documentados e bem conhecidos. .

Áreas problemáticas

Voltemos a duas áreas problemáticas em que o projeto atualmente não possui mecanismos ou políticas adequadas para controlar o Rust, o que acarreta os riscos de uma possível disfunção ou mesmo crise. Em ambos os casos, não está totalmente claro até que ponto o projeto está agora de tal crise. Mas, em qualquer caso, é melhor agir com antecedência do que chegar atrasado.

1. A própria linguagem . Sua definição. Este (diferentemente de muitas partes do projeto) é um artefato técnico comum obrigatório . Todo mundo está interessado nele, e cada mudança afeta potencialmente a todos. Além disso, todos devem estudar e entender sua parte essencial: é impossível ignorar partes desinteressantes. Até o que você deseja ignorar existe em um contexto geral: materiais de documentação e treinamento, exemplos e materiais de teste, componentes internos do compilador, modelos formais, bases de código, carga geral de manutenção, etc.
   
   Aqui, o crescimento da linguagem como um artefato é limitado pelo menos pelos seguintes fatores:
   
   
   • Uma oportunidade para um iniciante aprender um idioma.
   • A capacidade do usuário médio de se sentir confiante, se adaptar às bases de código de outras pessoas.
   • A capacidade de um especialista ou mantenedor de conhecer todas (ou a maioria) mudanças.
   • A proporção de custos e benefícios de cada nova mudança em termos de trabalho novo e em andamento. O número de pessoas ou casos de uso que se beneficiam dele. Os custos são combinatórios em muitas dimensões de design e tamanho da linguagem. Eles quase sempre aumentam.
   
   Se você não cumprir esses limites, poderá enfrentar riscos muito sérios:
   
   
   • Alterações de idioma irracionais, até a incapacidade de manter garantias críticas de segurança.
   • Reputação de complexidade excessiva, perda de usuários. Risco de se tornar o próximo C ++ ou Haskell.
   • Funções de baixa qualidade com definição incompleta, testes, documentação.
   • Recursos subutilizados que levam o esforço necessário para outro lugar.
   • Esmagando em dialetos, programas isolados, redução de valor.
2. O fardo para as pessoas que trabalham no idioma. Algumas partes do projeto podem ser delegadas, distribuídas entre todos os desenvolvedores disponíveis. Esses não são artefatos técnicos comuns. Até certo ponto, muitas pessoas (e mais e mais) precisam participar de quase todas as mudanças. Isso significa muita pressão sobre todos neste grupo: eles devem acompanhar todas as discussões, e o número de mudanças e o número de participantes nas discussões estão crescendo.
   
   Algumas restrições ao crescimento dessa carga para os participantes do projeto:
   
   
   • O número de horas por dia.
   • O número de horas pagas por dia.
   • Responsabilidade e interesses fora do projeto.
   • Uma reserva de energia mental para entender o que está acontecendo.
   • Confiança na opinião de todos os envolvidos na conversa.
   • Uma reserva de energia psicológica e emocional para leitura e discussão.
   • Presunção de boa fé de todos os envolvidos na conversa.
   
   Os riscos de exceder esses limites também são potencialmente muito graves:
   
   
   • Más decisões tomadas devido à exaustão ou esgotamento.
   • Desigualdade crescente: apenas os participantes mais privilegiados, acessíveis, enérgicos, bem pagos ou de outra forma bem organizados podem acompanhar tudo.
   • Limitando o discurso: da consideração cuidadosa à “vitória em uma disputa”.
   • As pessoas brincam, se esgotam, se comportam mal, deixam o projeto.
   • Desapontamento, acusação de desonestidade, ressentimento, pensamento conspiratório, garfos.
   
   Quero enfatizar que as limitações e riscos descritos não são completamente específicos para pessoas específicas ou mesmo para o projeto Rust como um todo. Em um grau variável, eles são encontrados em qualquer lugar. Simplesmente substituir os mantenedores atuais (por exemplo) por aqueles que você gosta realmente não resolverá o problema: as restrições permanecerão. A única solução é o gerenciamento cuidadoso em uma colisão com um limite. Assuma o controle.

Possíveis opções de controle

Esta é a parte difícil, onde tentarei evitar uma linguagem clara. No final, é importante assumir o controle do próprio livre arbítrio, e não imposto de fora. Eu acho que os participantes do projeto devem pausar, refletir, considerar coletivamente e estabelecer alguns controles. Portanto, vou oferecer apenas várias opções possíveis, não muito estruturadas, mas com um espírito festivo de Natal: como um monte de presentes potencialmente interessantes para desembrulhar, ver e decidir, sair ou trocar por algo mais interessante.

1. Espaço definido negativamente . Tome o processo de discutir funções e conceitos de planos para o desenvolvimento futuro da linguagem. Permita (ou incentive) as RFCs que dizem "Rust nunca terá X" por algum valor de X. Portanto, temos uma rodada única para uma discussão justa e consideração das objeções à mudança a longo prazo ("nunca" é muito tempo!). Então essa discussão terminará para sempre. Não se tornará uma fonte eterna de conflitos prolongados. Alguns exemplos em que os espaços negativos são definidos:
   
   
   • remover permanentemente determinadas categorias de expressividade do sistema de tipos (por exemplo, tipos dependentes, HKT etc.);
   • da sintaxe (por exemplo, chaves de parâmetro, argumentos posicionais ou nomeados);
   • de um conjunto de visualizações de elementos (por exemplo, tipos de postagem anônima);
   • de um conjunto de obrigações de saída até o ponto intermediário (por exemplo, síntese de constantes, argumentos implícitos).
   
   Defina algumas restrições rígidas: para evitar esses objetos, bem como as pessoas que estabelecem o objetivo de "fazer tudo certo".
2. Os custos de desenvolvimento precisam ser explicitamente declarados. Tomando uma página da lista de alterações no WebAssembly, deixe claro que, em um estágio inicial, essa RFC exigirá investimentos apropriados na implementação, formalização, revisão de documentação, revisão de materiais de treinamento, testes de gravação, manutenção, etc. Se os custos não puderem ser cobertos, nesse estágio adiar as alterações "até que um patrocinador seja encontrado".
3. Estabeleça metas para aprender velocidade e volume de material . Tente trabalhar na direção oposta: proceda da quantidade de tempo e do número de páginas necessárias para aprender o idioma ou se tornar um especialista nele - e exclua tudo o que estiver além dessa estrutura. Se "aprender a ferrugem em 21 dias" não funcionar, encontre o intervalo certo. Três meses? Seis? Ano? Pense em idiomas cujo aprendizado “definitivamente leva muito tempo” e escolha um número menor. O manual de 1000 páginas está ok? 500? 300?
4. Defina outros limites automáticos : o número de linhas de código no compilador, o tempo total de carregamento, dólares por dia para instâncias da AWS, o número de regras na gramática, no sistema de tipos, a porcentagem de cobertura de teste, a porcentagem de documentos que podem ser marcados como "incompletos" etc. Seja criativo, descubra as coisas relevantes que são mensuráveis ​​e implemente mecanismos para limitá-las.
5. Limite de tempo pessoal : quantas horas aproximadamente (ou tempo pago) uma pessoa pode realmente dedicar a um projeto sem exaustão ou exaustão, incluindo participantes com direitos mínimos. Defina restrições semelhantes para grupos, liberações individuais e planos de trabalho relacionados. Em seguida, remova ou adie tudo o que não se encaixa no limite.
6. Permita que os moderadores estabeleçam limites para a frequência de postagens ou estabeleçam períodos de silêncio em discussões específicas. Às vezes, de fora, parece que a discussão é muito quente. Para a diminuição do conflito, é mais fácil estabelecer um limite comum do que aplicar sanções a participantes individuais.
7. Assim como os moderadores: crie uma equipe adicional entre projetos que esteja envolvida no orçamento e na auditoria dos níveis de carga em outras equipes . Pode ser eficaz: a equipe de auditoria ajudará as pessoas a dizer não quando necessário e a não suportar, como a maioria dos membros da equipe, concordando demais.

Essas são apenas algumas idéias na direção geral das restrições de crescimento. Tenho certeza de que você pode encontrar maneiras mais realistas de controlar as restrições ao tamanho do idioma e às cargas pessoais. Ao longo dos anos, a comunidade Rust provou ser deliciosamente criativa, consciente e autocrítica. Você deve ser elogiado por isso. Espero que este artigo seja aceito no mesmo espírito de crítica construtiva.

Feliz Ano Novo e boa sorte!