Il est intéressant de noter que javascript/node ne fait pas partie de la liste, malgré le succès et la visibilité de cette pile technique chez d'autres éditeurs et auprès des jeunes développeurs notamment.
Je suppose que ça reflète plus la capacité de support par les salariés des équipes dédiés (eg, si y a un souci de perf sur le compilo/interpréteur), et donc les gens en place ainsi que l'historique de la base de code qu'autre chose.
C'est pour ça que ça me fait rire de voir ce genre de liste vu que ça ne va rien apporter de spécial pour la majorité des gens, à part des arguments d'autorité foireux comme "si une boite qui est assis sur une pompe à fric l'utilise, alors ça doit être adapté à ce que je veux faire".
Posté par Papey .
Évalué à 3.
Dernière modification le 07 août 2022 à 09:06.
javascript est déjà utilisé côté client de manière intensive avec des bibliothèques majeures comme react qui viennent de chez facebook donc je ne pense pas que les compétences manquent côté langage. De même la base de code existante doit être conséquente, même si tout n'est pas réutilisable côté serveur.
Je n'ai pas du être clair quand j'ai dit "compilo/interpreteur", je parle des équipes qui vont maintenir le dit compilo/interpréteur.
Coté client, si tu perds des ressources (que ça soit cpu ou ram), tu t'en fout, c'est pas toi qui paye. Coté serveur, si tu perds des ressources, tu payes vu que c'est tes serveurs, et à l'échelle de facebook, ça fait beaucoup.
De plus, si tu as un souci coté navigateur, tu n'a pas toujours le contrôle pour corriger. Coté serveur, tu n'as aucune excuse vu que tu as choisi la pile logiciel.
Je serais assez étonné qu'ils n'aient pas des gens qui connaissent très bien les interpréteurs des navigateurs et c'est le même qui est utilisé côté serveur. Parce que perdre de la RAM, ça peut aller côté client (dans une certaine mesure, parce que ça veut dire quand même que certaines personne ne pourront pas accéder au site), mais perdre du CPU, ça veut dire que le temps d'affichage va augmenter.
Par contre, si on regarde l'article, c'est un peu plus complexe que 4 langages supportés. C'est rust et c++ pour les perfs, rust pour la cli, hack pour la business logic (parce qu'il y a déjà énormément d'existant) et python pour data science/ML (et instagram). Donc, ce n'est pas simplement "voici les 4 langages supportés, choisissez comme vous voulez", c'est prenez un langage en fonction du cas d'utilisation. Et du coup, ça me semble assez logique que javascript ne rentre dans aucune case.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
Je serais assez étonné qu'ils n'aient pas des gens qui
connaissent très bien les interpréteurs des navigateurs et
c'est le même qui est utilisé côté serveur.
Bah, y a du monde chez facebook, mais ça veut pas dire forcément qu'ils vont couvrir tout. Entre dédié des devs sur le support d'un langage, ou les mettre sur des produits qui rapportent des thunes, le choix est vite fait.
Parce que perdre de la RAM, ça peut aller côté client (dans une
certaine mesure, parce que ça veut dire quand même que
certaines personne ne pourront pas accéder au site), mais
perdre du CPU, ça veut dire que le temps d'affichage va
augmenter.
Je parle plus des perfs à l’échelle de Facebook. Si tu perds 100ko de ram par client coté client, c'est invisible pour le client. Si tu perds 100ko par client coté serveur, ça va se voir plus, vu que ça s'accumule.
Si chaque client prends 10% de CPU en plus coté client, ç'est pas super, mais suivant le niveau de base, ça peut aller, surtout que le terminal client, il fait pas que ça, ni en permanence.
Personne ne cherche vraiment à maximiser l'usage du temps CPU sur les clients, donc il y a grosso modo des trucs en trop. C'est bien d'optimiser bien sur.
Si toute ta flotte prends 10% de CPU en plus, alors ça a un impact, car toi, en tant que fournisseur (à l’échelle de FB), tu n'as pas forcément du temps CPU qui traîne, car le but est d'utiliser le matos au maximum.
Je sais que Google a (ou avait) un outil interne pour savoir si c'est intéressant d'optimiser ou pas un service, car l'optimisation a un coût (salaire, etc), mais la non optimisation aussi (temps CPU, etc).
Et à coté de ça, ça impacte aussi l’écosystème. Tu veux rajouter un langage coté serveur, il faut rajouter et maintenir des libs pour la stack en question (j'imagine que Facebook a des libs pour les APIs internes). Il faut des gens qui connaissent les soucis de sécurité de la stack coté serveur pour examiner le code, faut que tes SRE puissent le lire et l'écrire. Il faut aussi maintenir la stack, donc embaucher du monde, etc.
Intuitivement, on se doute bien que supporter tout ce qui existe n'est pas faisable. On peut discuter de savoir si la limite devrait être 10, 50 ou 4, mais je pense que si Facebook a fait le choix de 4, ils ont sans doute plus de chiffres que nous.
Si chaque client prends 10% de CPU en plus coté client, ç'est pas super, mais suivant le niveau de base, ça peut aller, surtout que le terminal client, il fait pas que ça, ni en permanence.
Si c'était la seule base, je ne pense pas que Python serait autorisé dans les langages.
je pense que si Facebook a fait le choix de 4, ils ont sans doute plus de chiffres que nous.
Mais justement, ils n'ont pas fait le choix de 4. Ils ont fait le choix d'un langage par domaine (2 si on compte c++ et rust pour les perfs).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
Je suppose que comme Google en son temps (le projet Unladen Swallow), Meta/Instagram a son propre fork de Python.
C'est ce qu'ils ont fait pour PHP et ils avaient vachement communiqué dessus. J'ai pas retrouvé l'info, mais il me semble qu'ils utilisent pythran par exemple.
Oh c'est intéressant. Ils ont l'air de vouloir converger vers cpython sans pour autant être actif. Je sais pas comment ils vont gérer l'évolution de python. Pour le moment ils sont sur 3.8 et je n'ai pas vu quel était le plan : y rester, rappliquer leurs changements sur une version intéressante ou merger avec cpython.
Ce qui est intéressant, c'est qu'il y a sans doute plus de gens payé à temps plein sur le fork qu'upstream.
Et ils ne s'intéressent qu'à la performance et ont l'air de dire qu'ils ajoutent peut-être des bugs. Plus loin ils disent qu'ils redémarrent assez souvent leurs appli pour que les fuites mémoires ne soient pas un problème. Je sais pas s'ils parle du code instagram ou de cinder lui même.
Ça me donne un peu l'impression d'un besoin de vitesse très pressant et d'un projet assez précipité (on fait de la perf' pour nous, ce serait bien que ce soit mergé mais on le fera pas, on ne fera pas de support et attention on ne corrigera rien si on n'a pas le problème sur notre prod). C'est assez loin de dans la démarche de hhvm ou hack.
# On s'en tape de META
Posté par tout . Évalué à 4.
Je préfère Golang.
[^] # Re: On s'en tape de META
Posté par Papey . Évalué à 4. Dernière modification le 06 août 2022 à 17:45.
# pas de javascript donc
Posté par Papey . Évalué à 4.
Il est intéressant de noter que javascript/node ne fait pas partie de la liste, malgré le succès et la visibilité de cette pile technique chez d'autres éditeurs et auprès des jeunes développeurs notamment.
[^] # Re: pas de javascript donc
Posté par Misc (site web personnel) . Évalué à 7.
Je suppose que ça reflète plus la capacité de support par les salariés des équipes dédiés (eg, si y a un souci de perf sur le compilo/interpréteur), et donc les gens en place ainsi que l'historique de la base de code qu'autre chose.
C'est pour ça que ça me fait rire de voir ce genre de liste vu que ça ne va rien apporter de spécial pour la majorité des gens, à part des arguments d'autorité foireux comme "si une boite qui est assis sur une pompe à fric l'utilise, alors ça doit être adapté à ce que je veux faire".
[^] # Re: pas de javascript donc
Posté par Papey . Évalué à 3. Dernière modification le 07 août 2022 à 09:06.
javascript est déjà utilisé côté client de manière intensive avec des bibliothèques majeures comme react qui viennent de chez facebook donc je ne pense pas que les compétences manquent côté langage. De même la base de code existante doit être conséquente, même si tout n'est pas réutilisable côté serveur.
[^] # Re: pas de javascript donc
Posté par Misc (site web personnel) . Évalué à 6.
Je n'ai pas du être clair quand j'ai dit "compilo/interpreteur", je parle des équipes qui vont maintenir le dit compilo/interpréteur.
Coté client, si tu perds des ressources (que ça soit cpu ou ram), tu t'en fout, c'est pas toi qui paye. Coté serveur, si tu perds des ressources, tu payes vu que c'est tes serveurs, et à l'échelle de facebook, ça fait beaucoup.
De plus, si tu as un souci coté navigateur, tu n'a pas toujours le contrôle pour corriger. Coté serveur, tu n'as aucune excuse vu que tu as choisi la pile logiciel.
[^] # Re: pas de javascript donc
Posté par claudex . Évalué à 8.
Je serais assez étonné qu'ils n'aient pas des gens qui connaissent très bien les interpréteurs des navigateurs et c'est le même qui est utilisé côté serveur. Parce que perdre de la RAM, ça peut aller côté client (dans une certaine mesure, parce que ça veut dire quand même que certaines personne ne pourront pas accéder au site), mais perdre du CPU, ça veut dire que le temps d'affichage va augmenter.
Par contre, si on regarde l'article, c'est un peu plus complexe que 4 langages supportés. C'est rust et c++ pour les perfs, rust pour la cli, hack pour la business logic (parce qu'il y a déjà énormément d'existant) et python pour data science/ML (et instagram). Donc, ce n'est pas simplement "voici les 4 langages supportés, choisissez comme vous voulez", c'est prenez un langage en fonction du cas d'utilisation. Et du coup, ça me semble assez logique que javascript ne rentre dans aucune case.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: pas de javascript donc
Posté par Misc (site web personnel) . Évalué à 5.
Bah, y a du monde chez facebook, mais ça veut pas dire forcément qu'ils vont couvrir tout. Entre dédié des devs sur le support d'un langage, ou les mettre sur des produits qui rapportent des thunes, le choix est vite fait.
Je parle plus des perfs à l’échelle de Facebook. Si tu perds 100ko de ram par client coté client, c'est invisible pour le client. Si tu perds 100ko par client coté serveur, ça va se voir plus, vu que ça s'accumule.
Si chaque client prends 10% de CPU en plus coté client, ç'est pas super, mais suivant le niveau de base, ça peut aller, surtout que le terminal client, il fait pas que ça, ni en permanence.
Personne ne cherche vraiment à maximiser l'usage du temps CPU sur les clients, donc il y a grosso modo des trucs en trop. C'est bien d'optimiser bien sur.
Si toute ta flotte prends 10% de CPU en plus, alors ça a un impact, car toi, en tant que fournisseur (à l’échelle de FB), tu n'as pas forcément du temps CPU qui traîne, car le but est d'utiliser le matos au maximum.
Je sais que Google a (ou avait) un outil interne pour savoir si c'est intéressant d'optimiser ou pas un service, car l'optimisation a un coût (salaire, etc), mais la non optimisation aussi (temps CPU, etc).
Et à coté de ça, ça impacte aussi l’écosystème. Tu veux rajouter un langage coté serveur, il faut rajouter et maintenir des libs pour la stack en question (j'imagine que Facebook a des libs pour les APIs internes). Il faut des gens qui connaissent les soucis de sécurité de la stack coté serveur pour examiner le code, faut que tes SRE puissent le lire et l'écrire. Il faut aussi maintenir la stack, donc embaucher du monde, etc.
Intuitivement, on se doute bien que supporter tout ce qui existe n'est pas faisable. On peut discuter de savoir si la limite devrait être 10, 50 ou 4, mais je pense que si Facebook a fait le choix de 4, ils ont sans doute plus de chiffres que nous.
[^] # Re: pas de javascript donc
Posté par claudex . Évalué à 3.
Si c'était la seule base, je ne pense pas que Python serait autorisé dans les langages.
Mais justement, ils n'ont pas fait le choix de 4. Ils ont fait le choix d'un langage par domaine (2 si on compte c++ et rust pour les perfs).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: pas de javascript donc
Posté par Misc (site web personnel) . Évalué à 5.
Instagram est en Python si je me souviens bien:
https://pyvideo.org/pycon-us-2021/python-performance-at-scale-making-python-faster-at-instagram.html
Je suppose que comme Google en son temps (le projet Unladen Swallow), Meta/Instagram a son propre fork de Python.
Donc ils ont les techos et le code historique. On noteras que c'est pareil pour php avec Hack et facebook d'après mes souvenirs
[^] # Re: pas de javascript donc
Posté par barmic 🦦 . Évalué à 2.
C'est ce qu'ils ont fait pour PHP et ils avaient vachement communiqué dessus. J'ai pas retrouvé l'info, mais il me semble qu'ils utilisent pythran par exemple.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: pas de javascript donc
Posté par Misc (site web personnel) . Évalué à 4.
En fait, c'est dans le lien que j'ai donné. J'ai pas regardé la vidéo, mais dans les slides:
https://github.com/facebookincubator/cinder
Ce qui est intéressant, c'est qu'il y a sans doute plus de gens payé à temps plein sur le fork qu'upstream.
[^] # Re: pas de javascript donc
Posté par barmic 🦦 . Évalué à 2.
Oh c'est intéressant. Ils ont l'air de vouloir converger vers cpython sans pour autant être actif. Je sais pas comment ils vont gérer l'évolution de python. Pour le moment ils sont sur 3.8 et je n'ai pas vu quel était le plan : y rester, rappliquer leurs changements sur une version intéressante ou merger avec cpython.
Et ils ne s'intéressent qu'à la performance et ont l'air de dire qu'ils ajoutent peut-être des bugs. Plus loin ils disent qu'ils redémarrent assez souvent leurs appli pour que les fuites mémoires ne soient pas un problème. Je sais pas s'ils parle du code instagram ou de cinder lui même.
Ça me donne un peu l'impression d'un besoin de vitesse très pressant et d'un projet assez précipité (on fait de la perf' pour nous, ce serait bien que ce soit mergé mais on le fera pas, on ne fera pas de support et attention on ne corrigera rien si on n'a pas le problème sur notre prod). C'est assez loin de dans la démarche de hhvm ou hack.
On verra comment ça évolue.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Amazon ne recommande pas les technos Google
Posté par corentin38 (site web personnel) . Évalué à -2.
Quelle surprise.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.