Pensamentos sobre Rust 2019

Colegas, boa noite a todos!

Temos o prazer de oferecer uma tradução de um artigo verdadeiramente programático de Raf Levin , cujo trabalho titânico sobre o desenvolvimento da linguagem Rust evoca respeito e reverência:



Sem falsa modéstia e sem ódio, um autor respeitado de maneira objetiva e entusiasta respondeu ao apelo da comunidade Rust, publicado por referência no início deste artigo. Esperamos que tenha sido interessante e afirmativo.


Recentemente, a equipe principal do Rust propôs escrever artigos com opiniões sobre como o Rust deve crescer em 2019. Aqui está a minha opinião.

Ciclo de vida de amadurecimento

Neste artigo, considerarei o ciclo de vida do amadurecimento de uma forma extremamente simplificada. Deixe que ele consista em apenas três etapas: pesquisa, desenvolvimento, polimento. Os vários elementos do Rust diferem em seus diferentes graus de maturidade. É importante considerar isso ao tentar caracterizar com precisão o estágio atual do desenvolvimento da linguagem e, idealmente, para trazê-lo para o próximo estágio. Por exemplo, parece-me que o idioma está principalmente no estágio de "polimento". Se você persistir no fato de que a etapa de "pesquisa" ainda não foi concluída, a linguagem poderá ser enriquecida com tipos dependentes, estruturas virtuais etc., o que seria interessante, mas contraproducente. O inverso também é verdadeiro: não podemos formular exatamente o que nos falta na interface gráfica do usuário; portanto, tentativas prematuras de levar essas pesquisas a uma solução padrão provavelmente resultarão em resultados abaixo do ideal.

Em muitos produtos maduros, os lançamentos alternam, alguns dos quais dedicados à execução de novos recursos, enquanto outros são dedicados à sua estabilização. Por exemplo, esse é o sistema da Intel. As versões para Android de Kat Kit e Marshmallow eram estáveis, enquanto Lollipop estava trabalhando com pá). Em 2018, o Rust foi enriquecido com muitos recursos novos, então acredito que chegou a hora da fase de estabilização. Concordo com Jonathan Turner , assim como com muitos outros.

Linguagem de ferrugem

Eu acho que, em geral, a linguagem Rust está pronta. Parece que a comunidade concordou com a necessidade de “pousar” os recursos que ainda estão “on the fly” (em desenvolvimento): estamos falando de assíncrono / espera, const genéricos e um intérprete (que provavelmente nos fornecerá uma revisão tipos associados genéricos ). No entanto, acho que, além disso, não devemos ter muito zelo em encher o pipeline de novos recursos.

Mudança custa dinheiro. A partir de 2018, dois excelentes livros foram escritos sobre o Rust, mas ambos já estão um pouco desatualizados. As convenções para os caminhos qualificados diferem neles, agora usamos dyn Trait , etc. Quanto mais dinâmicas as alterações, mais inconvenientes para os usuários.

Existem muitos fatores que limitam o sucesso do Rust; Não acho que a maioria dessas deficiências seja inerente à própria linguagem.

Rigging

Um equipamento Rust poderia ter sido muito melhor. Eu experimentei o RLS, mas sempre retornava a um editor de texto comum e a um loop de linha de comando (para ser sincero, não defini esses experimentos recentemente). Penso que, a longo prazo, é necessário modificar significativamente as ferramentas Rust para pelo menos de alguma forma facilitar a curva de aprendizado. Tenho algumas idéias (espero que haja tempo para explicá-las com mais detalhes) sobre uma linguagem de efeito estufa, das quais não tenho certeza de onde é viável, onde não haveria diferença clara entre o valor e o link para ele, o valor poderia ser usado após a mudança etc. . Em princípio, essa linguagem permitiria que uma string fosse tratada como um número. O servidor aceita programas escritos nesse idioma, os corrige rapidamente e os converte em Rust completo.

Naturalmente, o RLS apenas metade corresponde a isso, os usuários interagem com ele através do editor. Trabalhar com o xi-editor é conveniente, embora geralmente exija alguma orientação e suporte. Este trabalho foi realizado por uma comunidade liderada por Colin Rofles e estou feliz em ver como esse editor melhora (ele já se tornou meu editor principal). Ele fornece suporte para o servidor de idiomas, além de novos recursos, por exemplo, um mecanismo de anotação geral, que será muito melhor finalizado em 2019.

Ecossistema de bibliotecas

O trabalho mais quente agora está em pleno andamento na criação de bibliotecas para o Rust. Abaixo, listo as coisas que pretendo fazer sozinho.

Um dos tópicos que gostaria de abordar é a “coerência”, que, na minha opinião, é um dos recursos mais valiosos do Rust, juntamente com o componente técnico do seu sistema de tipos . Muitos componentes do "mecanismo de jogo" no C ++ são uma seleção cuidadosamente preparada de bibliotecas que interagem bem entre si. Mas em Rust, muitas dessas coisas acontecem organicamente. Os contêineres geralmente são afiados para uso em pacotes configuráveis ​​e, se você usar corretamente coisas como, então, mais ainda está melhorando. Um exemplo particularmente convincente do segundo tipo é o mint , que garante a interoperabilidade de muitos contêineres matemáticos, embora as convenções usadas para definir os tipos de vetores não coincidam neles.

SIMD

Acho que as bibliotecas SIMD ainda estão sob investigação. Existem muitas bibliotecas de invólucros, cada uma das quais oferece uma perspectiva ligeiramente diferente e um conjunto diferente de trocas: simdeez , packages_simd , mais rápido e, é claro, meu próprio fearless_simd . Esses compromissos estão longe de serem incondicionais, porque alguns usuários precisarão reduzir todo o desempenho do idioma até a última gota e, se você se apegar a esses extremos, precisará recorrer às melhores instruções para processadores específicos. Outros apreciarão portabilidade e segurança.

Um dos erros SIMD mais importantes é que muito mais trabalho precisa ser feito no compilador, principalmente para interação com as arquiteturas AVX-512 e SIMX não x86. Também é possível que as bibliotecas de wrapper exijam algumas alterações no nível do idioma para tornar o trabalho o mais conveniente possível; Portanto, no momento, a incorporação e o cfg(target_feature = ...) interagem mal. Na minha opinião, essa é outra questão que requer pesquisa. É interessante entender até onde podemos ir sem suporte adicional no nível do idioma, e quais recursos exatamente ajudarão a aumentar fundamentalmente a conveniência de trabalhar com ele?

Áudio

Existem contêineres de áudio de baixo nível, entre os quais o cpal deve ser especialmente observado. No entanto, pode haver dificuldades no nível de desempenho (o contêiner nem sempre usa o fluxo em tempo real), algumas possibilidades. É necessário encontrar a maneira ideal: modificar o cpal ou desenvolver um novo contêiner que resolva problemas específicos. Para isso, em particular, você precisa examinar atentamente as bibliotecas C ++, por exemplo, RtAudio , que solucionam esses problemas também.

Para síntese de áudio de nível superior, tenho grandes planos para sintetizar-rs . Esta opção não é adequada para todos, mas acho que é uma boa base para uma variedade de técnicas de síntese e efeitos de áudio. Parece que hoje essa área de trabalho está entre as etapas de pesquisa e desenvolvimento.

Para acompanhar, confira o stream #synthesizer em nosso bate-papo do Zulip. Em novembro, dei uma palestra sobre isso, com base na qual pretendo escrever um post em breve.

GUI

As interfaces gráficas de usuário são atualmente um dos pontos mais fracos da Rust. Penso que em 2019 veremos muitos artigos sobre esse tópico na comunidade Rust.
Pessoalmente, parece-me que as GUIs de Rostov devem agora ser atribuídas à fase de "pesquisa". Muitas abordagens alternativas estão sendo elaboradas e, até o momento, não há consenso sobre qual delas é a melhor. Com que intensidade os gráficos 2D e outras primitivas da interface do usuário devem ser usados ​​na arquitetura do sistema ou devemos implementar essa pilha inteira por conta própria? A implantação na Web é necessária (usando wasm)? Todo o processo de programação deve ser percebido como "nativo da ferrugem" ou é melhor se adaptar às convenções estabelecidas em alguma GUI madura? A comunidade Rust possui recursos suficientes para criar um novo kit de ferramentas da GUI e, em caso afirmativo, vale a pena?

Comecei um projeto Druid para criar uma interface gráfica para o meu sintetizador e jogo, mas esse projeto é de pesquisa. Apresenta meu ponto de vista, minhas respostas a todas as perguntas formuladas acima e, na minha opinião, esse projeto está se desenvolvendo bem. Mas, repito, este é um projeto de pesquisa, e seria muito tolo nesta fase introduzi-lo em outros projetos.

Além disso, vários outros projetos de desenvolvimento de GUI estão em andamento. Na minha opinião, o mais promissor deles é o Azul , porque gosto do WebRender como base para criar uma GUI. Outro projeto muito promissor é o OrbTK , feito com base no Redox, mas multiplataforma e realmente avançado. Você pode aprender muito com os exemplos de Conrod , ggez , bem como os wrappers de ferramentas de outros idiomas.

Sem surpresa, a atividade de desenvolvimento de GUI mais intensa do Rust está intimamente relacionada aos jogos, e parece-me que isso é bom. As inovações se enraízam melhor no segmento de jogos, e a necessidade de ferramentas maduras não é tão aguda aqui. Mas, assim que aparecer uma excelente abordagem para a implementação da GUI no Rust, acho que ela encontrará a aplicação mais ampla. Também observo que meu Druid se originou com base no nível da GUI do editor de clientes xi para Windows .

Marcação

A biblioteca pulldown-cmark é usada muito bem, principalmente para o rustdoc, mas é preterida em alguns aspectos. Sua evolução não acompanha o desenvolvimento da especificação CommonMark. Uma das razões pelas quais ficou um pouco preso é com o algoritmo de análise; Eu já tenho uma idéia de como escrever um novo algoritmo para esse fim, muito melhor do que antes; mas ainda não resolvi os detalhes. Recentemente, voltei a este trabalho e estou me preparando para lançar um algoritmo. Quando o ramo new_algo adicionado ao master, acho que a comunidade deve continuar seu desenvolvimento, enriquecendo-o com novos recursos. Estou pensando em compatibilidade total com GFM, matemática e talvez algo assim.

Obrigado a todos da comunidade Rust por finalizarem o idioma com o qual gosto de viver.