Vamos falar de Ruby - AguiarDev Talks #35

Tiago Aguiar e Rafael Peixoto recebem Rodrigo Serradura, fundador da comunidade ADRB, para apresentar o Ruby a quem nunca teve contato com a linguagem. A conversa passa pelas características que tornaram o Ruby conhecido pela produtividade, pelo peso do framework Rails na história da linguagem e pelo estado atual da comunidade brasileira e internacional.

O que foi discutido

• Características da linguagem — interpretada, dinamicamente tipada e multiparadigma, com foco declarado na felicidade do programador
• Instalação e primeiros passos — do apt install ruby a gerenciadores de versão como RBenv e ASDF
• O trade-off entre liberdade de estilo e necessidade de convenções, e o papel do RuboCop nesse equilíbrio
• Onde o GVL (Global VM Lock) limita o paralelismo real do Ruby e quando isso importa na prática
• Os diferentes tipos de aplicação que a linguagem suporta, de APIs web a scripts de automação e sistemas embarcados via mRuby
• Como e por que o Rails nasceu dentro de um produto real, o Basecamp
• A evolução das ferramentas de teste no ecossistema, do Cucumber ao RSpec
• O estado da comunidade Ruby no Brasil e no mundo, incluindo a origem da comunidade ADRB

Sobre Rodrigo Serradura

Rodrigo começou sua trajetória em programação vindo da área de negócios, passando por VBA e PL/SQL antes de um contato inicial com Java. Ao conhecer o Ruby, decidiu migrar de vez para o ecossistema Rails e hoje se considera fluente tanto em Ruby quanto em JavaScript. Depois de anos ativo na comunidade Ruby Brasil, criou em 2018 um espaço para discutir boas práticas, arquitetura e programação funcional aplicada à linguagem — o que deu origem à comunidade ADRB (Arquitetura e Design de Aplicações Ruby), hoje com mais de 800 membros. É autor de bibliotecas como a MicroCase e do método de desenvolvimento BCDD, além de professor de um curso próprio de orientação a objetos e SOLID com Ruby.

Principais pontos

A linguagem foi desenhada em torno da felicidade do desenvolvedor

Ruby nasceu com o compromisso explícito de ser simples e produtiva — uma premissa do próprio criador, Yukihiro Matsumoto (Matz), que priorizou a experiência de quem programa. Isso se reflete em decisões concretas: a linguagem é dinamicamente tipada, dispensa declarações de assinatura em métodos e permite operações simples, como imprimir um valor na tela, com uma única palavra. Ruby também é multiparadigma, suportando os estilos procedural, orientado a objetos e funcional dentro do mesmo projeto.

"Uma das coisas da qual o criador da linguagem, um dos objetivos que o Matt teve, é que a linguagem fosse simples e voltada pra produtividade... o Matt teve como premissa a felicidade do programador" por Rodrigo Serradura

A liberdade de estilo exige combinar regras dentro do time

Como o Ruby permite múltiplas formas de resolver o mesmo problema, equipes precisam alinhar convenções para que o código continue legível em escala. É nesse contexto que ferramentas como o RuboCop — um linter que analisa estilo, performance e vulnerabilidades — se tornaram quase onipresentes no desenvolvimento Ruby, junto com presets como o Standard RB, que centralizam esse debate na própria comunidade.

"Você precisa combinar o jogo para poder jogar o jogo" por Rodrigo Serradura

O GVL limita paralelismo real, mas isso raramente é o gargalo

O Ruby tem suporte nativo a threads, mas cada uma delas compartilha um lock global (o GVL, Global VM Lock), o que significa que um único processo Ruby usa apenas um núcleo da máquina por vez. Para paralelismo real, é preciso trabalhar com múltiplos processos — ou explorar o Ractor, um modelo mais recente inspirado no modelo de atores do Erlang, ainda em evolução. Na prática, servidores de aplicação Rails contornam essa limitação rodando múltiplos processos, cada um com suas próprias threads.

"Se eu tenho mais de um core, se eu tenho um processo Ruby, eu só vou utilizar um core da minha máquina... para trabalhar com múltiplas threads em paralelo, e não de maneira concorrente, o Ruby tem maneiras de fazer isso" por Rodrigo Serradura

Performance depende do problema, não de benchmarks isolados

Para aplicações que dependem intensamente de processamento (CPU bound), Ruby não é a escolha mais indicada — linguagens como Go, Rust ou C tendem a ser mais adequadas. Mas para aplicações web tipicamente dominadas por operações de I/O, como chamadas HTTP e consultas a banco de dados, a diferença de performance entre Ruby e linguagens compiladas se torna irrelevante diante da latência dessas operações externas. Casos como GitHub, Shopify e Basecamp — todos rodando em Ruby e Rails em larga escala — sustentam esse argumento na prática.

"Se você precisa fazer algo que é baseado em CPU, onde você precisa utilizar todos os cores da sua máquina, eu diria que Ruby não é a resposta... agora, se você precisa desenvolver uma aplicação web, que é baseada em muito I/O, Ruby vai te atender muito bem" por Rodrigo Serradura

O Rails nasceu dentro de um produto, não de uma tese de linguagem

O framework surgiu quando David Heinemeier Hansson (DHH) construía o Basecamp, um sistema de gestão de projetos, e passou a automatizar tarefas repetitivas do próprio desenvolvimento — geradores de model, view e controller seguindo a arquitetura MVC. Essa origem prática, alinhada ao momento em que o mercado buscava um meio-termo entre a burocracia do mundo enterprise em Java e a informalidade excessiva do PHP, ajudou o Rails a se consolidar como ferramenta de escolha para startups que precisavam validar produtos rapidamente.

"O Rails ele nasce para construir um produto, basicamente gestão de projetos, chamado Basecamp" por Rodrigo Serradura

Frase de destaque

"O Ruby, na sua essência, na sua origem, ele nasce muito voltado a essa ideia das boas práticas e tudo mais... só que tem tanta coisa de boa prática que eu comecei esse movimento pra gente consumir e se beneficiar disso, e daí o ADA nasce por conta disso" por Rodrigo Serradura

Lições do episódio

1. Antes de escolher uma linguagem por performance, é preciso identificar se o problema é dominado por processamento (CPU bound) ou por operações externas (I/O bound) — essa distinção muda completamente a análise.
2. A flexibilidade do Ruby é uma força e um risco ao mesmo tempo: sem convenções de estilo combinadas em equipe, ela pode gerar código difícil de manter.
3. A produtividade de um framework como o Rails costuma vir de ele ter nascido resolvendo um problema real de produto, não de um exercício teórico de design de linguagem.
4. A cultura de testes esteve presente no ecossistema Ruby desde o início, o que explica por que ferramentas como RSpec e a filosofia de BDD nasceram e amadureceram ali.
5. Participar de comunidades especializadas — como grupos de Telegram, Reddit ou encontros locais — acelera o aprendizado prático de qualquer linguagem, além de abrir espaço para discussões mais avançadas de arquitetura.