[F] [mOved] Mon langage est mieux que le tien - Page 107

FPM est clairement la solution préférée pour PHP de nos jours, en tout cas.

Je ne vais pas parler de ma prod, vous ne voudriez pas avoir un infarctus mais oui, c'est probablement ce qui arrivera lors de la migration du serveur prévue pour... bientôt ?
FPM sur la prod et module classique sur mon poste.

Gitlab il fait utiliser le paquet omnibus, plus de galère, sink effectivement c'est une galère pas possible (j'avais utilisé docker pour éviter la galère ruby ya 2 ans).

L'utilisation de Node.JS se répand de plus en plus dans les grosses boîtes, même pour des projets importants :
https://dev.to/anthonydelgado/javascript-is-eating-the-world

Il y a peut-être une porte de sortie, je ne me suis pas renseigné mais on dirait que WebAssembly n'est pas si loin de prendre la relève : http://webassembly.org/ (auquel cas n'importe quelle langage pourrait compiler vers du WebAssembly de façon beaucoup plus fiable que les "transpileurs" actuels, et JavaScript ne serait plus un langage de premier choix pour ce domaine).

Je me demande à quel point on va garder les stigmates du JS dans WebAssembly, de la même façon qu'on voit l'héritage de la JVM sur les langages qui utilisent le bytecode Java.

Même si en soi, c'est déjà une très bonne nouvelle, aura-t-on à terme une lib standard en WebAssembly ?

On en a déjà parlé, pour moi c'est deux mouvements indépendants ; WebAssembly va fournir un nouveau langage, en revanche je ne vois pas pourquoi les plate-forme cibles changeraient leur lib standard. Celle de Node.js s'étoffe petit à petit (doc), celle des navigateurs risque d'être beaucoup plus complexe à bouger.

Sinon pour les stigmates du JS, tu penses à quoi ? Je ne vois que l'absence de typage, et WebAssembly possède bien des types donc de ce côté c'est bon. Pour le reste j'ai l'impression que JS permettait déjà pas mal de choses, c'est simplement la syntaxe qui ne te plait pas (mais c'est exactement ce que va faire disparaître la VM).

Zeph (./3185) :
Il y a peut-être une porte de sortie, je ne me suis pas renseigné mais on dirait que WebAssembly n'est pas si loin de prendre la relève : http://webassembly.org/ (auquel cas n'importe quelle langage pourrait compiler vers du WebAssembly de façon beaucoup plus fiable que les "transpileurs" actuels, et JavaScript ne serait plus un langage de premier choix pour ce domaine).

Je pense que si WebAssembly est clairement une bonne chose, mais le mal est déjà fait. JavaScript est dans une situation, bien pire que l'a été Visual Basic car il a en plus un effet de mode qui fait que les gens qui en font sont convaincu de manipuler une techno géniale.
Je pense qu'il faudra bien une dizaine d'années avant que tout ceux qui ont investi dans le JavaScript acceptent de reconnaitre que c'était une très mauvaise idée de promouvoir ce langage pour du développement d'application lourdes.

flanker (./3186) :
Je me demande à quel point on va garder les stigmates du JS dans WebAssembly, de la même façon qu'on voit l'héritage de la JVM sur les langages qui utilisent le bytecode Java.

A priori pas trop vu que WebAssembly ne vise pas du tout le JavaScript mais plutôt les langage bas niveau comme le C.
Il faut plus le voir comme un LLVM IR, mais normalisé.

flanker (./3186) :
Même si en soi, c'est déjà une très bonne nouvelle, aura-t-on à terme une lib standard en WebAssembly ?

Non c'est un bytecode, pas un langage. Tu utilisera la lib standard de ton langage et les API Web (CAnvas, DOM, WebGL, ...)

Sinon pour les stigmates du JS, tu penses à quoi ? Je ne vois que l'absence de typage, et WebAssembly possède bien des types donc de ce côté c'est bon.

Rien en particulier, simplement je me souviens des promesses qu'on m'avait faites sur le Scala (« tu verras, tous les défauts de Java ont été supprimés »), et au final on voit le Java réapparaître aux coutures (genre des bugs de typage qui sont liés à la différence Integer/int en Java, mais qui ne devraient pas exister en Scala).

Uther (./3188) :

flanker (./3186) :
Je me demande à quel point on va garder les stigmates du JS dans WebAssembly, de la même façon qu'on voit l'héritage de la JVM sur les langages qui utilisent le bytecode Java.

A priori pas trop vu que WebAssembly ne vise pas du tout le JavaScript mais plutôt les langage bas niveau comme le C.
Il faut plus le voir comme un LLVM IR, mais normalisé.

ok, je ne connais pas trop le sujet (j'attends que ça mûrisse un peu pour voir ce que ça donne)

flanker (./3186) :
Même si en soi, c'est déjà une très bonne nouvelle, aura-t-on à terme une lib standard en WebAssembly ?

Non c'est un bytecode, pas un langage. Tu utilisera la lib standard de ton langage et les API Web (CAnvas, DOM, WebGL, ...)

Ce n'est pas incompatible ^^ on pourrait imaginer des libs compilées en WebAssembly et utilisables dans tous les langages compilés en WebAssembly (un peu comme .Net, ou dans une moindre mesure ce qui se passe avec les libs C qui sont utilisables dans plein de langages).

encore une machine a pile?

Pourquoi "" ?

parce que c'est plutot inefficace le bytecode java, et ce truc y ressemble beaucoup, sauf qu'il a accès a de la RAM mappée et des pointeurs en plus. j'espère que ce machin aura un JIT derrière.

Tous les langages modernes basés sur des VMs de ce type ont un JIT derrière donc on peut sans trop s'avancer supposer que ça sera le cas ici aussi. Les navigateurs actuels en ont déjà pour le JS et là ça sera d'autant plus facile que le bytecode est fortement typé et donc que le boulot du JIT est grandement facilité. Ça fait quand même quelques années que ce type de VM n'est plus un frein pour les performances, c'est plutôt le GC qui va jouer ici. Le "" me parait un peu rapide et réducteur ^^

squalyl (./3190) :
encore une machine a pile?

Bof on s'en fout un peu non? Ca ne fait une différence que si on fait de l'interprétation pure et dure. Le but du WebAssembly, c'est d'être compilé et dans ce cas la ça permet un code plus léger a télécharger et plus rapide a compiler.

Et surtout, ça évite de définir un nombre arbitraire de registres, sans connaître le vrai nombre de registres de la plateforme ciblée, et de se casser la tête avec l'allocation de registres sur ces registres arbitraires. À la place, le JIT pourra allouer les registres de manière optimale pour la plateforme.

Et évidemment qu'il y aura un JIT, le but étant d'être plus rapide que le JavaScript qui a déjà un JIT dans tous les navigateurs récents.

En fait ça sera pas forcément un JIT, la spec permet aussi de faire de la compilation en AOT.

Du vrai AOT serait côté serveur et on se retrouverait avec le problème de sécurité. Comme ce sera du côté client, ce sera forcément au téléchargement de la page, donc JIT.

C'est juste qu'on utilise pas la même terminologie. Pour moi il y a une différence entre JIT/AOT et client/serveur.

Le JIT signifie que certaines parties du programmes sont interprétées ou compilées et éventuellement recompilées avec des paramètres d'optimisation différente, pendant qu'il est en train d'être exécuté.
Alors qu'en AOT, tout est compilé une fois pour toute avant l'exécution, mais ça n’empêche pas que la compilation peut-être faite, coté client.

Les applis Facebook pour Windows ont apparemment une conception... amusante :
https://what.thedailywtf.com/topic/23700/mystery-of-the-facebook-apps-for-windows

C'est moi, ou l'info ressemble de plus en plus à ça ?

XD

Manque un peu d'emulation Android dans la sauce

Non mais en fait l'émulateur d'iOS est écrit en Javascript (qui lance webkit qui lance du javascript).

J'aurais préféré

Javascript/Node -> Emulation Android -> Emulation iOS -> WebKit → Javascript

---

Ya pas a dire node/npm ca marche du feu de dieu !

Maya:crunchyroll.js godzil$ sudo npm -g install
/usr/local/bin/crunchy -> /usr/local/lib/node_modules/crunchy/bin/crunchy
+ crunchy@1.1.19
added 79 packages and updated 1 package in 18.162s
Maya:crunchyroll.js godzil$ sudo npm -g install
/usr/local/bin/crunchy -> /usr/local/lib/node_modules/crunchy/bin/crunchy
+ crunchy@1.1.19
added 17 packages and updated 1 package in 2.15s
Maya:crunchyroll.js godzil$ sudo npm -g install
/usr/local/bin/crunchy -> /usr/local/lib/node_modules/crunchy/bin/crunchy
+ crunchy@1.1.19
added 79 packages and updated 1 package in 3.248s
Maya:crunchyroll.js godzil$ sudo npm -g install
/usr/local/bin/crunchy -> /usr/local/lib/node_modules/crunchy/bin/crunchy
+ crunchy@1.1.19
added 17 packages and updated 1 package in 2.338s
Maya:crunchyroll.js godzil$ sudo npm -g install
/usr/local/bin/crunchy -> /usr/local/lib/node_modules/crunchy/bin/crunchy
+ crunchy@1.1.19
added 79 packages and updated 1 package in 15.192s
Maya:crunchyroll.js godzil$ sudo npm -g install
/usr/local/bin/crunchy -> /usr/local/lib/node_modules/crunchy/bin/crunchy
+ crunchy@1.1.19
added 17 packages and updated 1 package in 2.316s


[...]later[...]

Maya:crunchyroll.js godzil$ sudo npm install -g
/usr/local/bin/crunchy -> /usr/local/lib/node_modules/crunchy/bin/crunchy
+ crunchy@1.1.19
updated 1 package in 2.363s
Maya:crunchyroll.js godzil$ sudo npm install -g
/usr/local/bin/crunchy -> /usr/local/lib/node_modules/crunchy/bin/crunchy
+ crunchy@1.1.19
added 96 packages and updated 1 package in 11.278s

Pourquoi executer la MEME commande plusieurs fois d'affilé n'a pas le meme comportement? o_O

Ben Node est quantique, tu peux pas comprendre

Ca doit etre ca XD

Suite du ./3199 :

I just attempted to browse my Facebook Page's messages in app. Gradually my computer slowed to a crawl. Task Manager revealed that every time you click something in Page Messages (e. g. Delete message, Archive message, switching folders, or just entering and exiting selection mode), a new Facebook process is started. Which is a browser process because the last one loaded without the CSS all Times New Roman-y. These processes all eat 50 MB of memory on average.

Then I got an error message with a link saying "Back to home". Clicking it took me to the News Feed but with a very different layout. It had a "This website uses cookies" notice on the top.

XD

#gerbe#