Pourquoi Ruby donne toujours l’impression d’être chez soi, même après toutes ces années

 (caio.ca)
1 points par GN⁺ 1 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Ruby n’est ni le langage le plus rapide ni le plus à la mode, mais il reste celui vers lequel on revient quand on veut vraiment prendre plaisir à travailler, même après avoir passé plus de 15 ans entre plusieurs langages
  • Les refinements, Forwardable, SimpleDelegator, Object#then, Kernel#tap et les paramètres numérotés apportent de petites commodités syntaxiques et un flux de lecture facile à suivre
  • La bibliothèque standard avec Thread::Queue, json, csv, ainsi que RuboCop et Ruby LSP, permet de conserver un environnement de développement pratique sans multiplier les petites gem ni les configurations complexes
  • Le YJIT de Ruby 3.x et le ZJIT de la série 4.x réduisent l’écart sur les tâches gourmandes en CPU, et dans une comparaison simple autour de Fibonacci, Ruby avec ZJIT se situait à moins de 2 à 3 fois Go
  • Même si Rust, Go et Python sont plus adaptés dans certains domaines, Ruby conserve comme points forts le bonheur des développeurs et la rapidité d’itération pour les applications web, les traitements en arrière-plan et les outils internes

Les raisons linguistiques qui rendent Ruby agréable

  • Ruby n’est ni le langage le plus rapide ni le plus tendance, mais même après plus de 15 ans à naviguer entre plusieurs langages, c’est encore celui qu’on choisit quand on veut réellement apprécier son travail
  • Les refinements permettent d’ouvrir une classe uniquement dans une portée limitée, ce qui autorise l’ajout de petites commodités syntaxiques dans un fichier ou un bloc sans polluer tout l’espace de noms
    • Ils conviennent bien aux helpers de test ou aux DSL internes dans de grandes bases de code
    • On peut utiliser une méthode comme "hello".quote uniquement là où using QuotingRefinement a été appelé
  • Forwardable et SimpleDelegator de la bibliothèque standard permettent une délégation propre sans écrire soi-même des méthodes wrapper ni importer des gem supplémentaires
    • Si l’on utilise déjà Rails, le delegate d’Active Support peut être plus pratique, mais la version Ruby de base garde les scripts généraux légers
  • Object#then et Kernel#tap permettent d’enchaîner des opérations dans une chaîne qui se lit de haut en bas, sans créer de variables intermédiaires
    • On peut relier création, journalisation, normalisation et sauvegarde avec un flux comme User.new(params).tap { ... }.then { ... }.save
  • Les paramètres numérotés introduits à partir de Ruby 2.7 réduisent le bruit dans les callbacks courts
    • Il n’est plus nécessaire d’expliciter les arguments de bloc, comme dans items.map { _1.price * 1.1 }
  • Le fiber scheduler permet d’écrire du code concurrent qui ressemble à du code séquentiel lorsqu’il est relié à une boucle d’événements
    • Il exprime du code coopérant avec d’autres fibers sous la forme Fiber.schedule do ... end

L’état actuel des outils, des performances et de l’écosystème

  • Le Ruby LSP de Shopify fournit une intégration à l’éditeur avec une configuration minimale et fonctionne bien avec Steep ou RBS pour une adoption progressive du typage
  • RuboCop aide à garder un style cohérent sans les procédures cérémonieuses que l’on voit dans d’autres écosystèmes
  • La bibliothèque standard reste une force discrète, car elle évite d’ajouter une multitude de petites gem pour les tâches courantes
    • Si l’on a besoin d’une file, on peut utiliser Thread::Queue
    • Pour analyser du JSON ou du CSV, les bibliothèques json et csv couvrent la plupart des cas d’usage réels sans gros formalisme
  • Après le YJIT de Ruby 3.x, la série 4.x accueille maintenant ZJIT
    • ZJIT est un JIT plus agressif reposant sur la même base, capable de compiler plus efficacement les chemins d’exécution les plus chauds
    • Les premiers chiffres montrent une réduction significative de l’écart avec des langages qui distançaient largement Ruby sur les tâches gourmandes en CPU
    • CRuby ZJIT est développé dans le dépôt principal de Ruby
  • Dans un benchmark simple comparant une implémentation récursive de Fibonacci sur la même machine, Ruby avec ZJIT se situait à moins de 2 à 3 fois Go, ne s’éloignait pas énormément de Rust optimisé sur ce cas précis, tandis que Python avec pypy était en retrait
    • Les microbenchmarks ont leurs limites, mais sur des chemins de code chauds laissant au JIT le temps d’optimiser, les applications réelles peuvent elles aussi en tirer des gains plus importants
  • Comparé à Rust, Ruby a l’avantage de la vitesse d’itération sur la logique métier
    • Avec Rust, on peut passer du temps à lutter avec le borrow checker pour des choses qui sont pourtant claires à l’exécution
    • Go excelle par ses primitives de concurrence, mais jusqu’à récemment il n’avait pas de generics, et sa gestion des erreurs assez rigide peut rendre un simple script plus lourd que nécessaire
    • Python est son cousin mental le plus proche, mais il demande davantage de boilerplate pour exprimer les mêmes idées de haut niveau, notamment autour des classes et des décorateurs
  • Quand on met du code dans un modèle, l’efficacité en tokens fonctionne aussi comme un avantage concret de Ruby
    • Les blocs peuvent s’écrire avec do/end ou des accolades, et les appels de méthode n’ont presque pas besoin de parenthèses lorsque la lisibilité le permet
    • Les hash et les arguments nommés sont des fonctionnalités de premier ordre et restent concis, ce qui permet de faire tenir davantage de logique réelle dans la même fenêtre de contexte que dans des langages plus chargés en bruit structurel
  • Les utilitaires de métaprogrammation de Ruby sont bien adaptés à la création d’API petites et lisibles
    • Des fonctionnalités comme define_method, class_eval ou l’interception des missing method permettent de construire des API expressives sans étape de génération de code
    • Des bibliothèques comme dry-rb ou aasm utilisent ces capacités avec retenue pour fournir des machines à états et des couches de validation propres
  • Les outils communautaires et les flux de déploiement ont eux aussi gagné en maturité
    • byebug et pry paraissent plus souples que beaucoup de débogueurs essayés ailleurs
    • Pour les tâches en arrière-plan, solid_queue et good_job sont suffisamment simples pour qu’on puisse comprendre l’ensemble de leur implémentation en un après-midi
    • Kamal a remplacé pour beaucoup les anciennes procédures de style capistrano et donne vraiment l’impression d’un outil conçu par des gens qui font tourner de petites équipes
  • Cela ne signifie pas que Ruby bat Rust ou Go sur tous les sujets, et il existe bien des domaines où Rust ou Go sont plus adaptés
  • Dans cette vaste zone intermédiaire que sont les applications web, le traitement en arrière-plan et les outils internes, Ruby continue d’offrir le bonheur des développeurs sans cérémonial excessif ni changements de contexte incessants
  • Les petites commodités et la sensation générale du langage restent ce qui donne envie d’y revenir en premier, même après plus de dix ans, et les nouveaux travaux sur les JIT ainsi que les améliorations continues du langage ne font que renforcer cette impression

À lire aussi

  • Ruby 4.0.0
    6 points · 1 commentaires · 2025-12-26

1 commentaires

 
GN⁺ 1 시간 전
Avis sur Lobste.rs

  • J’ai du mal à être d’accord avec l’expression « RuboCop sans cérémonie »
    Avec RuboCop, il y a tout de même beaucoup de discussions sur les cops à choisir et à configurer, ainsi que sur l’activation ou non des nouveaux cops ajoutés dans les mises à jour récentes
    StandardRB se rapproche bien davantage d’une approche sans prise de tête, mais au final il faut quand même en choisir un
    Les langages qui intègrent le linting nativement sont bien moins pénibles que Ruby sur ce point, et suscitent aussi moins de débats de style insignifiants

    • J’ai choisi Standard pour la codebase de Sidekiq il y a une dizaine d’années, et je ne l’ai jamais regretté
      Les contraintes apportent au contraire de la liberté
    • Pourquoi ne pas simplement tout utiliser avec les valeurs par défaut ?
      Je suis plutôt opposé à la configuration des linters en général, et je préférerais laisser ce genre de décisions aux valeurs par défaut de la communauté
    • Honnêtement, je change moi-même d’avis sur ce point
      D’un côté, les valeurs par défaut de RuboCop sont déjà très correctes, donc je pense qu’il vaut mieux les suivre et les faire évoluer ensemble plutôt que de fragmenter davantage les styles de code
      D’un autre côté, c’est parfois trop prescriptif, au point qu’on se dit qu’un outil comme standard.rb a sa raison d’être
      J’ai écrit ça du point de vue de quelqu’un qui apprend Ruby ou y revient, et qui aimerait pouvoir coder confortablement sans devoir gérer une multitude de gem
    • Entièrement d’accord
      Quand Go est sorti, j’avais trouvé excellent qu’il fournisse un système de formatage officiel unique
      Le cerveau est une machine à faire du pattern matching : une fois habitué, on n’y pense même plus, mais dès qu’il y a plusieurs options, ça devient inconfortable et tout le monde est tiraillé dans un sens ou dans l’autre
      Le problème, c’est que ni RuboCop ni Standard ne peuvent avoir cette autorité dans Ruby
      Cette autorité devrait venir de la core team, mais comme cela irait à l’encontre de la philosophie de Ruby, cela risque peu d’arriver
      Dans mes projets, je désactive tous les cops de RuboCop et je n’en active qu’une partie
      Les guillemets simples, c’est le sommet 😀
    • Moi aussi, ça m’a fait tiquer à cet endroit
      D’autres billets semblent pointer la même chose : https://caio.ca/blog/coding/my-complicated-relationship - « The Wild West of Code Formatting »
      En gros : « Ce n’est pas une solution simple intégrée. Il y a des centaines de cops configurables, ce qui mène à des débats sans fin sur les règles à activer »

  • Globalement d’accord, mais je trouve un peu dommage de prendre refinements comme premier exemple
    Je comprends pourquoi on peut aimer ça, mais c’est plutôt le genre de chose où il vaut mieux ne pas trop savoir comment la saucisse est fabriquée
    La sémantique est tellement délicate que, même 10 ans après son introduction, on continue à trouver des bugs pénibles dans MRI
    Par exemple, rien qu’au cours des deux dernières semaines, il y a eu https://bugs.ruby-lang.org/issues/22071 et https://bugs.ruby-lang.org/issues/22058
    Côté performances aussi, cela complique beaucoup d’optimisations, et on voit la même chose se reproduire actuellement avec boxes

    • L’idée des boxes semble difficile à greffer après coup dans un langage où tout vit depuis des décennies dans le même espace de noms global
      Même au niveau de l’implémentation, il doit encore y avoir beaucoup de bugs cachés, et probablement aussi du côté des bibliothèques
      Je n’utilise plus beaucoup Ruby aujourd’hui, mais je suis curieux de voir comment cela va s’installer
      Ça a l’air intéressant

  • Ce billet recoupe beaucoup mon expérience dans mon article « Returning to Rails »[1]
    C’est peut-être un biais de confirmation, mais j’ai l’impression qu’on est de plus en plus nombreux à redécouvrir, ou à reconnaître de nouveau, la beauté du code Rails
    Cela me fait aussi penser au phénomène selon lequel les goûts musicaux ou artistiques se figent à la fin de l’adolescence ou au début de la vingtaine
    Peut-être que ceux qui ont découvert Ruby pendant l’« âge d’or » de Rails regardent aujourd’hui l’époque de Rails 3 et de Capistrano avec des lunettes roses
    À l’époque, j’étais plongé jusqu’au cou dans une boîte Ruby, entouré uniquement de développeurs Rails, donc j’avais l’impression qu’il y avait du Ruby partout
    Mais en voyant dans le fil lobste.rs[2] l’idée que Ruby a en réalité toujours été un langage assez de niche, je me dis que cela a peut-être joué aussi
    Malgré tout, Ruby continue de me donner l’impression d’être à la maison, et de fonctionner exactement comme mon cerveau fonctionne
    Il n’y a presque pas de traduction mentale à faire, peu de surprises, et on a l’impression de parler à un ami plutôt que de rédiger un article académique formel
    Je n’ai toujours pas trouvé d’autre langage qui me convienne aussi bien, et je ne pense pas que ce soit seulement une histoire de « les jeunes de nos jours »
    Quoi qu’il en soit, je suis heureux que ça ait survécu aussi longtemps
    Et merci d’avoir montré l’enchaînement « tap / new »
    J’ai trouvé cette structure si élégante et utile qu’elle m’a vraiment fait m’arrêter un instant, et je pense bien l’essayer
    PS - Sans lien direct avec le sujet, mais l’avatar IA de la page d’accueil est assez dérangeant
    Il donne vraiment une impression de vallée dérangeante du type « est-ce qu’un bot a écrit cet article ? »
    À chaque fois que j’en vois un, je me demande brièvement si je suis bien en train de parler à un humain réel
    [1]=https://www.markround.com/blog/2026/03/05/returning-to-rails-in-2026/
    [2]=https://lobste.rs/s/jreqtw/returning_rails_2026

    • Je peux affirmer avec certitude que je suis une vraie personne
      Je ne souhaite simplement pas publier une vraie photo, et cet avatar ressemble suffisamment à moi pour que les gens qui me connaissent puissent me reconnaître

  • Ruby 3.4 a ajouté le paramètre de bloc it, qui peut être utilisé à la place de _1 dans l’exemple

    items.map { it.price * 1.1 }

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

    • J’avais oublié de mentionner it
      C’est peut-être parce que c’est relativement récent, mais je n’arrive toujours pas à prendre l’habitude de taper it dans les itérateurs

  • J’adorais vraiment écrire du code en Ruby, mais la charge des tests est devenue trop lourde
    Je pensais qu’ajouter un peu plus de sûreté de typage au langage aiderait, mais quand #{last_job} a introduit Sorbet dans la codebase, l’élan et le plaisir d’écrire du code se sont complètement évaporés
    Ce n’est peut-être pas une opinion populaire, mais le simple fait que quelque chose comme Sorbet existe me semble davantage être un mauvais signal pour Ruby
    Ruby lui-même est un langage puissant et amusant, mais les gens ont commencé à l’utiliser pour des tâches pour lesquelles il n’avait pas été conçu à l’origine, et dans ce processus ils ont commencé à lui ajouter des outils pour compenser les anti-fonctionnalités du langage
    À ce stade, chaque ligne était devenue une corvée ennuyeuse, et je passais bien plus de temps à attendre divers outils de build, de test et de lint qu’à écrire du vrai code
    En ajoutant à cela des processus de build et de déploiement surconçus, même les tâches les plus basiques prenaient énormément de temps et le travail était devenu pénible
    Le monde Ruby d’environ 2012 me manque beaucoup
    Avec le recul, c’était vraiment une belle époque

    • D’après ton expérience, quel langage était plus adapté ?
      J’ai compris « tâches pour lesquelles il n’avait pas été conçu à l’origine » comme une allusion aux grosses applications Rails

  • Je suis revenu à Ruby après 10 ans, et à l’ère de l’« IA », il est utile de pouvoir réellement comprendre le code qui défile devant soi et de pouvoir diriger ou stopper un LLM
    C’est plus difficile avec des langages plus verbeux

  • Ruby me manque, et plus encore, le fait même qu’un tel langage puisse exister dans la production quotidienne me manque
    C’était un espoir, ou plutôt l’espoir lui-même
    En tout cas, ça l’a longtemps été pour moi

    • Qu’est-ce qui s’est passé ?

  • On dirait un article bâclé par une IA
    D’autres billets de blog récents donnent la même impression

    • Je n’ai pas perçu ce genre de signe
      Qu’est-ce qui t’a fait penser ça ?
      C’est bien de signaler les articles générés par IA de mauvaise qualité sur ce site, mais il faut éviter les faux positifs et expliquer précisément pourquoi on pense cela
    • Pour moi, ça ne ressemblait pas à un article bâclé par une IA
      Pourquoi tu as eu cette impression ?
      Ce genre d’alerte est utile, mais je préfère largement quand elle s’accompagne de raisons précises

  • J’ai un bon souvenir d’avoir travaillé avec Ruby au début de ma carrière
    Il y a vraiment quelque chose d’agréable dans Ruby
    En revanche, quand j’ai réutilisé un peu Ruby récemment, probablement l’an dernier, j’ai trouvé qu’il était difficile de naviguer dans la documentation web de la bibliothèque standard
    Est-ce que je suis le seul ? Existe-t-il des alternatives à la documentation de ruby-lang.org ?

  • Cet article me semble un peu étrange
    J’ai eu l’occasion d’écrire un projet et un SDK en Ruby, et cela ne m’a absolument pas donné envie de réutiliser Ruby un jour