– Soutenir un langage de programmation chez Meta est une décision très prudente et délibérée.
– Nous partageons nos conseils internes sur le langage de programmation qui aident nos ingénieurs et développeurs à choisir le meilleur langage pour leurs projets.
– Rust est le dernier ajout à la liste des langages côté serveur pris en charge par Meta.
Chez Meta, nous utilisons de nombreux langages de programmation différents pour une grande variété de plates-formes et de cas d’utilisation. Soutenir une nouvelle langue n’est pas une décision que nous prenons à la légère. Il est important que chaque langage que nous adoptons soit le mieux adapté à un cas d’utilisation particulier, nous faisons donc preuve d’une grande diligence chaque fois que nous évaluons un langage. Les décisions linguistiques ont tendance à rester une fois prises, nous voulons donc être délibérés dès le départ pour donner à nos ingénieurs les meilleurs outils avec lesquels travailler.
Aujourd’hui, nous partageons des informations sur nos conseils internes sur les différents langages qui jouent un rôle important chez Meta – et en particulier nos langages de programmation côté serveur, dont Rust est le dernier ajout.
Qu’est-ce qu’une langue prise en charge par Meta ?
Avant d’entrer dans les détails individuels, voici ce que prise en charge signifie (et ne signifie pas) dans Meta :
- Si une langue est prise en charge, les développeurs peuvent compter sur une bonne expérience de l’édition de code, du débogage, de la construction et du déploiement, ainsi que des bibliothèques principales et de l’interopérabilité. Les développeurs peuvent également compter sur cette expérience pour ne pas disparaître – ils ne seront pas invités à quitter une langue prise en charge. Dans la plupart des cas, Meta recommande de choisir une langue prise en charge pour les nouveaux projets et services.
- La prise en charge complète d’un langage est un investissement majeur pour Meta, donc les langages “à longue traîne” sont soutenu par la communauté. Pour ces langages, il y a beaucoup moins de garanties, et les équipes qui les adopteront devront assumer le fardeau de la maintenance. Dans la plupart des cas, les équipes doivent éviter de les utiliser pour de nouvelles applications, à moins qu’une équipe ait déjà un investissement important dans le langage.
Les principaux langages côté serveur pris en charge par Meta sont Hack, C++, Rust et Python.
- Pour les services back-end sensibles aux performances, nous encourageons C++ et Rust. Rust est un nouvel ajout à cette liste. Il y a une empreinte Rust en augmentation rapide dans nos produits et services, et nous nous engageons à Rust à long terme et accueillons les premiers utilisateurs.
- Pour Outils CLI, nous recommandons Rust. C’est une nouvelle recommandation pour cette année.
- Pour la logique métier et les applications relativement sans état, l’écosystème Hack a le plus haut niveau d’automatisation et de support chez Meta et est le langage recommandé.
- Enfin, Meta continue de soutenir fortement nos développeurs Python. Pour la science des données, les applications ML et Instagram, Python continue d’être le langage de choix, et nous continuons d’investir dans l’expérience avec cet écosystème.
- Pour des cas d’utilisation spécifiques, nous prenons en charge d’autres langages, notamment Java, Erlang, Haskell et Go. Ces langages ne sont actuellement pas largement pris en charge en dehors de cas d’utilisation spécifiques.
Comment sommes-nous arrivés à notre liste de langues prises en charge ?
Expliquons pourquoi nous avons une liste de langues prises en charge et pourquoi nous sommes généralement réticents à ajouter des langues à cette liste (bien que Rust soit un nouvel ajout). La raison principale est qu’il faut un investissement technique important pour prendre en charge un langage de programmation à l’échelle Meta, et que ce coût est largement réparti – pas seulement supporté par ses utilisateurs. Quelques exemples:
- Prise en charge des bibliothèques principales. Il y a très peu de services isolés, et moins nous avons de langues, moins il y a de charge sur les bibliothèques principales.
- Sécurité et confidentialité. Une pile fragmentée augmente la complexité de la construction d’importantes fonctionnalités de sécurité et de confidentialité dans nos services.
- Risque opérationnel. Si un service rencontre un problème critique, il nécessitera une assistance immédiate. Nous avons accumulé une expertise incroyable dans le diagnostic et la résolution des problèmes de production, et notre réponse aux incidents repose sur notre capacité à lire, comprendre et déboguer les services pour aider en cas d’incident majeur. Éviter la fragmentation réduit le risque opérationnel.
- Compétence. Nous construisons et maintenons une masse critique d’ingénieurs ayant une expertise dans chacune de ces langues.
- expérience de développeur. Les langues prises en charge ont des équipes qui travaillent à l’amélioration de domaines tels que la prise en charge de l’IDE, la vitesse de construction, l’expérience de débogage, etc.
Choisir un langage sous-optimal pour un projet peut être coûteux en termes de temps, d’efficacité et de productivité. Il vaut donc la peine de soumettre chaque langue que nous évaluons à un examen minutieux. Les exemples ci-dessus montrent à quel point nous investissons dans la prise en charge d’une langue.
Rust est le dernier langage côté serveur de Meta
Depuis que nous a commencé notre voyage avec Rust, le nombre de projets utilisant Rust dans Meta a augmenté à un rythme accéléré. Nous sommes ravis de voir Rust ajouté à cette liste de langages pris en charge côté serveur, nos ingénieurs offrant plus d’outils, de flexibilité et de support pour leur travail. Meta s’engage à fournir un support à long terme pour les langages de programmation utilisés par notre développeur, et cette décision signale l’engagement et le support à long terme de Meta pour l’écosystème du langage Rust.