Amo Ruby
Ruby, con su foco en la felicidad del desarrollador, su sintaxis expresiva y sus características favorables a los DSL, sigue inspirando un profundo afecto, especialmente para prototipado rápido y trabajo web con Rails, pero también plantea preocupaciones sobre mantenibilidad, comportamiento implícito y herramientas débiles frente a ecosistemas tipados modernos. Los comentaristas contraponen el estilo de Ruby de “se lee como inglés” y su potente metaprogramación con la seguridad y el soporte del IDE de lenguajes como Rust, Kotlin, TypeScript y Python, a menudo citando los sistemas de tipos y la explicitud como razones para haberse alejado. Gran parte del debate gira en torno a las compensaciones entre productividad y claridad a largo plazo: código alegre y conciso frente a los desafíos de depurar la magia, razonar sobre variables globales y trabajar en bases de código grandes y longevas.
Sentimiento general
- Muchos comentaristas dicen que Ruby es de una alegría y productividad únicas, especialmente para “hacer las cosas” y prototipar.
- Otros detestan activamente trabajar en Ruby, en particular en bases de código grandes o heredadas, citando problemas de mantenibilidad y “magia”.
- Varios ya no usan Ruby a diario, pero conservan un fuerte cariño por él.
Expresividad y sintaxis
- Quienes lo apoyan destacan su estilo de “se lee como prosa”, los métodos predicados con
?, los bloques/yieldy las operaciones encadenadas deEnumerablecomo altamente expresivos. - Los críticos argumentan que “se lee como inglés” está sobrevalorado; el lenguaje natural es impreciso, y el código muy basado en DSL puede ser más difícil de seguir que el código simple.
- Hay debate sobre qué significa siquiera “expresivo”; algunos lo vinculan al poder de los DSL/metaprogramación, otros lo ven como una etiqueta vaga para “me gusta este lenguaje”.
Tipos y herramientas
- Muchos pasaron de Ruby a Rust, TypeScript, Kotlin, etc., diciendo que ya no pueden vivir sin una tipificación estática fuerte.
- La historia de tipado gradual de Ruby (Sorbet, RBS) es vista ampliamente como torpe o dolorosa; algunos sienten que Ruby “necesita” mejores tipos integrados, otros dicen que eso traicionaría su naturaleza de paso de mensajes.
- Las herramientas se perciben más débiles que en ecosistemas tipados: ir a la definición y el análisis estático son frágiles, especialmente en Rails/código metaprogramado. Algunos señalan que las herramientas LSP/de depuración más nuevas están mejorando esto.
Metaprogramación, “magia” y mantenibilidad
- Ruby (y especialmente Rails) es elogiado por su potente metaprogramación y sus DSLs (RSpec, Cucumber, rutas/validaciones de Rails), que resultan elegantes y concisos.
- Las mismas características son criticadas por su comportamiento opaco e implícito: métodos generados dinámicamente, uso intensivo de herencia, estado mutable global y cadenas profundas de abstracción dificultan el razonamiento local.
- La gente describe la dificultad de rastrear dónde se define un método o por qué ocurre algo; otros responden que la introspección en tiempo de ejecución (pry,
method(...).source_location) es el flujo de trabajo previsto.
Comentarios y documentación
- Hay un fuerte desacuerdo sobre “el código como documentación”. Algunos rubyistas escriben pocos comentarios y confían en código claro, de alto nivel, y en DSLs.
- Muchos sostienen que los comentarios son esenciales para explicar el “por qué”, las decisiones de diseño y las restricciones no obvias; la ausencia de esos comentarios se ve como un olor de mantenibilidad.
Rendimiento, ecosistema y empleos
- Algunos dicen que el rendimiento de Ruby suele ser suficientemente bueno para trabajo web, donde dominan la latencia de la base de datos o de la red; otros prefieren lenguajes más rápidos o más tipados para backends serios.
- Ruby es elogiado por un ecosistema agradable y una comunidad amable, pero varios perciben un descenso en las oportunidades de empleo en Ruby/Rails frente a TypeScript/React y otros stacks.