Por que Ruby ainda parece um lar mesmo depois de muito tempo

 (caio.ca)
1 pontos por GN⁺ 1 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • Ruby não é a linguagem mais rápida nem a mais hypada, mas continua sendo a escolhida quando a pessoa quer voltar a gostar de trabalhar, mesmo depois de passar por várias linguagens ao longo de mais de 15 anos
  • refinements, Forwardable, SimpleDelegator, Object#then, Kernel#tap e parâmetros numerados oferecem pequenas conveniências sintáticas e um fluxo fácil de ler
  • Thread::Queue, json e csv da biblioteca padrão, além de RuboCop e Ruby LSP, ajudam a manter um ambiente de desenvolvimento prático sem precisar de várias gems pequenas nem de configurações complexas
  • O YJIT do Ruby 3.x e o ZJIT da série 4.x estão reduzindo a diferença em tarefas intensivas de CPU, e numa comparação simples de Fibonacci o Ruby com ZJIT ficou a até 2–3x do Go
  • Há áreas em que Rust, Go e Python são mais adequados, mas em apps web, processamento em background e ferramentas internas, a felicidade do desenvolvedor e a rapidez de iteração continuam sendo pontos fortes do Ruby

Os motivos linguísticos que fazem Ruby parecer confortável

  • Ruby não é a linguagem mais rápida nem a mais popular do momento, mas continua sendo aquela para a qual se volta quando se quer realmente gostar do trabalho, mesmo depois de transitar entre várias linguagens por mais de 15 anos
  • refinements permitem abrir classes apenas em um escopo limitado, o que possibilita adicionar pequenas conveniências sintáticas dentro de um arquivo ou bloco sem poluir o namespace inteiro
    • Combina bem com helpers de teste ou DSLs internas em codebases grandes
    • Métodos como "hello".quote só podem ser usados no local em que using QuotingRefinement foi chamado
  • Forwardable e SimpleDelegator, da biblioteca padrão, permitem fazer delegação de forma limpa sem escrever métodos wrapper manualmente nem puxar gems extras
    • Se você já usa Rails, o delegate do Active Support pode ser mais conveniente, mas a versão do Ruby puro mantém scripts gerais mais leves
  • Object#then e Kernel#tap permitem encadear operações em um fluxo que se lê de cima para baixo, sem criar variáveis intermediárias
    • Dá para escrever um fluxo de criação, logging, normalização e salvamento como User.new(params).tap { ... }.then { ... }.save
  • Os parâmetros numerados do Ruby 2.7 em diante reduzem ruído em callbacks curtos
    • Em algo como items.map { _1.price * 1.1 }, não é preciso declarar explicitamente o argumento do bloco
  • O fiber scheduler permite escrever código concorrente que parece sequencial quando conectado a um event loop
    • Ele expressa código que coopera com outras fibers na forma Fiber.schedule do ... end

O estado atual de ferramentas, desempenho e ecossistema

  • O Ruby LSP da Shopify oferece integração com o editor com configuração mínima e funciona bem com Steep ou RBS para adoção gradual de tipagem
  • O RuboCop ajuda a manter o estilo consistente sem os rituais mais pesados vistos em outros ecossistemas
  • A biblioteca padrão continua sendo uma força silenciosa, porque evita a necessidade de adicionar várias gems pequenas para tarefas comuns
    • Se você precisa de uma fila, pode usar Thread::Queue
    • Para parsing de JSON ou CSV, as bibliotecas json e csv cobrem a maior parte dos casos reais sem grande cerimônia
  • Depois do YJIT do Ruby 3.x, a série 4.x está recebendo o ZJIT
    • O ZJIT é um JIT mais agressivo sobre a mesma base, compilando com mais eficiência caminhos de execução mais quentes
    • Números iniciais mostram uma redução significativa da diferença para linguagens que antes abriam grande vantagem em tarefas intensivas de CPU
    • CRuby ZJIT está sendo desenvolvido no repositório principal do Ruby
  • Em um benchmark simples comparando implementações recursivas de Fibonacci na mesma máquina, o Ruby com ZJIT ficou a até 2–3x do Go, não ficou muito distante de um Rust otimizado nesse caso, e o Python com pypy ficou atrás
    • Microbenchmarks têm limitações, mas caminhos de código já aquecidos, nos quais o JIT tem tempo para otimizar, podem render ganhos ainda maiores em aplicações reais
  • Em comparação com Rust, Ruby leva vantagem na velocidade de iteração da lógica de negócio
    • No Rust, pode haver tempo gasto brigando com o borrow checker mesmo para coisas que em tempo de execução são claras
    • O Go tem ótimos primitivos de concorrência, mas até recentemente não tinha generics e, com um tratamento de erros um tanto rígido, pode fazer scripts simples parecerem mais pesados do que deveriam
    • Python é o primo mental mais próximo, mas costuma exigir mais boilerplate para expressar as mesmas ideias de alto nível, especialmente em torno de classes e decorators
  • Ao colocar código em modelos, a eficiência de tokens também funciona como uma vantagem prática do Ruby
    • Blocos podem ser expressos com do/end ou chaves, e chamadas de método quase nunca precisam de parênteses quando a legibilidade permite
    • Hashes e argumentos nomeados são recursos de primeira classe e concisos, permitindo encaixar mais lógica real na mesma janela de contexto do que em linguagens com muito ruído estrutural
  • Os utilitários de metaprogramação do Ruby são ótimos para criar APIs pequenas e fáceis de ler
    • Recursos como define_method, class_eval e interceptação de métodos ausentes permitem criar APIs expressivas sem uma etapa de geração de código
    • Bibliotecas como dry-rb e aasm usam esses recursos com moderação para oferecer máquinas de estado e camadas de validação limpas
  • As ferramentas da comunidade e o fluxo de deploy também amadureceram
    • byebug e pry parecem mais flexíveis do que muitos depuradores usados em outros lugares
    • Em jobs de background, solid_queue e good_job são simples o bastante para que toda a implementação possa ser entendida em uma tarde
    • Kamal substituiu, para muita gente, os antigos procedimentos ao estilo capistrano, e parece uma ferramenta feita por quem realmente opera times pequenos
  • Isso não significa que Ruby vença Rust ou Go em todo tipo de trabalho; há áreas em que Rust ou Go são mais apropriados
  • Na ampla faixa intermediária de aplicações web, processamento em background e ferramentas internas, Ruby continua oferecendo felicidade do desenvolvedor sem excesso de cerimônia nem trocas constantes de contexto
  • Pequenas conveniências e a sensação geral da linguagem continuam sendo o que faz muita gente recorrer a ela primeiro mesmo depois de mais de uma década, e o novo trabalho em JIT junto com melhorias constantes na linguagem só reforçam esse motivo

Leituras relacionadas

  • Ruby 4.0.0
    6 pontos · 1 comentários · 2025-12-26

1 comentários

 
GN⁺ 1 시간 전
Opiniões no Lobste.rs

  • É difícil concordar com a expressão “RuboCop sem cerimônia”
    Com o RuboCop, ainda existe bastante discussão sobre quais cops escolher e ajustar, e se vale ativar ou não os novos cops adicionados nas atualizações recentes
    O StandardRB chega bem mais perto de uma abordagem sem cerimônia, mas no fim ainda é preciso escolher um deles
    Linguagens com lint embutido são muito menos trabalhosas que Ruby nesse ponto e têm bem menos discussões triviais de estilo

    • Escolhi o Standard para a base de código do Sidekiq uns 10 anos atrás e nunca me arrependi
      Restrições acabam dando liberdade
    • Não dava para simplesmente usar todos os padrões?
      No geral sou contra configuração de linter, e preferiria deixar esse tipo de decisão para os padrões da comunidade
    • Sinceramente, minha opinião oscila nessa parte
      Por um lado, acho que os padrões do RuboCop já são bons o suficiente, então faz sentido segui-los e evoluir junto com eles em vez de fragmentar ainda mais o estilo de código
      Por outro, às vezes ele é opinativo demais, e aí algo como o standard.rb parece necessário
      Escrevi isso pensando em quem está aprendendo Ruby ou voltando para a linguagem e quer escrever código de forma tranquila sem precisar lidar com uma infinidade de gems
    • Concordo 100%
      Quando Go surgiu, achei excelente o fato de já trazer um sistema oficial de formatação
      O cérebro é uma máquina de reconhecimento de padrões, então quando se acostuma simplesmente segue em frente, mas quando há opções isso gera desconforto e puxa todo mundo para um lado ou para outro
      O problema é que nem o RuboCop nem o Standard podem ter esse tipo de autoridade em Ruby
      Essa autoridade teria de vir do core team, mas isso provavelmente não vai acontecer porque vai contra a filosofia do Ruby
      Nos meus projetos eu desativo todos os cops do RuboCop e só ligo alguns
      Aspas simples são as melhores 😀
    • Também travei nessa parte por um instante
      Parece que outro texto toca nesse mesmo ponto: https://caio.ca/blog/coding/my-complicated-relationship - “The Wild West of Code Formatting”
      Algo na linha de: “Não é uma solução embutida simples. Há centenas de cops configuráveis, o que leva a discussões intermináveis sobre quais regras ativar”

  • Em geral concordo, mas é um pouco uma pena que refinements seja o primeiro exemplo
    Entendo por que gostam disso, mas parece mais uma daquelas coisas em que é melhor não saber como a salsicha é feita
    A semântica é tão delicada que, mesmo 10 anos depois de ter sido introduzido, ainda seguem encontrando bugs complicados no MRI
    Por exemplo, só nas últimas duas semanas houve https://bugs.ruby-lang.org/issues/22071 e https://bugs.ruby-lang.org/issues/22058
    Em termos de desempenho, também tende a dificultar várias otimizações, e algo parecido está acontecendo agora com boxes

    • A ideia de boxes parece difícil de encaixar tardiamente numa linguagem em que tudo viveu no mesmo namespace global por décadas
      No nível de implementação, provavelmente ainda deve haver muitos bugs escondidos, e imagino que do lado das bibliotecas também
      Hoje já não uso tanto Ruby, mas tenho curiosidade de ver como isso vai se consolidar
      Parece interessante

  • Esse texto também coincide bastante com a minha experiência no meu texto “Returning to Rails”[1]
    Pode ser viés de confirmação, mas parece que cada vez mais gente está redescobrindo ou voltando a reconhecer a beleza do código Rails
    Ao mesmo tempo, isso também me lembra aquele fenômeno de que gosto musical ou artístico costuma se fixar no fim da adolescência ou nos 20 e poucos anos
    Então fico pensando se quem conheceu Ruby pela primeira vez na “era de ouro” do Rails não está olhando de volta para a época de Rails 3 e Capistrano com óculos cor-de-rosa
    Naquele tempo eu estava mergulhado numa “shop” de Ruby, e ao meu redor só havia desenvolvedores Rails, então parecia que Ruby estava em todo lugar
    Mas, vendo no thread do lobste.rs[2] a opinião de que Ruby sempre foi uma linguagem bem de nicho, talvez isso também tenha influenciado
    Mesmo assim, Ruby ainda parece casa, e dá a impressão de funcionar exatamente do jeito que a minha cabeça funciona
    Quase não há tradução mental, nada surpreende, e parece mais uma conversa com um amigo do que escrever um artigo formal
    Ainda não encontrei outra linguagem que encaixe desse jeito, e não acho que isso seja só pensamento do tipo “essa geração de hoje”
    De qualquer forma, fico feliz que ela tenha sobrevivido por tanto tempo
    E obrigado por mostrar a cadeia “tap / new”
    A estrutura é tão bonita e útil que me fez parar um instante, e provavelmente vou mesmo usar
    PS - Não tem relação direta com o assunto, mas o avatar de IA da página inicial é meio perturbador
    Passa muito aquela sensação de vale da estranheza de “será que esse texto foi escrito por um bot?”
    Sempre que vejo algo assim, por um instante me pergunto se estou mesmo falando com um ser humano real
    [1]=https://www.markround.com/blog/2026/03/05/returning-to-rails-in-2026/
    [2]=https://lobste.rs/s/jreqtw/returning_rails_2026

    • Posso afirmar com certeza que sou uma pessoa de verdade
      Só não quero publicar uma foto real, mas aquele avatar se parece o bastante para que pessoas que me conhecem me reconheçam

  • No Ruby 3.4 foi adicionado o parâmetro de bloco it, que pode ser usado no lugar de _1 no exemplo

    items.map { it.price * 1.1 }

    https://rubyreferences.github.io/rubychanges/3.4.html/…

    • Esqueci de mencionar o it
      Talvez por ser um recurso relativamente recente, ainda não consigo pegar o hábito automático de digitar it em iteradores

  • Eu adorava escrever código em Ruby, mas a carga de testes ficou pesada demais
    Achei que adicionar algum nível de segurança de tipos à linguagem ajudaria, mas, em #{last_job}, quando colocamos Sorbet na base de código, o impulso e a diversão de escrever código morreram completamente
    Talvez seja uma opinião impopular, mas o simples fato de algo como Sorbet existir me parece mais um mau sinal para Ruby
    Ruby em si é uma linguagem poderosa e divertida, mas as pessoas começaram a usá-la para trabalhos para os quais ela não foi originalmente projetada, e nesse processo passaram a empilhar ferramentas para compensar anti-recursos da linguagem
    A essa altura, cada linha parecia um sofrimento tedioso, e eu passava muito mais tempo esperando várias ferramentas de build, teste e lint do que escrevendo código de verdade
    Somando a isso processos de build e deploy excessivamente projetados, até coisas básicas passaram a demorar e o trabalho ficou penoso
    Sinto muita falta do mundo Ruby por volta de 2012
    Olhando para trás, foi realmente uma época muito boa

    • Pela sua experiência, qual linguagem foi mais adequada?
      Entendi que, quando você falou em “trabalhos para os quais ela não foi originalmente projetada”, estava se referindo a grandes aplicações Rails

  • Voltei para Ruby depois de 10 anos, e na era da “IA” é útil conseguir realmente entender o código que passa diante dos olhos e conseguir orientar ou interromper o LLM
    Em linguagens mais verbosas isso é mais difícil

  • Sinto falta de Ruby e, mais ainda, sinto falta da própria ideia de que uma linguagem assim pudesse existir no dia a dia de produção
    Aquilo era esperança, ou melhor, a própria esperança
    Pelo menos para mim, foi assim por muito tempo

    • O que aconteceu?

  • Isso parece um texto feito de qualquer jeito por IA
    Outros posts recentes do blog também são assim

    • Eu não percebi esse sinal
      Que pistas fizeram você pensar isso?
      Acho válido apontar textos ruins gerados por IA neste site, mas é preciso evitar falso positivo e dizer exatamente por que você pensa assim
    • Para mim não soou como um texto malfeito por IA
      Por que você achou isso?
      Esse tipo de alerta em si é válido, mas eu prefiro muito mais quando a pessoa explica o motivo junto

  • Tenho boas lembranças de ter trabalhado com Ruby no início da carreira
    Ruby tem mesmo alguma coisa muito agradável
    Mas, quando usei um pouco de Ruby recentemente, acho que no ano passado, senti que era difícil navegar a documentação da biblioteca padrão na web
    Sou só eu? Existe alguma alternativa à documentação do ruby-lang.org?

  • Esse texto parece meio estranho
    Tive a oportunidade de escrever um projeto e um SDK em Ruby, e não fiquei com a menor vontade de usar Ruby de novo depois disso