Réponse à « Ruby n’est pas un langage de programmation sérieux »

• En réponse à la vision selon laquelle Ruby ne serait pas un langage « sérieux », Ruby est un langage qui rend la programmation plus humaine et plus agréable
• La communauté Ruby est née comme une petite rébellion légère, en mettant l’accent sur la clarté et l’accessibilité plutôt que sur la complexité
• Des services à grande échelle comme Shopify, Doximity, GitHub fonctionnent avec Ruby, ce qui prouve des résultats concrets
• Le cœur de Ruby réside dans l’expérience des personnes qui écrivent le code et dans une culture de développement durable, ce qui correspond à une attitude d’attention et de respect, pas à une simple nostalgie
• Dans le futur du développement logiciel, la lisibilité, la maintenabilité et le plaisir deviendront encore plus importantes, et Ruby restera un repère pertinent

---

Ruby et la notion de « sérieux »

• La question « Ruby est-il un langage sérieux ? » révèle une différence de perception sur les émotions que la programmation doit porter
  • Certaines personnes considèrent qu’un outil agréable à utiliser n’est pas sérieux, mais Ruby ne partage pas cette définition
• Les débuts de Ruby étaient remplis d’une petite communauté avec une énergie espiègle, montrant qu’il n’est pas nécessaire que la programmation soit oppressive
• Les critiques de l’époque venaient surtout d’architectes Java ou de développeurs d’entreprise traditionnels, et la communauté Ruby s’en est détachée pour rester concentrée sur la construction de produits concrets

Un langage centré sur l’accessibilité et la productivité

• Ruby privilégie l’accessibilité plutôt que la simple simplicité afin d’aider les débutants et les petites équipes à grandir rapidement
  • Plutôt que la théorie complexe, Ruby mise sur le momentum et la clarté, permettant de développer sans angoisse
• Grâce à ces qualités, les bootcamps et les startups ont adopté Ruby, ce qui convenait aux environnements privilégiant la vitesse et la créativité
• Comme dans le cas de Twitter, Ruby a suffisamment contribué à la croissance d’une entreprise, et la migration ultérieure vers d’autres technologies a été présentée comme le résultat du succès

Fiabilité en conditions réelles et exemples concrets

• Selon des années d’expérience en conseil, aucune équipe n’a échoué en choisissant Ruby ; au contraire, la complexité, l’hésitation et une grande gravité excessive étaient les causes d’échec
• Ruby est apprécié comme un langage qui ne gêne pas le développeur et lui permet de se concentrer sur son travail principal
• Des services clés comme Shopify, Doximity, GitHub sont exploités avec Ruby, ce qui est présenté comme une preuve pragmatique, pas émotionnelle (proof)

Culture Ruby et philosophie de développement centrée sur l’humain

• Ruby attire ceux qui valorisent la sensibilité d’écriture du code et l’expérience de lecture, ce qui constitue une manière durable de produire des logiciels plutôt qu’une simple nostalgie
• La communauté Ruby met l’accent sur l’expressivité et l’orientation humaine, rappelant que programmer est un acte au service des personnes
• Les différences avec ceux qui préfèrent d’autres langages relèvent de la préférence, et Ruby ne cherche pas à convaincre tout le monde

Programmation de demain et rôle de Ruby

• L’avenir du développement logiciel ne sera pas dominé par un langage, un paradigme ou une idéologie unique, mais se déploiera sous une forme mixte et flexible
• À l’ère où l’IA écrit du code, la lisibilité et la maintenabilité deviennent encore plus importantes, et dans un environnement où le burn-out se banalise, le plaisir devient une valeur centrale
• Les valeurs de Ruby – clarté, empathie, humanité – ne sont pas un héritage du passé, mais un repère pour l’avenir

Un code qui résonne au-delà du « sérieux »

• La société et les affaires récompensent davantage la résonance que le « sérieux », ainsi que la clarté et l’humanité
  • Les candidats, musiciens, artistes, startups et ingénieurs dits sérieux ne réussissent pas toujours
• Ruby vise un code pour l’équipe et une programmation pour les personnes, et cette approche maintient l’industrie de manière plus humaine
• Les développeurs curieux et enjoués joueront un rôle important dans l’écosystème technologique de demain, et Ruby restera un langage signifiant dans ce mouvement

Conclusion

• La question « Ruby est-il un langage sérieux ? » est une mauvaise question
• La question plus juste serait « Ruby peut-il encore apporter une contribution significative à la prochaine génération de logiciels ? », et la réponse est oui
• Si cela signifie qu’il n’est pas « sérieux », c’est précisément pour cela que Ruby doit être inclus dans la conversation

[xguru]

Le Ruby n’est pas un langage de programmation sérieux

[GN⁺]

Avis Hacker News

• Je pense que le cas Twitter, souvent cité pour détester Ruby, n’est pas pertinent
  Même si Ruby en avait été la cause, ce choix a permis de lancer l’activité et d’obtenir un premier succès
  Le problème de Twitter ne venait pas du langage, mais d’une situation particulière de fan-out à très grande échelle (tweet de célébrité → millions d’abonnés)
  Et personne ne parle des startups qui ont échoué malgré un langage « extensible dès le départ » — c’est un classique biais du survivant
  En regardant la page auteur Wired concernée, on a l’impression qu’il pratique stratégiquement l’écriture polémique
  Je retourne donc parmi la majorité silencieuse qui continue à faire des logiciels utiles en Ruby
  • Il y a aussi le contre-argument suivant : « Sans Ruby, on aurait pu lancer la même activité avec un meilleur langage et éviter ces problèmes »
  • Beaucoup de temps a passé, et le Ruby d’aujourd’hui n’a plus rien à voir avec celui de l’époque
• Dans l’article original, l’auteur n’expliquait pas concrètement pourquoi il détestait Ruby
  Il se contentait d’énumérer d’anciennes limites, alors qu’en réalité le problème venait peut-être surtout de la codebase dont il avait la charge
  Le point central du premier article était : « En 2025, il n’y a plus de raison de choisir Ruby pour un nouveau projet », et c’est là-dessus que la discussion aurait dû porter
  Ce nouvel article prend un virage émotionnel et, ironiquement, confirme lui-même l’argument précédent selon lequel Ruby fonctionnerait à l’affect
  Beaucoup de gens qui aiment Elixir voient Ruby comme un langage « non sérieux », alors qu’Elixir lui-même est fortement influencé par Ruby
  • J’utilise Elixir depuis plusieurs années, et j’ai aussi fait du Ruby au début
    Beaucoup de gens sont attirés par Elixir parce qu’il combine la syntaxe familière de Ruby avec une base fonctionnelle
    Surtout, ses propriétés en exploitation sont totalement différentes grâce à la runtime BEAM
    BEAM donne l’impression de ne pas être un simple langage, mais un système pour les systèmes — on peut tout tracer, redémarrer et observer
  • Je suis surpris que Crystal, langage compilé inspiré de Ruby, ne soit pas mentionné
    Cela dit, Crystal souffre encore plus qu’Elixir d’un manque de popularité
    Selon le classement TIOBE, Elixir figure dans le top 50
  • Ruby est installé par défaut sur macOS, donc pour écrire des scripts sans rien installer de plus, il faut choisir entre Perl, Bash, AppleScript ou Ruby
  • Les deux articles m’ont semblé creux
    Le premier ne parle que des statistiques StackOverflow et de Twitter, le second ne parle que de nostalgie et d’esthétique
    Le fait que ce soit écrit par un humain et non par un LLM est encore plus déprimant
• Quand j’évalue un langage que j’aime, mon critère n’est pas « est-ce que j’aime écrire du code avec ? »
  mais « est-ce que je souhaite qu’un système en production soit écrit dans ce langage ? »
  Peu de gens donnent la même réponse aux deux questions
  • Écrire du code et faire tourner une activité sont deux problèmes distincts
    J’aime Ocaml, mais je n’ai pas envie de l’utiliser pour des systèmes en production, car l’écosystème est faible et il est difficile d’y recruter
  • Cela dépend de l’époque du langage et de la culture de code de l’équipe
    Un Python avec annotations de type et outils de vérification est agréable à maintenir, mais sans cela une culture de la documentation devient indispensable
  • La réponse change selon qu’on veut simplement maintenir le système ou continuer à le faire évoluer
    Dans le premier cas, COBOL peut convenir ; dans le second, d’autres choix deviennent intéressants
  • Si c’est un système que j’ai moi-même construit, n’importe quel langage me va ; sinon, je préfère le transmettre à quelqu’un d’autre
  • J’aime coder en Forth, mais je n’ai pas envie d’en faire mon métier
• J’aime vraiment Ruby
  Pas pour des raisons émotionnelles, mais simplement parce que c’est très agréable à écrire — bien plus que JavaScript, notamment
  Les textes qui attaquent Ruby me paraissent étranges
  Il existe des réussites comme Github, Twitter, Coinbase ou Shopify, et les problèmes de scalabilité ne sont qu’un sous-produit du succès
  Ruby est un excellent outil, et je recommande de juger par soi-même s’il convient au prochain projet
• L’article original comme sa réfutation restent flous dans leurs définitions
  Si l’affirmation est « Ruby ne passe jamais à l’échelle à long terme », alors cela vaut aussi pour la plupart des langages
  Au fond, les deux textes s’accordent sur le fait que « Ruby ne fonctionne jamais éternellement »
  Ce qui est intéressant, c’est que l’article original rabaissait Ruby en citant sa 18e place sur StackOverflow,
  alors qu’en réalité il était 14e en 2024, tandis que Scala, que l’auteur encensait, se trouvait 9 places plus bas
  Lien vers l’enquête StackOverflow 2024
  • Je ne suis pas d’accord avec l’idée que « Ruby ne fonctionne jamais éternellement »
    Du code Ruby que j’ai écrit il y a 10 ans, par exemple le compilateur offlineasm de WebKit, fonctionne encore très bien aujourd’hui
  • Se moquer de Java tout en encensant Scala est aussi assez drôle — la plupart des points forts de Scala viennent justement de Java
• Beaucoup de gens décrivent Ruby comme un « langage pour les humains », mais en réalité tous les langages sont conçus pour les humains
  Ruby a une syntaxe propre et expressive, mais il peut paraître difficile à utiliser à cause du typage dynamique et de la magie (comportements implicites)
  Ce n’est pas un langage pour moi, mais il convient parfaitement à certaines personnes
  • Rails a popularisé l’idée des « objets magiques »
    Les fans trouvent cela incroyable et plaisant, mais pour d’autres c’est presque inquiétant
    Flask, en Python, utilise lui aussi des context local proxy
    À l’inverse, Zig et Go sont apparus comme une réaction du type « tout doit être explicite », tandis que Rust se situe quelque part entre les deux
    Rust est strict, mais offre proprement une expressivité proche d’un DSL
• Il y a 10 ans, je suis passé de Ruby à Elixir
  Les performances algorithmiques ont été multipliées par 10, il y a eu moins de bugs grâce à l’immutabilité, et le support de la concurrence était excellent
  Le pattern matching et les guards ont supprimé beaucoup de boilerplate, il n’y a pas de GIL et le GC fonctionne par processus
  La courbe d’apprentissage existe un peu, mais Elixir passe bien mieux à l’échelle sur le long terme, en maintenance comme sous charge
  La communauté Ruby reste excellente
  J’aimerais simplement qu’Elixir puisse être compilé en exécutable natif ou tourner dans le navigateur
  • J’ai eu une expérience similaire
    Je continue à « penser en Ruby », mais mes projets personnels sont en Elixir/Erlang
    Au travail, j’utilise Golang et Python, mais sans y prendre plaisir
    Mes scripts personnels, en revanche, sont toujours écrits en Ruby
• Ce texte donne l’impression que quelqu’un est en train de défendre son langage
  Je trouve plus utile d’avoir des discussions qui analysent froidement l’impact des propriétés d’un langage sur la qualité du code, plutôt que sa popularité ou le simple fait d’y être habitué
  Ce type de débat rebute souvent les gens à cause de notions comme les monades ou les applicatives, mais c’est là que se trouvent les discussions vraiment utiles
  • La qualité du code, la productivité et la stabilité sont difficiles à mesurer objectivement, donc on finit souvent par revenir à des différences d’expérience
  • Il n’y a pas que la qualité du code : la simplicité, la lisibilité et la vitesse d’expression comptent aussi
    Plus il y a de types et de contraintes, plus la qualité monte, mais plus la vitesse de développement et la flexibilité baissent
  • Si ce sujet vous intéresse, un livre comme Eloquent Ruby peut valoir le détour
  • J’aimerais vraiment lire un article ou un papier qui analyse quelles fonctionnalités de langage sont favorables à la construction de systèmes à grande échelle
• Je ne suis pas fan de Ruby, mais l’article original de Wired était un pur contenu d’indignation conçu pour générer des clics
  Ce genre de texte est une sorte de toxine qui déclenche des guerres de langages sur HN
  Pas la peine de le prendre au sérieux
• J’aimais Ruby pour son expressivité, son orientation objet totale et sa syntaxe facile à lire
  Mais aujourd’hui, Kotlin me convient mieux — grâce au typage statique et à l’ergonomie de sa syntaxe
  Ruby devient inquiétant à mesure que le projet grandit, mais reste un langage charmant pour les petits travaux
  • Autrefois, j’ai vu un incident où de mauvaises variables liées à la session en Ruby ont mélangé des comptes utilisateurs
    Ce n’était peut-être pas la faute du langage, mais les langages avec peu de garde-fous ont tendance à attirer du code plus risqué
  • On dit que Ruby est entièrement orienté objet, mais si on exécute par exemple if.class, ce n’est pas totalement vrai
    Cela dit, parmi les langages grand public, c’est probablement celui qui s’en rapproche le plus