Ruby est rapidement devenu un langage incontournable. Considéré comme élégant, il propose une approche pragmatique pour les développeurs en visant à leur faire gagner un temps précieux en ne négligeant pas la concision et la maintenabilité. Standardisé en 2011/2012, il a depuis été popularisé sur le web notamment grâce au framework Rails, il est utilisé au coeur des infrastructures de géants du Net.
La version 3 de Ruby arrivant à grands pas, elle est prévue pour Noël 2020, nous allons donc revenir un peu sur les (r)évolutions qu'il faut en attendre
Annoncé comme 3 fois plus performant (d'où son petit nom de Ruby 3x3) que la version 2, un gros travail a été porté sur le ramasse-miettes, pour une meilleure gestion de la mémoire. Toujours concernant les performances, un effort a été porté sur le compilateur JIT, mais à ce jour nous ne savons toujours pas quelle piste sera suivie. Nous garderons un oeil attentif sur MJIT qui a déjà fait son apparition sur Ruby 2.6 et qui utilise un compilateur écrit en C.
Ruby a des soucis avec les threads et son Global Interpreter Lock (GIL), le multithreading reste peu efficient pour utiliser de multiples CPUs et le problème n'est pas récent . Pour palier ce souci, on se dirige vers des greens threads, et non vers de l'async IO jugé trop compliqué à appréhender bien que Python 3 ait choisi cette approche. La bibliothèque Ruby de programmation événementielle Event Machine n'a de son côté jamais atteint le status de standard.
Ruby 3x3 devrait également être marqué par le passage à des guildes visant à isoler des processus en userland. L'idée est ici de pouvoir bénéficier de plusieurs GIL qui auront des threads (systèmes) pouvant partager un état.
Outre l'énorme travail porté sur les performances, l'autre challenge qui se dessine porte sur l'analyse statique du code. L'objectif étant d'éviter au maximum l'écriture de tests.
Comme Matz déteste les annotations, il veut utiliser un second fichier (en .rbi) pour annoter le code, une approche assez singulière pour ne pas dire farfelue (de mauvaises langues y verront un traumatisme hérité de Perl).
Eclipse a lui aussi traumatisé des générations de developpeurs, mais depuis Atom et VSCode, les IDE légers (plus légers que Java, c'est à dire tous les autres) reviennent en force, et le confort de l'analyse statique est sans équivalent. Brakeman est déjà un effet palpable.
Plus rapide et doté de fonctionnalités d'analyse de code à la volée, voici ce que nous sommes en mesure à ce jour d'attendre de Ruby 3x3, c'est certes pour l'instant encore assez mystérieux mais nous devrions voir arriver d'autres informations ces prochaines semaines.
Le bémol dans tout ça, c'est que les transitions sont toujours un peu douloureuses. Si Python annonce la fin du support de Python 2 (et donc la branche 2.7 la plus répandue) pour 2020, l'écosystème permettant une migration vers Python 3 est mature, après 10 années, ce ne serait pas un troll que de dire que c'est au minimum ce qu'on en attend. Nul doute que pour Ruby la transition se fera sans casse, et probablement un peu plus rapidement que pour Python (l'effort sur les performances a ce côté sexy qui motivera la migration). Mais en attendant, nous risquons d'avoir à passer par cette période que personne n'aime par principe, celle de voir cohabiter sur ses machines plusieurs versions de Ruby, et donc d'avoir à maintenir des applications dans des environnements très hétérogènes.
Ressources :
https://developers.redhat.com/blog/2018/03/22/ruby-3x3-performance-goal/ https://developer.squareup.com/blog/rubykaigi-and-the-path-to-ruby-3/ http://stereobooster.github.io/ruby-3
RubyConf 2017 :
Opening Keynote - Good Change, Bad Change by Yukihiro Matsumoto What If... ?: Ruby 3 by Eric Weinstein Git Driven Refactoring by Ashley Ellis Pierce LLVM-based JIT compiler for MRI byTakashi Kokubun What does GIL really guarantee you? by Daniel Vartanov That time I used Ruby to crack my Reddit password by Haseeb Qureshi
