Aaron Patterson detalha Ractors, JIT e a proposta para reinventar o bundle install

No episódio de agosto do podcast On Rails, publicado no blog oficial do Ruby on Rails↳Ruby3 conteúdosComo migrei meus testes automatizados de Java para Ruby… Será que fiz bem?Dev (Back & Front) · jun 2019Refatoração em RubyDev (Back & Front) · mai 20197 exemplos de linguagens de programação server-sideGestão Dev & TI · jun 2024Ver tudo em Dev (Back & Front) →, Robby Russell conversa com Aaron Patterson, o Tenderlove, senior staff engineer do time de infraestrutura Ruby do Shopify e contribuidor de longa data do Ruby e do Rails Core. A conversa cobre três frentes que interessam diretamente a quem mantém app Rails em produção: paralelismo com Ractors, compiladores JIT e uma proposta para reescrever a forma como as gems são instaladas.

Ractors: paralelismo de verdade, mas com fronteira rígida

Historicamente, o CRuby (a implementação de referência) sempre teve o GVL (Global VM Lock), que impede que duas threads Ruby executem bytecode ao mesmo tempo. Na prática, threads em Ruby são ótimas para trabalho I/O-bound (esperando banco, rede, disco), mas não escalam CPU-bound: um processo Ruby usava, efetivamente, um core por vez para computação pura. A saída clássica no mundo Rails sempre foi rodar múltiplos processos (via Puma em modo cluster, Unicorn, Sidekiq com vários workers), pagando o custo de memória de cada processo separado.

Os Ractors mudam esse cenário ao permitir execução paralela real dentro de um mesmo processo. Cada Ractor tem seu próprio GVL, então dois Ractors podem queimar CPU em cores diferentes simultaneamente. O preço disso é o modelo de isolamento: Ractors não compartilham objetos mutáveis livremente. A comunicação acontece por troca de mensagens, e objetos precisam ser shareable (imutáveis, frozen) ou são copiados/movidos entre Ractors. É um modelo mais próximo do que Elixir/Erlang fazem com actors do que do compartilhamento de memória caótico que threads costumam permitir.

Para o dev Rails, o ponto honesto é: Ractors ainda não são um botão que você liga e o app fica paralelo. Boa parte do ecossistema (incluindo o próprio Rails e muitas gems) assume estado global mutável, o que colide com o isolamento exigido. O amadurecimento vem justamente de tornar mais partes do runtime e das bibliotecas ractor-safe. O ganho potencial, quando isso destravar, é rodar mais trabalho por processo sem multiplicar o consumo de RAM, algo que impacta direto a conta de servidor de qualquer app hospedado no Brasil.

JIT: por que o Ruby ficou mais rápido

Patterson também discute os compiladores JIT. O JIT (Just-In-Time) compila trechos de bytecode quentes para código de máquina nativo em tempo de execução, em vez de interpretar tudo. No Ruby, isso passou pelo MJIT, depois YJIT (escrito originalmente em Rust, mantido em boa parte pelo time do Shopify) e experimentos mais recentes. O YJIT já entrega ganhos reais em cargas Rails, sem que o desenvolvedor precise mudar código: liga-se com uma flag na inicialização.

O trade-off vale ser dito com clareza. JIT tem custo de warmup: os primeiros requests pagam a compilação, e há consumo extra de memória para guardar o código gerado. Para workloads de vida curta (uma task CLI que roda e morre) o benefício pode não compensar. Para um processo web de longa duração servindo milhares de requests, o custo é amortizado e o throughput sobe. É a diferença entre otimizar tempo de partida e otimizar tempo de regime.

Content addressable gems: a proposta para acelerar o bundle install

O trecho talvez mais concreto do episódio é a proposta que Patterson levou ao RubyGems.org: gems endereçadas por conteúdo (content addressable). Hoje, bundle install baixa arquivos .gem inteiros e refaz muito trabalho, mesmo quando pouca coisa mudou entre versões ou entre dependências que compartilham arquivos. O endereçamento por conteúdo identifica cada arquivo pelo hash do seu conteúdo, no mesmo espírito de como o Git guarda blobs ou como sistemas de build modernos fazem cache.

Na prática, isso abre caminho para deduplicação e cache muito mais agressivos: se um arquivo com determinado hash já está na máquina, não precisa ser baixado de novo, independentemente de qual gem ou versão o trouxe. O impacto direto seria um bundle install dramaticamente mais rápido, como coloca a fonte, o que pesa em pipelines de CI e em deploys, onde a instalação de dependências é reexecutada o tempo todo. Para times brasileiros lidando com latência para servidores de pacotes fora do país, cortar downloads redundantes é ganho tangível.

É importante frisar que se trata de uma proposta, não de algo já em produção. Mudar o formato de distribuição de gems mexe em infraestrutura crítica e exige compatibilidade com todo o ecossistema existente.

Extensões C e FFI: por que as gems descem para o nativo

A conversa também aborda por que tantas gems recorrem a extensões nativas em C. Os motivos usuais: performance em trechos críticos e a necessidade de fazer binding com bibliotecas C já existentes (parsers, drivers de banco, libs de criptografia). O custo é conhecido: extensões C precisam ser compiladas na instalação, o que quebra em ambientes sem toolchain, aumenta o tempo de bundle install e cria dor de cabeça de portabilidade. A fonte lista o FFI (Foreign Function Interface) como alternativa, permitindo chamar código nativo sem escrever uma extensão C completa, ao custo de outros trade-offs de performance e complexidade.

AI no dia a dia, com desconfiança

Por fim, Patterson tem uma conversa franca sobre como usa AI↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → no trabalho. Ele descreve dois usos: navegar por código desconhecido na escala do Shopify e construir um encoder JPEG quase inteiramente com o Claude. Ao mesmo tempo, admite que ainda não confia na ferramenta como confia num colega de longa data. É um posicionamento útil justamente por não ser nem hype nem rejeição: AI como acelerador para exploração e prototipagem, com o julgamento humano permanecendo no loop para o que vai para produção.

O episódio completo dura 1h23 e está disponível no blog do Rails e nos players de podcast.

Fonte: Ruby on Rails Blog