Ruby 3.3

Artigo original ↗ Discussão no Hacker News ↗

O lançamento do Ruby 3.3 é visto por muitos como o mais significativo em uma década, trazendo um JIT pronto para produção (YJIT), o novo parser Prism, ferramentas IRB melhoradas e primitivas mais fortes de async e concorrência, como fibers e Ractors. Os comentaristas debatem se esses ganhos mudam materialmente a reputação do Ruby de baixo desempenho — especialmente em comparação com Go, Rust, Java e Python — e quanto Rails e seu ecossistema, e não a linguagem em si, são responsáveis pela lentidão e pela perda de relevância. Outros argumentam que Ruby e Rails continuam altamente produtivos para backends web e scripting, com desempenho agora “bom o suficiente” para a maioria das cargas de trabalho de negócios, mesmo que não seja competitivo em benchmarks brutos.

Significance do Ruby 3.3

  • Muitos veem o 3.3 como o lançamento mais importante do Ruby em uma década: YJIT pronto para produção, parser Prism, IRB melhorado, fibras/async e Ractors.
  • Outros não se convencem e perguntam o que há de fundamentalmente novo além de ganhos incrementais de velocidade e ferramentas.

Desempenho, YJIT e Benchmarks

  • Há relatos de acelerações de 10–15% em grandes apps Rails com YJIT ativado; microbenchmarks mostram ganhos de 2–3x em algumas cargas de trabalho limitadas por CPU.
  • Críticos argumentam que, mesmo com esses ganhos, Ruby continua ordens de magnitude mais lento que Go/Java/Rust e que isso não mudará a reputação de Ruby como “lento”.
  • Contraponto: em aplicativos web típicos, a latência é dominada por DB/IO; Ruby é “rápido o suficiente”, e o custo de servidor muitas vezes é pequeno em comparação com o tempo de desenvolvimento.
  • Alguns descrevem casos reais em que o overhead e o uso de recursos de Django/Rails viraram gargalo em uma escala modesta.

Concorrência e Runtime (Ractors, Fibers, RUBY_MAX_CPU)

  • Ractors e fibras assíncronas são vistos como recursos importantes, porém pouco discutidos, embora a adoção prática em Rails ainda seja incerta.
  • O novo RUBY_MAX_CPU tem padrão 8; alguns querem que ele seja ligado aos núcleos lógicos, outros observam contagens de núcleos reportadas incorretamente e preferem um padrão conservador.
  • A resolução de nomes (getaddrinfo) agora roda em threads de trabalho para poder ser interrompida; isso adiciona um pequeno overhead, mas permite comportamento assíncrono.

Ferramentas: Prism, LSP e Depuração

  • O parser Prism é elogiado como base para análise estática mais rápida, integração com RuboCop e servidores de linguagem.
  • O IRB recebe melhorias importantes (autocompletar, depuração), e as ferramentas de debug do Ruby (rdbg, Pry) são destacadas, embora a metaprogramação pesada continue difícil de depurar.

Filas de Jobs e Interoperabilidade entre Linguagens

  • Vários lamentam a falta de uma fila de tarefas de fato padrão entre linguagens para integração Ruby–Python; muitas empresas simplesmente usam Sidekiq (Ruby) e Celery (Python) separadamente.
  • Opções mencionadas: um sistema agnóstico de linguagem baseado em Redis/RabbitMQ, Faktory, o protocolo do Celery, beanstalkd, Gearman, dirq, SQS e filas DIY em Postgres/Redis.
  • Debate sobre monetização: alguns recursos de confiabilidade “essenciais” (por exemplo, não perder jobs em caso de crash) ficam atrás de planos pagos, algo que alguns desaprovam e outros defendem como necessário para a sustentabilidade.

Imports e Namespace Global

  • O namespace global único de constantes do Ruby e a falta de imports de módulos dividem opiniões.
  • Alguns gostam do estilo C de “basta carregar arquivos” e das convenções de autoloading do Rails/Zeitwerk; outros preferem imports explícitos no estilo Python e acham a resolução de constantes do Ruby pouco prática.
  • Bibliotecas experimentais e propostas tentam semânticas de import mais explícitas e modulares.

Saúde do Ecossistema e Casos de Uso

  • Uma visão forte: Ruby/Rails atingiu seu auge anos atrás, está em declínio de longo prazo em comparação com Python, TypeScript, Go, Rust e Java/Spring; muitas empresas web já migraram para outras opções.
  • Visão oposta: embora não esteja no pico de 2007–2009, Ruby/Rails está estável ou se recuperando — novas conferências, livros, gems e recursos (Rails 7, Hotwire, Turbo 8) indicam uma comunidade ativa.
  • Há consenso de que a maior parte do uso de Ruby ainda é em apps web Rails; usos fora de Rails (CLIs, infraestrutura, ferramentas de segurança, gestão de configuração) existem, mas são de nicho.

Ruby vs Outras Linguagens: Velocidade vs Produtividade

  • Um grupo enfatiza a lentidão do Ruby e o mercado de trabalho encolhendo, argumentando que trabalhos sérios e sensíveis a desempenho pertencem a Go, Rust, Java, C#, etc.
  • Outro grupo valoriza a expressividade do Ruby, a forte biblioteca padrão (Strings/Arrays/Hashes), a cultura de testes (RSpec/MiniTest) e a “felicidade do desenvolvedor”, defendendo que produtividade e simplicidade superam a velocidade bruta na maioria dos aplicativos de negócio.
  • Alguns observam que Go/Rust podem reduzir drasticamente o número de servidores para APIs pesadas, mas também reconhecem iteração mais lenta e curvas de aprendizado mais íngremes.

Aprendendo Ruby e “Bash Melhorado”

  • As recomendações variam: se você já é produtivo em Python/Node, Ruby talvez não desbloqueie capacidades fundamentalmente novas, mas é agradável e elegante.
  • Vários elogiam Ruby como um “bash/Perl melhorado” para scripting, processamento de texto e trabalho exploratório de sistema, especialmente com Pry/IRB, Sequel e APIs enumerable fortes.
  • Outros acham a sintaxe, os blocos e a cultura de metaprogramação do Ruby mais difíceis de abordar do que o estilo mais minimalista e centrado em funções do Python.