18 pontos por GN⁺ 2025-06-12 | 5 comentários | Compartilhar no WhatsApp
  • Texto que reúne 10 anos de experiência adotando Rust em produção desde logo após o lançamento do Rust 1.0 e as expectativas para os próximos 10 anos
  • No começo, foi difícil lidar com problemas de compatibilidade entre versões, tempo de build e adaptação ao borrow checker
  • A comunidade e o ecossistema Rust evoluíram rapidamente graças a um “excelente senso de programação” e a uma forte cultura comunitária, com muitos desenvolvedores talentosos migrando para Rust
  • Hoje Rust se tornou uma “escolha segura” para sistemas em geral e backend, e a evolução da biblioteca padrão com a maturidade do ecossistema de crates reduziu bastante a incerteza
  • O texto apresenta de forma concreta os desafios que Rust ainda precisa resolver e suas direções de evolução, como velocidade de build, portabilidade, recursos const, concorrência e expansão para vários domínios
  • Os próximos 10 anos devem trazer compilações mais rápidas, expansão ampla para diferentes domínios e inovação na experiência do desenvolvedor, acelerando o ciclo de feedback positivo do ecossistema Rust

  • Em junho de 2015, cerca de um mês depois de a empolgação com o lançamento do Rust 1.0 começar a diminuir, o autor escreveu seu primeiro código em Rust
  • Depois de usar C, Python e JavaScript, conheceu Rust e nunca mais olhou para trás
  • Com base na experiência em duas startups baseadas em Rust e em mais de 500 mil linhas de código escritas, compartilha uma reflexão sobre esses 10 anos

Os primeiros anos foram dolorosos - The early days were painful

  • No início da adoção, a compatibilidade de versão entre crates e compilador era muito instável, e até pequenos bug fixes frequentemente forçavam a atualização de todo o ambiente de build
  • Os conceitos do borrow checker e o gerenciamento de lifetimes pareciam difíceis, e o aumento de tipos complexos agravava seriamente o tempo de compilação
  • Sempre que era preciso um novo recurso ou uma correção de bug, era necessário atualizar “todas as versões do mundo”, e muito tempo era gasto procurando combinações compatíveis

A excelência da comunidade Rust - The people were and are exceptional

  • O ecossistema Rust consolidou uma cultura de programação excepcional, voltada a implementações simples e elegantes, com desempenho rápido e robusto
  • Em comparação com TypeScript ou Python, a estrutura de dependências em Rust é muito mais limpa e o build é mais simples
  • A dedicação dos voluntários da comunidade e a postura cautelosa de “agora não/ainda não” tiveram papel central
  • Em Londres, isso foi uma grande vantagem na contratação de desenvolvedores Rust, e o nível médio dos desenvolvedores Rust é muito alto

Rust se tornou uma escolha segura (em alguns domínios) - Rust has become a safe bet (in some domains)

  • No começo, a falta de recursos na biblioteca padrão (std) exigia criar utilitários e patches manualmente, mas agora a maioria das funções está embutida em std e nos crates, reduzindo muito a incerteza
  • A previsibilidade de builds e upgrades, a redução de dependências externas, o respeito ao semver e as melhorias no borrow checker e no mecanismo de inferência tornaram a experiência com Rust muito mais estável
  • Novos crates como jiff, polars e tauri estão sendo desenvolvidos com base nos aprendizados do passado, enquanto tokio, hyper e regex já foram comprovados na prática
  • Antes, reinventar a roda era inevitável; hoje é possível focar na lógica de negócio e desenvolver aplicações de alto desempenho e robustas

O ambiente de desenvolvimento que Rust oferece hoje - Rust today feels like what programming should be

  • Rust é uma linguagem com empatia real pelo programador, oferecendo sistema de build conciso e robusto, excelentes mensagens de erro e lints, ótima documentação e integração com IDE, além de CI e testes de regressão poderosos
  • Entre grandes projetos open source, é raro encontrar uma linguagem tão amigável para programadores quanto Rust
  • O investimento de longo prazo de inúmeras comunidades e contribuidores foi o fator central para construir o Rust atual

O que espero dos próximos 10 anos - What I’m looking forward to over the next 10 years

Builds mais simples e rápidos - Simpler and faster builds

  • Espera-se a continuidade do trabalho de substituir dependências complexas ou lentas por alternativas simples e rápidas
  • São promissoras novas tentativas como biblioteca padrão totalmente em Rust, menos dependência de linker e bibliotecas do sistema, criptografia pure-Rust, BTreeMap persistente e engines de jogos em Rust
  • Na Tably, nos últimos meses, a velocidade de compilação do frontend/backend melhorou 60%

Mais portabilidade e menos #[cfg()] - Improved portability and less #[cfg()]

  • Testar combinações variadas de plataformas e opções é difícil, e #[cfg()] gera código não verificado, documentação incompleta e problemas em IDEs
  • Ao mover #[cfg()] para dentro do trait system, espera-se viabilizar garantias de plataforma/opção, menos recompilações, cache de MIR e CI mais rápido

Que todo código possa ser const - Everything being const

  • Executar mais trabalho em tempo de compilação reduz a dependência de macros e build scripts, além de prevenir erros de runtime com antecedência
  • Hoje isso ainda é limitado, mas o objetivo futuro é um Rust em que “todo código possa ser executado em contexto const

Simplificação da concorrência - Simpler concurrency

  • O modelo atual de async em Rust tem muita complexidade prática, como static bound, cancellation-safety e restrições de traits, o que dificulta o uso no mundo real
  • É necessário buscar uma concorrência mais simples no nível da linguagem, como ocorria com as antigas user-space green threads (libgreen)

Tornar-se competitivo em mais domínios - Excelling in more domains

  • O uso de Rust dentro do navegador web (especialmente em wasm/rustwasm) ainda é um território pouco explorado, com vários desafios em aberto, como stack traces cross-browser
    • Frameworks como leptos e sycamore continuam evoluindo, mas ainda há bastante espaço para melhorias
  • Espera-se também progresso contínuo em domínios onde Rust ainda não rompeu totalmente, como rapid prototyping, lógica de negócio, GUI, machine learning e desenvolvimento de jogos

Conclusão

  • O futuro do crescimento de Rust é muito claro e promissor
  • Quanto maior a adoção, maior a capacidade de engenharia e testes, criando um ciclo virtuoso de expansão e melhoria
  • Os próximos 10 anos devem tornar realidade compilações mais rápidas, aplicação em áreas diversas e uma experiência de desenvolvimento mais fluida
  • O autor está ansioso pela nova década de Rust

5 comentários

 
ndrgrd 2025-06-12

O Rust é ótimo, mas a linguagem exige demais.
Quando uso Rust, sinto que estou mais estudando a própria linguagem do que focando na implementação da ideia em si.

Para migrar um projeto já existente, como ao sair de C++, isso talvez não seja um grande problema,
mas não tenho certeza se ele é realmente confortável de usar quando se quer implementar uma ideia nova.

 
felizgeek 2025-06-12

Para prototipagem, recomendo Python.

 
ndrgrd 2025-06-12

Pessoalmente, prefiro sistemas de tipos, então atualmente uso C# e acho que isso já me satisfaz.

 
codemasterkimc 2025-06-12

Pessoalmente, se você pensa no meio ambiente da Terra, RUST. Código legado em Spring para Axum!!!

 
GN⁺ 2025-06-12
Opinião do Hacker News
  • É um texto muito positivo e bate bastante com a minha experiência também. Mas, se eu tivesse que apontar um lado mais sombrio, seria algo assim:
    "async tem um custo de complexidade relativamente alto por causa de static bound, segurança de cancelamento e limitações relacionadas a traits e dyn. No momento, não há muitos sinais de que isso vá ser resolvido. A bifurcação entre primitivas síncronas/assíncronas e as características próprias do ecossistema aumentam o async tax (custo extra). Soluções baseadas em Effects também não parecem muito promissoras."
    "Antes do Rust 1.0, existia uma solução chamada libgreen. Ela implementava concorrência em user space sem bifurcação, mas acabou removida por causa dos custos consideráveis de performance, portabilidade e manutenção. Acho que vale a pena reconsiderar isso se houver capacidade de engenharia suficiente. Um dia quero fazer um PoC que faça zero-cost wrapping de std::{fs, net} e fiber::{spawn, select} com generators"
    • Há quem diga que a discussão de que "o static bound aumenta a complexidade" é apenas uma escolha de design do runtime async do Tokio, e não algo que represente o design do Rust como um todo. O runtime async do Embassy funciona sem esse bound, embora em troca seja preciso gerenciar pinning manualmente. Na verdade, o static bound existe justamente para reduzir a complexidade
  • Como alguém que mergulhou em Rust no fim de 2022 e estudou a linguagem, sempre acho interessante ouvir relatos de quem aprendeu em uma época mais difícil, como 2015. Sinto que tive sorte de poder aprender Rust em um momento mais maduro, quando a curva de aprendizado já íngreme estava um pouco mais suavizada. Hoje em dia, tenho a sensação de estar revivendo essas histórias dos primeiros anos do Rust com Zig. Parece que o Zig está em um estágio parecido com o Rust do começo. Mesmo assim, já estou usando e me divertindo bastante
    • Existe uma cultura forte de "deixar melhor do que encontrou". Se a ferramenta ou a linguagem foi confusa, a culpa não é do usuário. Se eu me confundi, outras pessoas provavelmente também vão se confundir, então melhorar isso sempre que possível traz um grande benefício para todo mundo. Aqui vale aquele ditado de que o segundo melhor momento para plantar uma árvore é hoje. Graças a essa cultura, alguém que tentou Rust no passado e se frustrou pode ter uma experiência muito melhor um ano depois. Por isso, o melhor conselho para quem estava começando em Rust era: "espere seis meses"
    • Se uma linguagem é adotada por big techs como MSFT e Google, ou por grandes projetos open source como o Linux, isso já é um sinal de que o ecossistema está suficientemente maduro. Mas não tenho a mesma confiança em Zig, porque ele ainda não mostrou uma mudança (grande) em relação às ferramentas já existentes
  • Tenho a impressão de que Rust incentiva programação funcional. Eu estava fazendo um parser que alterava o estado interno a cada advance, mas acabei tendo dificuldade por causa da mutabilidade e do sistema de borrowing, então tive que mudar para um parser stateless. Em vez de modificar um índice interno, a estrutura passou a retornar o índice. Fico curioso se esse tipo de situação, em que o jeito tradicional não funciona bem e é preciso abordar o problema de outra forma em Rust, é comum
    • Tive uma experiência parecida. Em casos simples, dá para usar um estilo mutável e imperativo sem problemas, mas, à medida que a complexidade aumenta, acabo migrando para um estilo funcional e evitando mudanças o máximo possível. Por causa do borrow checker e dos lifetimes, padrões mais tradicionais ficam difíceis, e naturalmente você vai para o lado funcional. Se você não está acostumado a implementar de forma funcional, isso pode ser duro, mas é uma experiência em que o compilador fica bem mais satisfeito
  • Async/await é o único motivo para eu não usar Rust
    • Na verdade, acho que async/await é um dos principais motivos para usar Rust. Ele deixa os padrões de concorrência muito mais simples. No começo, parecia uma espécie de doença contagiosa maligna em que todo o código acabava tendo que virar async, mas depois que você aprende a interagir com código async, fica tranquilo. Normalmente, spawn, spawn_blocking e futures::stream cobrem 90% dos casos de uso, e, se você definir bem as "fronteiras", nem precisa deixar o async se propagar
    • Até entendo em certa medida. Mas, para mim, async/await encaixa tão bem em Rust que é um dos maiores motivos para eu usar a linguagem. Gosto da sintaxe e não me importo muito com o problema de function colouring. Especialmente ao usar Tokio, como existem versões async de todas as funções padrão necessárias, parece que a solução flui muito bem. Isso pode criar uma barreira em alguns pontos, mas, no geral, programar concorrência fica muito mais fácil e a performance é boa, então fico satisfeito. Às vezes eu me enrolo com cancelamento (cancellation), mas acho que isso é mais limitação minha mesmo
    • Hoje em dia isso não já está tudo disponível?