O que significa o fato de o Ubuntu usar Rust?

• A adoção de Rust pelo Ubuntu mostra que, no ciclo de adoção de tecnologia, Rust está saindo dos early adopters, atravessando o abismo e chegando ao mainstream
• A Canonical adotou Rust como a linguagem padrão para novos softwares de base, substituindo usos de C, C++ e parte de Python, e está investindo no desenvolvimento de utilitários com segurança de memória tanto financeiramente quanto em reputação
• Como os usuários da maioria inicial (Early Majority) querem "padrões da indústria" e compatibilidade com fluxos de trabalho existentes, a substituição de utilitários em modo drop-in é a estratégia central para atravessar o abismo
• A questão da expansão da biblioteca padrão de Rust voltou a ganhar destaque, e há uma reavaliação de que o conceito de "Rust Platform", rejeitado em 2016, talvez seja mais adequado para a maioria inicial
• Uma estrutura que converta adoção em investimento e a inclusão baseada em empatia na comunidade open source são essenciais para a próxima fase de crescimento de Rust

---

A travessia do "abismo" de Rust varia conforme a área

• Se Rust já atravessou o abismo no Technology Adoption Life Cycle depende da área
• Dentro da Amazon, Rust já está firmemente estabelecido em grandes data planes e na construção de agentes com consciência de recursos, mas ainda existe a percepção de que ele é excessivo para desenvolvimento geral
• Na área de Safety Critical Software, há casos de sucesso, mas a maior parte do setor ainda permanece em modo de "esperar para ver"

A importância de "clientes de referência"

• O ponto-chave para atravessar o abismo é garantir clientes de referência (reference customers)
• Adotantes iniciais compram o agente de mudança (change agent), mas a maioria inicial quer aumentar a produtividade das operações existentes e minimizar descontinuidades
• Ver organizações parecidas com a sua tendo sucesso é o fator mais convincente para a adoção de uma nova tecnologia
• O sucesso de Rust na equipe do S3 é convincente para equipes de serviços em larga escala, mas tem pouca força persuasiva direta para equipes de serviços CRUD

A estratégia de adoção de Rust no Ubuntu (Canonical)

• No Rust Nation, o VP of Engineering da Canonical, Jon Seager, apresentou a keynote "Rust Adoption At Scale with Ubuntu"
• A Canonical vinha limitando suas linguagens internas de desenvolvimento a Python, C/C++ e Go, mas recentemente adicionou Rust e o adotou como linguagem padrão para novos trabalhos de base
• De forma semelhante à keynote de Lars Bergstrom sobre a adoção de Rust no Google, trata-se de uma abordagem que combina visão e pragmatismo
  • Essa é exatamente a característica necessária para a transição de adotantes iniciais para a maioria inicial

Investimento em utilitários com segurança de memória

• Jon Seager mencionou que o Ubuntu deve apoiar a criação de utilitários baseados em segurança de memória no espírito de "pay it forward"
• A Canonical está financiando o desenvolvimento de sudo-rs e ntpd-rs da Trifecta Tech Foundation, além do trabalho de coreutils do uutils
• A estrutura permite que o Ubuntu experimente e valide novidades primeiro, para que depois outras distribuições também se beneficiem
• Utilitários drop-in que entram diretamente nos fluxos de trabalho existentes atendem à exigência da maioria inicial de minimizar descontinuidades

Exigências dos novos adotantes: expansão da biblioteca padrão

• Durante um jantar, Jon Seager comentou que a política de biblioteca padrão pequena de Rust deveria ser reavaliada
• Essa é uma demanda recorrente há anos e, em vez de simplesmente oferecer uma biblioteca padrão maior, está-se considerando uma alternativa em formato de projeto chamada "Battery Packs"
• A Rust Platform, proposta em 2016 — a ideia de reconhecer certos crates como uma biblioteca padrão expandida — foi rejeitada pelos adotantes iniciais da época, mas agora está sendo reavaliada como algo possivelmente adequado para a maioria inicial
  • Na época, prevalecia a visão de que bastava adicionar dependências ao Cargo.toml

A necessidade de mudança para crescer

• Para passar de adotantes iniciais para a maioria inicial, é preciso comunicar Rust não como "estado da arte (state-of-the-art)", mas como "padrão da indústria (industry standard)"
• Rust foi bem-sucedido em conquistar reconhecimento no setor, e agora precisa ser a melhor escolha com base não no "que pode vir a ser", mas no "que de fato é"
  • Essas duas coisas às vezes podem entrar em tensão
• Fazer marketing para pragmáticos exige paciência, compreensão dos problemas do setor em questão e participação em conferências da indústria

Uma estrutura que converte adoção em investimento

• A ampliação da adoção de Rust traz consigo um aumento da demanda sobre o projeto Rust e seu ecossistema
• Para organizações open source como a Canonical, construção de relações entre organizações e contribuição importam mais do que $$
  • Os desenvolvedores de Rust for Linux inicialmente receberam ajuda dos mantenedores de Rust, mas gradualmente passaram a corrigir bugs diretamente, enquanto os mantenedores migraram para um papel de mentoria
• Uma tendência interessante é que o financiamento muitas vezes vem mais de empresas que estão considerando adotar Rust do que das que já o adotaram
  • Early adopters individuais dentro da organização impulsionam a adoção interna e alocam orçamento para desenvolver funcionalidades de "table stakes"
• Segundo Alexandru Radovici, do Rust Foundation Silver Member Directory, várias empresas de software crítico para segurança têm recursos para financiar o preenchimento das lacunas de Rust, mas não sabem como usá-los

O papel do open source e a importância da empatia

• O open source é uma excelente plataforma para atravessar o abismo, mas panelinhas (cliques) e "tradições orais (oral traditions)" podem se tornar barreiras de entrada
• Uma ideia pode ser rejeitada pelo uso de terminologia errada, e uma única resposta rude pode fazer um novo colaborador desistir
• O que Rust mais precisa para sua próxima fase de crescimento é empatia no open source (Empathy in Open Source)
• O essencial é ir até onde Rust pode ajudar as pessoas, oferecer apoio e capacitá-las

[GN⁺]

Comentários do Hacker News

• O fato de o Ubuntu usar um userland com licença que não é GPL pode significar permitir mais TiVoization no ecossistema Linux
  Se isso se combinar com a direção que a Amutable, do campo do systemd, está tomando, pode surgir uma distribuição Linux fechada em que o usuário não consegue modificar nada
  Do ponto de vista das empresas, um ambiente fechado com verificação completa de assinaturas pode ser atraente. Um mundo em que até “ls” e “cd” sejam closed source tem um ar estranhamente apocalíptico

  • util-linux e BSD não vão desaparecer. Se você não gosta do Ubuntu, é só não usar. O Debian sempre foi muito mais estável
  • Na verdade, existe um motivo para ter sido chamado de GNU/Linux. Android/Linux também não usa userland GPL, e a maioria dos concorrentes embarcados também não. No fim, Linux é só o kernel
  • Historicamente, talvez eu esteja sendo ingênuo, mas não acho necessariamente que essa mudança seja ruim. Eu prefiro utilitários open source, mas acho aceitável que existam alternativas fechadas que sigam as especificações. As empresas podem fazer isso e ainda assim investir mais dinheiro em projetos open source
  • Sinceramente, o Ubuntu parece a Apple do Linux, vencendo mais pelo marketing do que pela qualidade. A família Debian é usada porque o custo de manutenção é baixo, e eu pessoalmente acho que Fedora e OpenSUSE são o futuro
  • Se uma mudança assim fizer com que 95% dos usuários de Linux acabem usando o mesmo SO, talvez isso não seja tão ruim assim

• O verdadeiro abismo (chasm) que o Rust precisa atravessar é o suporte a linking dinâmico com ABI segura
  Só quando for possível alterar uma biblioteca e manter a segurança, com estabilidade de ABI no nível de C, o pessoal de C/C++ poderá adotar Rust de verdade

  • Rust já consegue se comunicar por ABI de C. Ele oferece linking dinâmico em nível equivalente ao do C++
  • A estabilidade de ABI do C++ é um dos principais fatores que travam a evolução da linguagem. Não dá para mudar o layout de classes da STL, e templates implementados em headers também ficam difíceis de otimizar depois. O Rust não deveria suportar esse tipo de “ABI estável”
  • A eficiência do Rust depende da monomorfização em tempo de compilação. Para criar uma ABI, seria preciso considerar especialização em tempo de link. Não é só empurrar a geração de código para o linker; é preciso tratar com cuidado a “forma (shape)” dos parâmetros de função
  • Linking dinâmico também ajuda a reduzir o tempo de compilação em builds de debug. Bibliotecas que não mudaram não precisam ser recompiladas, e o overhead em runtime é mínimo
  • É uma pena que a comunidade Rust prefira MIT à GPL. A GPL é amigável ao usuário, enquanto a MIT é amigável às empresas. Acho problemático que o movimento “Rewrite-it-in-Rust” esteja mais focado em espalhar a linguagem do que em proteger o usuário

• Mais problemático do que o Ubuntu adotar Rust é o fato de ele ainda usar scripts curl|bash para builds importantes
  Isso fica claro no snapcraft.yaml do firefox-snap

  • Quando se fala em “curl|bash”, normalmente se pensa em alterações aleatórias de configuração ou em mexer no .bashrc, mas aqui estamos apenas falando de executar um script de instalação de toolchain estática. É um método bem anos 90, mas relativamente seguro
  • Há muitas distribuições com versão de Rust antiga demais. O Rust do Debian ou do Ubuntu LTS é uma versão ultrapassada, então parece que eles não gostam de linking estático
  • Mesmo executando algo via curl, desde que a verificação de hash seja bem feita, tudo bem

• O fato de o projeto Rust Coreutils ter licença MIT me incomoda
  A filosofia da FSF às vezes é criticada, mas a GPL protege o open source. Se a Canonical mudar o Ubuntu inteiro para MIT, não sei o que pode acontecer

  • A GPL era poderosa antigamente, mas agora, graças a sistemas automáticos de lavagem de copyright, ela frequentemente acaba convertida em código MIT/BSD ou proprietário. A FSF também não tem solução
  • Discussões sobre licença nunca terminam. A GPL restringe a adoção, mas a MIT é mais flexível. No fim, tudo depende de qual é o objetivo — você quer OSS que todos possam usar, ou quer impedir que empresas lucrem sem contribuir?
  • Fico curioso sobre quais “más ações” concretas se tornam possíveis só porque o Coreutils passou a ser MIT

• Por causa do rust-coreutils, não foi possível instalar o CUDA Toolkit. Há uma issue relacionada no fórum da NVIDIA

  • Pelo tópico linkado, parece que era um problema relacionado ao gzip. Não parece ter sido por causa do dd
  • Sinceramente, rust-coreutils não tem razão de existir. Depois de instalar o Ubuntu, a primeira coisa a fazer é reinstalar o coreutils de verdade e o sudo

• O conceito de “Crossing the chasm” é interessante. Além do caso do coreutils no Ubuntu, há muitos outros abismos que o Rust está tentando atravessar
  Existe Rust for Linux e também Rust para a indústria automotiva, mas por enquanto parece que ainda está no nível de drivers

  • O Rust está se expandindo em várias direções. pyo3 (substituição de módulos Python), Dioxus (framework web semelhante ao React) e Ferrocine (compilador para automotivo) são exemplos representativos. O projeto DARPA TRACTOR também acelera a adoção de Rust
  • O documento Project Goals do Rust (link) mostra em quais direções a comunidade está investindo com mais foco
  • O Rust em si é excelente, mas o problema é que parte da comunidade só quer reescrever software estável existente em Rust e se apropriar da marca. O Ubuntu também parece estar preso a esse tipo de virtue signaling

• A lógica de dizer que a biblioteca padrão pode ser trocada depois é perigosa. O usuário quer um sistema estável e de alta qualidade, mais do que atravessar algum “abismo”

  • No caso do Rust, não se trata de “trocar” a stdlib, e sim de adicionar, o que é fácil. Sai uma nova release a cada 6 semanas, e em cada uma entram mais de 10 recursos novos. Já existem centenas de funcionalidades na stdlib

• A imaturidade do ecossistema Rust é um fator que atrapalha a adoção. Muitos crates ainda estão em versões pré-1.0 ou são apenas wrappers simples para C. Na parte de criptografia está razoável, mas coisas como SAML são difíceis de encontrar

  • Não precisa se preocupar tanto com versões pré-1.0. Por causa da cultura de seguir SemVer com rigor, muitos projetos adiam declarar 1.0. Crates profundamente ligados à API, como libc, também têm dificuldade para subir versão. Pessoalmente, consulto listas curadas como blessed.rs
  • O gettext também só chegou à versão 1.0 depois de 30 anos
  • O módulo cryptography do Python passou a exigir toolchain Rust, então não foi possível instalar no ambiente Termux. É incômodo até projetos Python ficarem pesados por causa de dependências em Rust

• Há um movimento de “traduzir” código C++ para Rust no estilo vibe-translate, mudando até a licença no processo. Por exemplo, o sudo-rs tem um histórico de segurança pior que o da versão em C

  • A propaganda em torno de Rust, IA e segurança está exagerada demais. No começo eu adorava Rust, mas a polêmica da licença MIT e o marketing excessivo estão ficando cansativos

• A enorme biblioteca padrão do .NET é realmente muito confortável. Dá para fazer a maioria das tarefas do jeito padrão, e quando existe alguma implementação estranha, muita gente tenta padronizar

  • Acho que a stdlib pequena do Rust foi um erro. Como a stdlib é a única dependência sempre presente, ela deveria incluir mais ferramentas, mesmo que não fosse perfeita
  • Mas, do ponto de vista de quem programa sistemas, uma stdlib grande pode ser um problema. No .NET isso não importa tanto porque ele é baseado em GC, mas Rust e C++ também precisam rodar em ambientes bare metal. Uma stdlib grande pesa em ambientes com restrições de memória (<64K)
    O std/core do Rust já é grande demais, então em microcontroladores são necessários truques como weak symbol.
    Uma stdlib pequena ajuda a manter a estabilidade da API e reduzir a carga de manutenção. Como o C++ sofreu com isso, o Rust precisa ser cauteloso