Ruby 3.3

Artículo original ↗ Discusión en Hacker News ↗

La versión 3.3 de Ruby es vista por muchos como la más significativa en una década, al traer un JIT listo para producción (YJIT), el nuevo parser Prism, mejores herramientas de IRB y primitivas más sólidas de concurrencia y async como fibras y Ractors. Los comentaristas debaten si estas mejoras cambian de forma material la reputación de Ruby por su bajo rendimiento—especialmente frente a Go, Rust, Java y Python—y cuánto del problema recae en Rails y su ecosistema, más que en el lenguaje en sí, además del declive de su presencia mental. Otros sostienen que Ruby y Rails siguen siendo muy productivos para backends web y scripting, con un rendimiento ya “lo suficientemente bueno” para la mayoría de las cargas empresariales, aunque no compita en benchmarks brutos.

Importancia de Ruby 3.3

  • Muchos ven la 3.3 como la versión de Ruby más importante en una década: YJIT listo para producción, el parser Prism, un mejor IRB, fibras/async y Ractors.
  • Otros no están convencidos y preguntan qué hay de fundamentalmente nuevo más allá de mejoras incrementales en velocidad y herramientas.

Rendimiento, YJIT y Benchmarks

  • Se informa de aumentos de velocidad del 10–15% en grandes aplicaciones Rails con YJIT habilitado; los microbenchmarks muestran ganancias de 2–3x en algunas cargas de trabajo limitadas por CPU.
  • Los críticos sostienen que, incluso con estas mejoras, Ruby sigue siendo órdenes de magnitud más lento que Go/Java/Rust y que esto no cambiará la reputación de Ruby como “lento”.
  • Contrapunto: en aplicaciones web típicas, la latencia está dominada por la BD/IO; Ruby es “lo suficientemente rápido”, y el costo del servidor suele ser menor que el tiempo de desarrollo.
  • Algunos describen casos reales en los que la sobrecarga de Django/Rails y el uso de recursos sí se convirtieron en un cuello de botella a una escala modesta.

Concurrencia y Runtime (Ractors, Fibers, RUBY_MAX_CPU)

  • Ractors y las fibras asíncronas se consideran funciones importantes poco comentadas, aunque su adopción práctica en Rails sigue sin estar clara.
  • El nuevo RUBY_MAX_CPU tiene un valor predeterminado de 8; algunos quieren que se vincule a los núcleos lógicos, otros señalan conteos de núcleos mal reportados y prefieren un valor conservador.
  • La resolución de nombres (getaddrinfo) ahora se ejecuta en hilos de trabajo para poder interrumpirse; esto añade una ligera sobrecarga pero permite comportamiento asíncrono.

Herramientas: Prism, LSP y Depuración

  • El parser Prism es elogiado como base para análisis estático más rápido, integración con RuboCop y servidores de lenguaje.
  • IRB recibe mejoras importantes (autocompletado, depuración), y se destaca la herramienta de depuración de Ruby (rdbg, Pry), aunque el metaprogramado pesado sigue siendo difícil de depurar.

Colas de trabajo e interoperabilidad entre lenguajes

  • Varios lamentan la falta de una cola de tareas de facto y multiplataforma para la integración Ruby–Python; muchas empresas simplemente usan Sidekiq (Ruby) y Celery (Python) por separado.
  • Opciones mencionadas: un sistema agnóstico al lenguaje basado en Redis/RabbitMQ, Faktory, el protocolo de Celery, beanstalkd, Gearman, dirq, SQS y colas DIY con Postgres/Redis.
  • Debate sobre monetización: algunas funciones de fiabilidad “imprescindibles” (por ejemplo, no perder trabajos en caso de fallo) están detrás de niveles de pago, algo que a algunos les disgusta y otros defienden como necesario para la sostenibilidad.

Imports y espacio de nombres global

  • El espacio de nombres global único de Ruby y la falta de imports de módulos dividen opiniones.
  • A algunos les gusta el estilo C de “solo cargar archivos” y las convenciones de autoloading de Rails/Zeitwerk; otros prefieren los imports explícitos al estilo Python y consideran engorrosa la resolución de constantes de Ruby.
  • Bibliotecas y propuestas experimentales intentan semánticas de importación más explícitas y modulares.

Salud del ecosistema y casos de uso

  • Una postura fuerte: Ruby/Rails alcanzó su pico hace años y está en declive a largo plazo frente a Python, TypeScript, Go, Rust y Java/Spring; muchas empresas web ya se han pasado a otras opciones.
  • La postura opuesta: aunque no está en su pico de 2007–2009, Ruby/Rails es estable o se está recuperando: nuevas conferencias, libros, gems y funciones (Rails 7, Hotwire, Turbo 8) indican una comunidad viva.
  • Hay consenso en que la mayor parte del uso de Ruby sigue siendo en aplicaciones web Rails; el uso fuera de Rails (CLIs, infraestructura, herramientas de seguridad, gestión de configuración) existe, pero es nicho.

Ruby frente a otros lenguajes: velocidad vs productividad

  • Un bando enfatiza la lentitud de Ruby y la reducción del mercado laboral, argumentando que el trabajo serio sensible al rendimiento pertenece a Go, Rust, Java, C#, etc.
  • El otro valora la expresividad de Ruby, su sólida biblioteca estándar (Strings/Arrays/Hashes), la cultura de pruebas (RSpec/MiniTest) y la “felicidad del desarrollador”, sosteniendo que la productividad y la simplicidad pesan más que la velocidad bruta en la mayoría de las aplicaciones empresariales.
  • Algunos señalan que Go/Rust pueden reducir drásticamente el número de servidores para APIs pesadas, pero también reconocen iteraciones más lentas y curvas de aprendizaje más pronunciadas.

Aprender Ruby y “mejor Bash”

  • Las recomendaciones varían: si ya se es productivo en Python/Node, Ruby puede no desbloquear capacidades fundamentalmente nuevas, pero es agradable y elegante.
  • Varios elogian Ruby como un “mejor bash/Perl” para scripting, procesamiento de texto y trabajo exploratorio de sistemas, especialmente con Pry/IRB, Sequel y APIs enumerable robustas.
  • Otros encuentran la sintaxis, los bloques y la cultura de metaprogramación de Ruby más difíciles de abordar que el estilo más minimalista y centrado en funciones de Python.