🍪🦄 Pourquoi autant de licornes françaises sont codées en Ruby ?
Temps de lecture : 5 minutes
Hello les petits Biscuits !
Bienvenue sur la 25ème édition de Ruby Biscuit.
Vous êtes maintenant 501 abonnés 🥳
Maintenant Ruby biscuit, c’est aussi votre meilleur allié pour recruter des devs Ruby !
Si vous n’avez pas encore rejoint le club, RDV sur https://recrutement.rubybiscuit.fr
Bonne lecture.
Pourquoi autant de licornes françaises sont codées en Ruby ?
Il est de notoriété publique que le Ruby on Rails est utilisé par de merveilleuses entreprises à travers notre merveilleuse planète. On pense évidemment à Github, Shopify, Twitch, Airbnb, Coinbase, ...
En France aussi le RoR est très utilisé dans les startups mais un constat est particulièrement frappant : la présence du Ruby on Rails dans les licornes* du web français.
*Licorne : entreprise dont la valorisation dépasse 1 milliard de dollars.
Parmi les licornes françaises plusieurs (et parmi les plus importantes) sont codées en RoR : Doctolib, Pennylane, Sorare, Qonto, Aircall et Swile.
Comment expliquer cette insolente réussite du RoR alors que les Cassandre du javascript annoncent sa fin chaque année ? ^^
Tout d'abord il ne s'agit pas d'une hype momentanée de ce brillant langage (jeu de mot avec le Ruby qui brille ;)), car ces entreprises n'ont pas été créées au même moment. Voici leurs dates de création :
Doctolib : 2013
Aircall : 2014
Qonto : 2016
Sorare et Swile : 2018
Pennylane : 2020
Alors vous me direz :
Oui mais aucune n'a été créée tout récemment !
Et je vous répondrai que vous avez raison, mais comme aurait pu le dire Simone de Beauvoir :
On ne naît pas Licorne, on le devient.
Par exemple Doctolib a vu sa corne pousser en 2019, suite à sa levée de 150M€, soit 6 ans après sa création.
Ainsi je ne doute pas que, dans quelques années, il y aura de belles entreprises RoR créées autour de l'année 2024.
Mais alors pourquoi autant de licornes françaises sont codées en Ruby on Rails ?Sans parler de toutes les boites à succès qui ne sont pas des licornes
D'après ce John Rogue, sur Quora, Doctolib a choisi le Ruby par hasard, parce que c'était un langage à la mode à cette époque (utilisant au passage une belle locution latine rappelant que "le hasard façonne le monde").
C'est un peu court comme explication, mais ce n'est pas complètement faux.
Oui il est crucial, si l'on veut développer une technologie ambitieuse, d'utiliser une technologie populaire. Une licorne a besoin de beaucoup de développeurs pour (se) développer et le choix ne peut pas être que sur les capacités techniques d'une techno.
Autrement dit, si le langage A est 5% plus performant pour le besoin que le langage B, mais qu'il y a 2 fois plus de développeurs du langage B, alors ce dernier paraît bien plus adapté.
Ruby on Rails = Vélocité
Développer une startup qui va cartonner c'est hyper complexe. Il y a beaucoup d'appelés et peu d'élus. Une fois que l'on a trouvé un product market fit (une fois que son produit rencontre la demande), on se rend compte que des dizaines d'entreprises sont sur le même créneau en train de cravacher pour être la meilleure. Et dans ce cas il faut être hyper rapide.
Cela tombe bien c'est un des gros avantages du RoR.
Comparons la vélocité du RoR versus Django (Python) et Express.js (Node.js), ses principaux rivaux ⚔️ On pourrait aussi choisir Laravel ou Symphony qui sont des frameworks populaires de PHP, mais à ma connaissance, ces options reviennent moins souvent, en ce moment, quand il faut construire une plateforme web complexe.
Voici les points de comparaison que je retiens :
Philosophie et Structure
Outils et Scaffolding
Écosystème et Packages
Courbe d'apprentissage
1- Philosophie et Structure
Ruby on Rails : Suivant la philosophie "Convention over Configuration", le RoR impose des conventions strictes qui permettent de démarrer rapidement un projet sans avoir à prendre de nombreuses décisions de configuration ⟶ Gain de temps assuré. Surtout si vous avez des dévs qui aiment débattre 😬
Django : privilégie une approche "Explicit is Better Than Implicit", où chaque élément doit être défini clairement. Cette approche apporte de la clarté et une structure robuste, mais nécessite plus de configuration initiale.
Express.js : Node.js offre une grande flexibilité et liberté de structuration. Avec Express.js, un cadre minimaliste, les développeurs ont plus de liberté pour organiser le projet comme ils le souhaitent. Cependant, cette flexibilité peut entraîner un temps de configuration plus long comparé au RoR et Django.
Synthèse :
🐇🐇🐇 RoR
🐇🐇 Django
🐇 Express.js
“Vous n’êtes pas un flocon de neige magnifique et unique”
Voici ce qu'on peut lire sur le site de Rails concernant la Convention :
L’un des premiers slogans de Rails était : “Vous n’êtes pas un flocon de neige magnifique et unique”. La devise dit qu’en abandonnant l’individualité, il est possible d’éviter de résoudre des problèmes triviaux et d’avancer plus rapidement dans les domaines qui sont vraiment importants.
Qui se soucie du format dans lequel vos clés primaires sont décrites dans la base de données ? Est-ce vraiment important si c’est “id”, “postId”, “posts_id” ou “pid” ? Cette solution mérite-t-elle une discussion constante ? Non
2- Outils et Scaffolding
Ruby on Rails : dispose d'outils de scaffolding puissants qui permettent de générer rapidement des modèles, des vues, et des contrôleurs. Cela accélère significativement la mise en place des fonctionnalités de base d'une application.
Django : propose également des outils de scaffolding, mais ils sont moins intégrés et complets que ceux de RoR. Le développement initial peut donc être plus lent en comparaison.
Express.js : offre des générateurs de code, mais ceux-ci sont généralement moins robustes et moins intégrés que ceux de RoR et Django. Les développeurs doivent souvent configurer manuellement davantage d'éléments.
Synthèse :
🐇🐇🐇 RoR
🐇🐇 Django
🐇 Express.js
Exemple de scaffolding avec RoR : la génération d'une ressource complète (Modèle, Contrôleur, Vues, Routes)
Supposons que vous souhaitiez créer une application qui gère des articles de blog. Avec Rails, vous pouvez générer un modèle, un contrôleur, et les vues associées en une seule commande :
rails generate scaffold Article title:string content:text published:booleanCe que cette commande fait :
Modèle (
Article) : Crée un modèleArticleavec les attributstitle(chaîne de caractères),content(texte), etpublished(booléen).Contrôleur (
ArticlesController) : Crée un contrôleurArticlesControlleravec les actions standard CRUD (Create, Read, Update, Delete) :index,show,new,edit,create,update,destroy.Vues : Génère les vues associées à chaque action du contrôleur (
index.html.erb,show.html.erb,new.html.erb,edit.html.erb, etc.).Routes : Ajoute automatiquement les routes RESTful associées dans le fichier
config/routes.rb, comme/articles,/articles/:id,/articles/new, etc.Migration : Crée une migration pour créer la table
articlesdans la base de données avec les colonnestitle,content, etpublished.
3- Écosystème et Packages
Ruby on Rails : dispose d'un écosystème mature avec de nombreuses gemmes bien maintenues, permettant d'ajouter rapidement des fonctionnalités. L'intégration des gemmes est généralement fluide, ce qui accélère le développement. Et beaucoup de développeurs, notamment en France, choisissent cette techno pour sa communauté active et bienveillante.
Django : bénéficie également d'un écosystème riche de packages, avec un fort accent sur les meilleures pratiques de sécurité et de structure. Les packages sont bien intégrés et maintenus, mais l'écosystème est légèrement moins vaste que celui d'Express.js.
Express.js : via npm, possède le plus grand écosystème de packages, offrant une flexibilité immense. Cependant, cette richesse peut parfois entraîner des problèmes de compatibilité ou de maintenance, nécessitant un temps supplémentaire pour la sélection et l'intégration des packages.
🐇 🐇Express.js
🐇🐇 RoR
🐇 Django
La puissance du Wagon
Dans le contexte français, un autre élément à prendre en compte est l'existence du bootcamp Le Wagon. Chaque mois ce sont plus de cent personnes qui sont diplômées en développement web en Ruby on Rails, puisque le Wagon forme au web à travers ce framework.
Evidemment, nombreux sont les alumni qui ne finissent pas développeurs mais ces personnes ont aussi un impact puisqu'un fondateur d'entreprise préfère que son CTO utilise une technologie qu'il comprend plutôt qu'une autre. En tant que dirigeant d'une agence travaillant en Ruby on Rails, j'ai eu plusieurs clients qui préféraient travailler en RoR simplement du fait qu'ils aient fait le Wagon.
Bien-sûr les projets ambitieux ont surtout besoin de développeurs expérimentés et l'on ne devient pas développeur en 9 semaines. Mais Le Wagon est une école formidable, qui donne le goût du développement et qui a formé des juniors qui sont désormais des séniors, je le vois au quotidien chez Capsens.
4- Courbe d'apprentissage
Ruby on Rails (RoR) : RoR est souvent considéré comme ayant une courbe d'apprentissage douce, grâce à sa documentation complète et à ses conventions strictes et claires. Cela permet aux développeurs de devenir rapidement productifs. Cela explique notamment pourquoi le Wagon a choisi d'enseigner le web à travers le Rails
Django : Django offre une excellente documentation et une communauté active, ce qui en fait un framework accessible. Sa philosophie "Explicit is Better Than Implicit" aide à comprendre clairement ce qui se passe dans le code, mais cela peut nécessiter un peu plus de temps pour maîtriser certains concepts.
Node.js (avec Express.js) : Node.js nécessite une bonne compréhension de JavaScript, notamment des concepts asynchrones comme les callbacks, les promesses, et async/await. La flexibilité et l'asynchronisme de Node.js peuvent ralentir la productivité initiale, surtout pour les développeurs moins expérimentés.
Ce qui est fort avec le Ruby on Rails, c'est que l'on peut recruter d'excellents développeurs dans d'autres technologies et les former rapidement à sa stack.
🐇🐇🐇 RoR
🐇🐇🐇 Django
🐇 Express.js
RoR n'est pas seul
Evidemment, pour un projet web complexe qui scale, le Ruby est souvent couplé d'autres technologies. En terme de back Qonto a développé le coeur de son système bancaire en Go, tandis que les fonctionnalités utilisateurs sont en RoR. Idem pour Sorare qui couple le Ruby on Rails au Go.
Chez Doctolib le Ruby on Rails est vraiment roi. Couplé en front au React (avec React Native pour le mobile). Ce duo de choc on le retrouve dans beaucoup d'apps importantes (parce qu'on peut dire que React a vraiment pris une longueur d'avance en terme de front en France). Il est drôle de voir que notre stack chez Capsens est identique à celle-ci : RoR + React + Kubernetes/Docker + AWS
D'ailleurs pour la science voici les langages backend que j'ai recensé chez les principales licornes françaises du web :
C# / .NET : Pigment
Java : Dataiku, Mirakl,
Très diversifié (Plusieurs parmi Symphony + Scala + Node + Go + Python + Java) : Contentsquare, ManoMano, Blablacar, Vestiaire Collective, Deezer
Go : Lydia
Python (Flask) : Alan
Python (Django) + Scala : BackMarket
Scaler avec Ruby
Le témoignage de Pennylane
Le RoR c'est bien pour démarrer vite mais ça ne scale pas
Cette réplique on l'a beaucoup entendue il y a plusieurs années. Depuis Ruby n'a eu de cesse d'innover particulièrement pour mieux gérer le scaling.
Dans cet article https://medium.com/pennylane-engineering/scaling-our-ruby-on-rails-monolith-using-packwerk-part-1-b787aaa218ff, Alexandre Ruban, ex-Pennylane, explique le scaling avec Ruby chez Pennylane.
Tout d'abord il pose les bases :
Pennylane a mis en place une équipe de 120 dév Ruby en 3 ans 😮
400 commits, soit 45 000 nouvelles lignes par semaine 🤯
Ils ont donc connu un problème de scaling avec une base de code trop grosse et monolithique 🤷
Il explique que la principale solution a été de diviser l'app en services afin qu'elle soit plus compréhensible par les développeurs. De plus Pennylane a utilisé un outil, Packwerk, mis en ligne par Shopify qui les a aidé à rendre leur app plus modulaire (vive la communauté RoR !).
Et voilà !
Concrètement ce n'est pas si simple, mais ce n'est jamais simple de scaler une app complexe, quelque soit le langage.
Ruby on Rails s'est réinventé pour scaler
Ruby et Ruby on Rails ont été améliorés pour répondre aux besoins de scalabilité et de performance. Voici les principales améliorations de ces dernières années :
Ruby a introduit la compilation JIT (Just in time) dans sa version 2.6 (2019), et optimisé son gestionnaire de mémoire pour améliorer la réactivité.
Rails a ajouté un mode API plus léger, optimisé les requêtes de base de données, et adopté des pratiques de modularisation comme les microservices.
Rails a également renforcé son écosystème avec des outils comme Active Job pour le traitement en arrière-plan
Il existe de nombreuses comparaisons des performances de Ruby par rapport à d'autres langages. Les conclusions sont souvent que Ruby est à peu près aussi performant que ses concurrents mais que pour faire de la performance pure il ne faut pas s'orienter vers des technologies web de type Rails/Node/Django mais vers du Go ou du Scala. Ce qui explique pourquoi beaucoup d’entreprises qui scalent combinent plusieurs langages.
En conclusion
Je ne vous cache pas mon bonheur de voir que le Ruby on Rails soit autant représenté dans de belles et grandes entreprises françaises où le développement est central, mais cela ne m'étonne pas. Le Ruby on Rails permet d'aller vite, a des conventions strictes qui évitent de se prendre la tête pour rien, et une communauté incroyable. Cette techno a tout pour plaire et a l’avenir devant elle.
A partir du moment où d'aussi grandes entreprises font du Ruby, cela crée un effet boule de neige car elles recrutent et forment en Ruby, ce qui pousse plus de développeurs à se former à cette techno et la communauté s’étoffe encore.
Ce qui est paradoxal, c'est que le Ruby on Rails est aussi (et surtout) un excellent framework pour bootstrapper (= démarrer sans avoir beaucoup de moyens financiers) un projet et pour des entreprises petites ou moyennes. Car la plupart des projets n'auront jamais à scaler au point de devenir des licornes. Mais on est jamais à l'abri d'un succès fulgurant 🚀
N’hésitez pas à réagir à cet article en réponse à ce mail ou dans les commentaires ;)
Vive le Ruby ❤️
— Nicolas
Super article, comme d'habitude !