Por qué Ruby sigue sintiéndose como hogar incluso después de mucho tiempo

 (caio.ca)
1 puntos por GN⁺ 1 시간 전 | 1 comentarios | Compartir por WhatsApp
  • Ruby no es el lenguaje más rápido ni el más de moda, pero incluso después de pasar por varios lenguajes durante más de 15 años, sigue siendo el que uno vuelve a elegir cuando quiere disfrutar el trabajo
  • refinements, Forwardable, SimpleDelegator, Object#then, Kernel#tap y los parámetros numerados ofrecen pequeñas comodidades sintácticas y un flujo fácil de leer
  • Thread::Queue, json y csv de la biblioteca estándar, junto con RuboCop y Ruby LSP, permiten mantener un entorno de desarrollo práctico sin gems pequeñas ni configuraciones complejas
  • YJIT en Ruby 3.x y ZJIT en 4.x están reduciendo la brecha en tareas intensivas de CPU, y en una comparación simple de Fibonacci, Ruby con ZJIT quedó a una distancia de 2 a 3 veces respecto a Go
  • Aunque hay áreas donde Rust, Go y Python son más adecuados, en apps web, procesamiento en segundo plano y herramientas internas, la felicidad del desarrollador y la velocidad de iteración siguen siendo fortalezas de Ruby

Razones del lenguaje por las que Ruby se siente cómodo

  • Ruby no es el lenguaje más rápido ni el más de moda, pero incluso después de moverse entre varios lenguajes durante más de 15 años, sigue siendo el lenguaje al que se vuelve cuando de verdad se quiere disfrutar el trabajo
  • refinements permite abrir clases solo dentro de un alcance limitado, así que se pueden agregar pequeñas comodidades sintácticas dentro de un archivo o bloque sin contaminar todo el espacio de nombres
    • Encaja bien con helpers de pruebas o DSL internos en bases de código grandes
    • Métodos como "hello".quote solo se pueden usar donde se invoque using QuotingRefinement
  • Forwardable y SimpleDelegator de la biblioteca estándar permiten una delegación limpia sin tener que escribir métodos envoltorio a mano ni traer gems adicionales
    • Si ya se usa Rails, delegate de Active Support puede ser más cómodo, pero la versión base de Ruby mantiene ligeros los scripts generales
  • Object#then y Kernel#tap permiten encadenar operaciones en un flujo que se lee de arriba hacia abajo sin crear variables intermedias
    • Se puede escribir un flujo de creación, logging, normalización y guardado como User.new(params).tap { ... }.then { ... }.save
  • Los parámetros numerados desde Ruby 2.7 reducen el ruido en callbacks cortos
    • No hace falta declarar explícitamente los argumentos del bloque en algo como items.map { _1.price * 1.1 }
  • El fiber scheduler permite escribir código concurrente que se ve como código secuencial cuando se conecta a un event loop
    • Expresa código que coopera con otras fibers en la forma Fiber.schedule do ... end

Estado actual de herramientas, rendimiento y ecosistema

  • Ruby LSP de Shopify ofrece integración con el editor con configuración mínima, y funciona bien junto con Steep o RBS para una adopción gradual de tipos
  • RuboCop ayuda a mantener un estilo consistente sin los procesos ceremoniales que se ven en otros ecosistemas
  • La biblioteca estándar sigue siendo una fortaleza silenciosa, porque evita tener que agregar varias gems pequeñas para tareas comunes
    • Si se necesita una cola, se puede usar Thread::Queue
    • Para parsear JSON o CSV, las bibliotecas json y csv cubren la mayoría de los casos reales sin demasiado trámite
  • Después de YJIT en Ruby 3.x, la serie 4.x está incorporando ZJIT
    • ZJIT es un JIT más agresivo sobre la misma base, y compila de forma más efectiva las rutas de ejecución más calientes
    • Los números iniciales muestran que la diferencia con lenguajes que antes sacaban una gran ventaja a Ruby en tareas intensivas de CPU se ha reducido de forma significativa
    • CRuby ZJIT se está desarrollando en el repositorio principal de Ruby
  • En un benchmark simple que comparó implementaciones recursivas de Fibonacci en la misma máquina, Ruby con ZJIT quedó a una distancia de 2 a 3 veces respecto a Go, no muy lejos de Rust optimizado en ese caso, mientras que Python con pypy quedó por detrás
    • Los microbenchmarks tienen limitaciones, pero en rutas de código ya calientes donde el JIT tiene tiempo para optimizar, las aplicaciones reales también pueden beneficiarse más
  • Comparado con Rust, Ruby destaca en la velocidad de iteración de la lógica de negocio
    • En Rust puede terminar invirtiéndose tiempo en pelear con el borrow checker incluso para cosas que en tiempo de ejecución son claras
    • Go tiene excelentes primitivas de concurrencia, pero hasta hace poco no tenía generics, y su manejo algo rígido de errores puede hacer que scripts simples se sientan más pesados de lo necesario
    • Python es el primo mental más cercano, pero suele requerir más boilerplate para expresar ideas similares de alto nivel, especialmente alrededor de clases y decoradores
  • Al poner código dentro del modelo, la eficiencia de tokens también funciona como una ventaja real de Ruby
    • Los bloques pueden expresarse con do/end o llaves, y si la legibilidad lo permite, casi nunca hacen falta paréntesis en llamadas a métodos
    • Los hashes y los argumentos con palabra clave son funciones de primera clase y concisas, así que cabe más lógica real en la misma ventana de contexto que en lenguajes con mucho ruido estructural
  • Las utilidades de metaprogramación de Ruby son buenas para crear APIs pequeñas y legibles
    • Funciones como define_method, class_eval o la intercepción de métodos faltantes permiten crear APIs expresivas sin una etapa de generación de código
    • Bibliotecas como dry-rb o aasm usan estas capacidades con moderación para ofrecer máquinas de estado y capas de validación limpias
  • Las herramientas de la comunidad y los flujos de despliegue también han madurado
    • byebug y pry se sienten más flexibles que muchos depuradores usados en otros entornos
    • En trabajos en segundo plano, solid_queue y good_job son tan simples que resulta posible entender toda la implementación en una tarde
    • Kamal ha reemplazado para muchos los viejos procesos al estilo capistrano, y de verdad se siente como una herramienta hecha por gente que opera equipos pequeños
  • Esto no significa que Ruby supere a Rust o Go en todo, y sí hay áreas donde Rust o Go encajan mejor
  • Pero en la amplia zona intermedia de aplicaciones web, procesamiento en segundo plano y herramientas internas, Ruby sigue ofreciendo felicidad del desarrollador sin ceremonias excesivas ni cambios constantes de contexto
  • Las pequeñas comodidades y la sensación general del lenguaje siguen siendo lo que hace que uno lo elija primero incluso después de más de diez años, y el nuevo trabajo en JIT junto con las mejoras constantes del lenguaje refuerzan todavía más esa razón

Lecturas relacionadas

  • Ruby 4.0.0
    6 puntos · 1 comentarios · 2025-12-26

1 comentarios

 
GN⁺ 1 시간 전
Opiniones en Lobste.rs

  • Me cuesta estar de acuerdo con la expresión de "RuboCop sin ceremonias"
    Con RuboCop hay bastante discusión sobre qué cops elegir y ajustar, y sobre si conviene activar o no los nuevos cops que van agregando en actualizaciones recientes
    StandardRB se acerca mucho más a un enfoque sin tanta ceremonia, pero al final igual hay que elegir uno
    Los lenguajes que traen el lint integrado son mucho menos engorrosos que Ruby y también tienen menos discusiones de estilo por cosas triviales

    • Elegí Standard para el codebase de Sidekiq hace como 10 años y nunca me arrepentí
      Las restricciones, de hecho, dan libertad
    • ¿No bastaría con usar todos los valores por defecto?
      En general estoy en contra de configurar el linter, y preferiría dejar este tipo de decisiones en manos de los valores por defecto de la comunidad
    • Si soy sincero, con eso voy y vengo
      Por un lado, creo que los valores por defecto de RuboCop son lo bastante buenos como para seguirlos y hacerlos evolucionar juntos, en vez de fragmentar todavía más el estilo de código
      Por otro lado, a veces tiene opiniones demasiado fuertes, y ahí sí parece necesario algo como standard.rb
      Escribí desde la perspectiva de alguien que está aprendiendo Ruby o quiere volver a él y no debería tener que lidiar con montones de gems solo para poder escribir código de forma cómoda
    • Coincido al 100%
      Cuando salió Go, me pareció una gran decisión que trajera un único sistema oficial de formateo
      El cerebro es una máquina de reconocer patrones, así que una vez que te acostumbras simplemente lo pasas por alto, pero cuando hay opciones te genera incomodidad y todos terminan jalando para un lado u otro
      El problema es que ni RuboCop ni Standard pueden tener esa autoridad en Ruby
      Esa autoridad tendría que venir del equipo core, pero probablemente no ocurra porque va en contra de la filosofía de Ruby
      En mis proyectos apago todos los cops de RuboCop y solo activo algunos
      Las comillas simples son lo máximo 😀
    • Yo también me detuve un momento en esa parte
      Parece que otro artículo también señala esto: https://caio.ca/blog/coding/my-complicated-relationship - "The Wild West of Code Formatting"
      Va por la línea de: “No es una solución simple integrada. Hay cientos de cops configurables, lo que lleva a discusiones interminables sobre qué reglas activar”

  • En general estoy de acuerdo, pero me decepciona un poco que refinements sea el primer ejemplo
    Entiendo por qué te gusta, pero entra más en la categoría de cosas de las que es mejor no saber cómo se hace la salchicha
    La semántica es tan delicada que incluso 10 años después de su introducción siguen apareciendo bugs complicados en MRI
    Por ejemplo, solo en las últimas 2 semanas hubo https://bugs.ruby-lang.org/issues/22071 y https://bugs.ruby-lang.org/issues/22058
    También desde el punto de vista del rendimiento complica muchas optimizaciones, y ahora está volviendo a pasar algo parecido con boxes

    • La idea de boxes parece difícil de encajar a estas alturas en un lenguaje donde todo ha vivido durante décadas en el mismo espacio de nombres global
      Me imagino que a nivel de implementación todavía debe haber muchos bugs escondidos, y probablemente del lado de las librerías también
      Ya no uso mucho Ruby, pero me da curiosidad ver cómo termina asentándose esto
      Se ve interesante

  • Este artículo también se superpone bastante con mi experiencia en mi texto “Returning to Rails”[1]
    Puede ser sesgo de confirmación, pero me da la impresión de que cada vez más gente está redescubriendo o volviendo a apreciar la belleza del código Rails
    Aunque también me hace pensar en ese fenómeno de que los gustos musicales o artísticos se fijan entre el final de la adolescencia y los veintitantos
    Quizá quienes conocieron Ruby por primera vez durante la “edad dorada” de Rails están mirando hacia atrás, a la época de Rails 3 y Capistrano, con lentes color de rosa
    En ese momento yo estaba muy metido en el “shop” de Ruby y además todo mi entorno eran desarrolladores de Rails, así que sentía que Ruby estaba en todas partes
    Pero al ver en un hilo de lobste.rs[2] la opinión de que Ruby en realidad siempre fue un lenguaje bastante de nicho, pensé que eso también pudo haber influido
    Aun así, Ruby se sigue sintiendo como casa, y parece funcionar exactamente como funciona mi cabeza
    Casi no hay traducción mental, rara vez me sorprende, y se siente más como hablar con un amigo que como redactar un ensayo formal
    Todavía no encuentro otro lenguaje que me encaje así, y no creo que todo se deba solo a una mentalidad de “los jóvenes de hoy”
    En cualquier caso, me alegra que siga vivo después de tanto tiempo
    Y gracias por mostrar esa cadena de “tap / new”
    Esa estructura me pareció tan bonita y útil que me hizo detenerme un momento, y seguro voy a probarla
    PD: no está directamente relacionado con el tema, pero el avatar de IA de la página principal da un poco de escalofríos
    Me da una fuerte sensación de valle inquietante, como de “¿esto lo escribió un bot?”
    Cada vez que veo algo así, me quedo pensando un instante si de verdad estoy hablando con un 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

    • Puedo asegurar que sí soy una persona real
      Solo que no quiero publicar una foto real, y ese avatar sí se parece lo suficiente como para que la gente que me conoce me reconozca

  • Ruby 3.4 agregó el parámetro de bloque it, que puede usarse en lugar de _1 en el ejemplo

    items.map { it.price * 1.1 }

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

    • Se me olvidó mencionar it
      Como es una función relativamente reciente, por alguna razón no logro acostumbrarme a escribir it en iteradores

  • De verdad me encantaba escribir código en Ruby, pero la carga de pruebas se volvió demasiado grande
    Pensé que quizá ayudaría añadirle algo más de seguridad de tipos al lenguaje, pero cuando metimos Sorbet al codebase en #{last_job}, se murió por completo el impulso y la diversión de escribir código
    Puede que sea una opinión impopular, pero para mí el simple hecho de que exista algo como Sorbet ya es más bien una mala señal para Ruby
    Ruby en sí es un lenguaje potente y divertido, pero la gente empezó a usarlo para trabajos para los que no fue diseñado originalmente, y en ese proceso comenzaron a apilar herramientas para compensar las anti-funciones del lenguaje
    Llegó un punto en que cada línea se sentía como una tarea pesada y aburrida, y pasaba mucho más tiempo esperando varias herramientas de build, pruebas y lint que escribiendo código real
    Si a eso le sumas procesos de build y despliegue sobreingenierizados, incluso hacer cosas básicas tomaba mucho tiempo y trabajar se volvió doloroso
    Extraño muchísimo el mundo Ruby de alrededor de 2012
    Viéndolo en retrospectiva, de verdad fueron muy buenos tiempos

    • En tu experiencia, ¿qué lenguaje resultó más adecuado?
      Entendí que con “trabajos para los que no fue diseñado originalmente” te referías a aplicaciones grandes de Rails

  • Volví a Ruby después de 10 años, y en la era de la “IA” es útil poder entender de verdad el código que pasa frente a ti y también poder orientar o frenar a los LLM
    En lenguajes más verbosos, eso es más difícil

  • Extraño Ruby, y más aún extraño la mera posibilidad de que exista un lenguaje así en producción cotidiana
    Era esperanza, o mejor dicho, la esperanza misma
    Al menos para mí, lo fue durante mucho tiempo

    • ¿Qué pasó?

  • Se lee como un texto hecho al aventón por IA
    Otros posts recientes del blog también se sienten así

    • Yo no percibí esa señal
      ¿Qué indicios te hicieron verlo así?
      Está bien señalar contenido de baja calidad generado por IA en este sitio, pero hay que evitar falsos positivos y decir con precisión por qué se piensa eso
    • A mí no me pareció un texto hecho al aventón por IA
      ¿Por qué te dio esa impresión?
      Me parece bien hacer ese tipo de advertencias, pero prefiero mucho más que vengan acompañadas de las razones

  • Tengo buenos recuerdos de haber trabajado con Ruby al inicio de mi carrera
    Ruby tiene de verdad algo muy agradable
    Pero cuando usé un poco de Ruby recientemente, creo que el año pasado, sentí que era difícil navegar la documentación de la biblioteca estándar en la web
    ¿Soy solo yo? ¿Hay alguna alternativa a la documentación de ruby-lang.org?

  • Este artículo se siente medio raro
    Tuve la oportunidad de escribir un proyecto y un SDK en Ruby, y no me quedaron nada de ganas de volver a usar Ruby