GitLab, le gestionnaire de référentiels Git basé sur le Web et développé par GitLab Inc. a été développé en Ruby on Rails (RoR), un framework web libre écrit en Ruby qui suit le motif de conception modèle-vue-contrôleur (MVC). Les co-fondateurs du projet nous donnent ici les raisons de ce choix. Lorsque Dmitriy Zaporozhets, cofondateur et membre de l'ingénierie, a décidé de construire GitLab, il a choisi de le faire avec Ruby on Rails, bien qu'il travaillait principalement en PHP à cette époque....

L'interview est très drôle aussitôt que l'on n'oublie pas son esprit critique. Je m'explique, le fondateur de Gitlab nous apprend que lui et son associé ont pris Ruby comme langage (alors que lui venait du PHP) et Rails comme framework (parce que ce dernier est très mature, super stable, documenté, toussa). Bref, le mec vante les mérites incroyables de RoR (Ruby On Rails) et des Gems Ruby, en clair que cette stack est juste incroyable...

Sauf qu'il explique après qu'ils ont du recoder une partie du kernel de Gitlab en Go (et aussi en C, de ce que j'ai pu constaté dans le code) car Ruby bah ça rame... La GUI a été recodée en Vue.js à la place de Rail, car RoR n'est pas assez "réactif" et ça rame et d'autres technos encore (NodeJS / Mongo / PHP / Redis lorsque l'on ouvre le capot). D'ailleurs et d'expérience, Gitlab est une des pires technos que je connaisse du point de vue OPS car elle contient bien trop de choses à installer, trop de systèmes de caches à configurer, trop d'utilisateurs Unix à créer, trop de permissions à affecter, etc.

Bon, le gars justifie le fait que ses choix technologiques étaient les meilleurs mais qu'ils ont du tout recoder quand même car RoR n'était pas adapté... Hum hum best choice ever donc pas vrai ? (눈_눈) #Bullshit

Si ce choix avait été le meilleur, rien n'aurait dû être recodé. RoR n'était tout simplement pas le meilleur choix. RoR est très bien pour les petites applications et les prototypes mais ne tient pas la charge. D'ailleurs l'implémentation JRuby (qui tourne sous Java) est plus rapide à l'exécution que l'implémentation d'origine !!! Le créateur de Ruby est bon pour créer un langage mais pas bon pour coder. Et encore, ne pas avoir du multi-thread natif et facile à utiliser en 2019 (typiquement les coroutines de Kotlin ou les async / await de TypeScript) ce devrait être considéré comme trèèèèèès embarrassant.

Pourquoi ce post alors ?

Parce qu'il dégouline de bullshit. Les mecs de Gitlab ont du recoder leur application mais il faut rassurer leurs investisseurs. Ils ont fait des choix discutables en mixant 5 ou 6 langages de programmation au sein du même outil (de ce que j'ai constaté Go, Ruby, C, PHP, JavaScript, SQL et NoSQL - et encore je m'étais arrêté là en 2018 d'où notre choix de Gitea qui avait le mérite d'être consistant même si moins fonctionnel déjà à cette époque).

Et en lisant l'interview, toute la novlangue du type est déployée pour réécrire une histoire technique désastreuse d'un projet commercialement fabuleux. Voilà pourquoi j'écris ce post, pour dénoncer cette réécriture "de vainqueur" qui devrait vous faire réfléchir à deux fois à la direction que prend Gitlab. #TraduisonsLes