Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Facebook avait utilisé PHP principalement car il était facile de trouver des développeurs PHP pour leur besoin énorme de croissance tant au niveau code (mais aussi au niveau infra).
Cependant on a vu avec hiphop que PHP avait commencé à leur poser problème (performances) et qu'ils ont travaillé pour non pas s'en séparer (vu leur base de code c'est illusoire) mais pour contourner le problème etc.
Non, Mark Zuckerberg a utilisé Facebook parce que c'est ce qu'il maîtrisait le mieux, qu'il codait ça pendant ses études, et qu'il devait faire vite pour piquer l'idée aux jumeaux trop occupés à faire du rameur.Envoyé par David_g
Une fois bien lancé, il s'est trouvé coincé avec ce choix technologique, il a dû faire avec et trouver des solutions (parfois assez compliquées). Aujourd'hui fb se trimballe encore ce choix historique, même s'ils essayent de le remplacer petit à petit par autre chose (mais ça prend du temps, Rome ne s'est pas construite en un jour).
Bref, quand on a des deadlines super serrées, on ne choisit pas forcément la solution la mieux adaptée mais la plus accessible, c'est-à-dire :
- celle qu'on maîtrise le mieux (on ne perd pas de temps à devoir apprendre quelque chose de nouveau)
- celle qui respecte le budget (ça sert à rien de choisir une technologie qui fait le boulot à notre place si on ne peut pas se l'offrir à cause du coût des serveurs ou autre)
Une fois ce choix effectué, généralement on l'assume pendant assez longtemps par la suite. Vu qu'on ne peut pas se permettre de tout réécrire du jour au lendemain, on fait des patches et des bidouilles pour que ça continue de tourner.
Donc Mark Zuckerberg a choisi PHP parce que c'était plus accessible pour lui que le reste (y compris Java) et a recruté plein d'ingénieurs par la suite par rapport à ce choix historique (et non pas parce qu'il y avait plein de développeurs PHP : il y avait autant, si ce n'est plus, de développeurs Java en 2004).
"On en a vu poser les armes avant de se tirer une balle dans le pied..."
-- pydévelop
Derniers articles:
(SQL Server) Introduction à la gestion des droits
(UML) Souplesse et modularité grâce aux Design Patterns
(UML) Le Pattern Etat
Autres articles...
Justement si cela avait été un peu étayé ça aurait été intéressant, mais là c'est creux ... vide, nada.
Pire, cela fait penser à ceux qui faisaient "mumuse" avec des Applets en 1997 dans Netscape Navigator ou dans IE 4 et qui disaient (à raison) "Java c'est lent" ... mais depuis (on est en 2012 je le rappelle) ce n'est plus vrai et malheureusement les vieilles idées reçues ont la peau dure. Java a pris un sérieux "boost" avec la 1.4.2, puis la 1.5 et encore la version 6 ... et la 7 c'est du bonheur.
A chaque version, les performances de la JVM (avec du bytecode client JAVA inchangé) sont meilleures.
Bref, un argumentaire de bistro émanant d'Andi Gutmans, ça fait un peu pitié.
Ca ne sera jamais aussi bon que du natif assembleur ou C micro-optimisé au poil de derche.
Mais, pour une très grande majorité d'applis, ça suffit, aujourd'hui. Ca n'a pas toujours été le cas, et c'est une réputation qui va être difficille à décoller de la semelle.
Ca me rappelle le bon temps de ces débatset a cette époque, vu du Java plus rapide que du C, because HotSpot était plus futé que le développeur qui n'avait pas utilisé toutes les bonnes options d'optimisations ... Cela étant dans ce débat, n'oublions pas que la partie strictement "calcul" dans une application web reste limitée et 100x plus lent peut au final ne se traduire que par un x3 ou x4 (et pour peu que tu fasses du templating de ouf dans ton IHM ...).
C'est certain.Je te rejoins sur ce point. D'ailleurs quand on le souhaite on appelle du code natif avec JAVA (JNI) ... donc on a toujours la possibilité de le faire, mais on perd le "compile once, run anywhere" ...
De plus, je me vois mal faire un site web en JSF + Ajax + Transactionnel + Load Balancé en assembleur
A une époque je m'amusais même à ré-écrire mes routines d'accès à la carte vidéo (mode X 13h pour ceux qui se souviennent) avec Triple Buffering et tout tout ... et un jour est arrivé Direct X ... plus personne ne fait sans Direct X aujourd'hui.
Code : Sélectionner tout - Visualiser dans une fenêtre à part mov eax, [ebx]
J'ai envie de dire que les compilateurs de chaque langage s'améliorent à chaque version. Niveau argumentaire pitoyable, tu l'as rejoint sans vouloir te manquer de respectA chaque version, les performances de la JVM (avec du bytecode client JAVA inchangé) sont meilleures.
Bref, un argumentaire de bistro émanant d'Andi Gutmans, ça fait un peu pitié.
De nos jours, je ne suis pas persuadé que les dev C++ les plus pointus aillent bidouiller le binaire final pour gagner en perf ni inclure de l'assembleur.
C'est vachement plus simple de filer les options d'optimisation au compilo.
Maintenant, vu que la question ici concerne PHP: l'interpréteur PHP a-t-il des "options de compilation" ou trucs du genre pour améliorer les performances sans toucher au code ?
Après, si on veut vraiment choisir le meilleur langage, je pense que le meilleur, c'est celui déjà utilisé. Si on tape dans les limites, il faut ensuite voir si quelqu'un dans l'équipe maîtrise un langage mieux adapté et qui peut s'interfacer avec le 1er.
Parce que bon, la formation c'est pas donné, sans compter que, pendant ce temps, le travail n'avance pas. Et si en plus il faut réécrire une vieille appli... les coûts et les délais explosent pour une perte de stabilité (historique des bugs corrigés).
Malheureusement tu me fais dire ce que je n'ai pas dit.
Je n'ai pas dit que les autres de s'étaient pas améliorés, j'ai juste dit que Gutmans s'était figé dans le temps en ce qui concerne JAVA ... version 1996 ... et qu'il a dû oublié d'étudier sérieusement les autres plateformes que la sienne dans l'intervalle et je trouve cela consternant.
J'ai quand même fourni quelques benchmarks et d'autres contributeurs aussi, je pensais avoir un peu argumenté mon point de vue ... ou alors tu n'as pas tout lu, sans vouloir te manquer de respect
Si tu fait attention lorsque tu utilises Facebook tu ne change pas beaucoup de page (enfin lors mon utilisation en tout cas), beaucoup de choses se fait en Ajax. La problématique de Facebook est surtout lié a la rapidité d'acces aux données et ce, n'est pas directement lié au language de programmation. D'ailleurs Facebook a en interne ses propres outils PHP et bases de données sur mesure, donc ce n'est pas tellement facile de comparer Facebook et PHP.
Je résume, fb réécrit memcache et ses drivers réseau, du C donc, écrit Cassandra, un NoSQL en Java, un compilateur PHP/C++ ... je ne serais pas surpris de trouver quelques bricoles en Python et autres langages, bref, fait ce qu'on fait tous dans ces cas là, utiliser les technologies adaptées au problème donné.
A miboo plus haut, au sujet des applications Java "lentes", pour information, bon nombre de sites web, c'est vrai plutôt "pro", sont développés sur des solutions comme Liferay, Nuxeo ... et autre ametys, hippocms. Il est vrai qu'in fine, les pages ne sont pas suffixées en .jsp ...
Je n'ai jamais dit que Facebook a creer ses propres languages de programmation, drivers... ne fait pas dire ce que je n'ai pas dit, surtout en presentant les extremes.
C'est juste que Facebook a developer certains de ses propres outils, et pas seulement concernant le PHP (n'est ce pas), pour pallier a de nouveaux problemes majeurs que les outils existant ne sont pas toujours capables de repondre (ou de maniere inadaptee), tel les donnees par exemple.
Facebook n'est pas la seule entreprise a le faire loin de la.
Répondre avec citation
Partager