Sur le serveur, Swift est nettement plus rapide que Node.js
Swift, le nouveau langage de programmation d’Apple, n’est pas limité aux produits du constructeur. Conçu comme un langage à tout faire, depuis le noyau d’un système d’exploitation jusqu’aux scripts des utilisateurs, il peut aussi servir sur les serveurs. Apple fournit une version prête à emploi pour Ubuntu qui sert justement à exploiter le langage sur un serveur, où Linux domine largement.
Pour utiliser Swift sur un serveur, il faut tout développer soi-même toutefois, ce n’est pas un langage prêt à l’emploi comme peut l’être PHP. Néanmoins, plusieurs frameworks proposent tout le nécessaire pour créer des applications en Swift dédiées à un serveur, sans avoir à gérer soi-même les connexions entrantes et sortantes et tout le reste. Mais que valent-ils sur le plan des performances, et par extension, comment se positionne Swift sur le serveur en termes de vitesse ?
Pour le savoir, Ryan Collins a comparé ces frameworks à un poids lourd côté serveur, à savoir Node.js qui permet d’utiliser du JavaScript sur un serveur. Cet environnement est devenu extrêmement populaire et de nombreuses entreprises l’utilisent pour leurs services, de Netflix à Uber, en passant par eBay et des centaines d’autres. C’est un outil très populaire, mais qui n’a jamais été très rapide et la comparaison avec Swift est impitoyable : node.js est souvent bon dernier.
Les mesures ont été effectuées sur un Mac mini de 2012, où Ubuntu a été installé nativement (sans virtualisation). Deux applications minimales ont été créées, un blog et une autre qui génère un fichier JSON, pour simuler au mieux un usage réel de ces langages de programmation sur les serveurs. À l’exception de l’un des frameworks Swift qui avait un bug connu avec le JSON, Node.js a toujours terminé dernier sur les benchs qui mesuraient à la fois le nombre maximum de requêtes gérées correctement par seconde et le temps de réponse.
Naturellement, le choix d’un langage n’est pas lié uniquement aux performances. Dans le cas de Swift, l’intérêt pour les développeurs iOS et macOS est d’utiliser le même langage et pourquoi pas même les mêmes lignes de code pour leurs apps et pour le module serveur associé. C’est la même logique pour Node.js : les développeurs de sites web utilisaient déjà du JavaScript, ils pouvaient garder les mêmes compétences sur le serveur.
Si vous voulez commencer à utiliser Swift sur les serveurs, Perfect est un bon point de départ. Il est le plus rapide sur toutes les mesures effectuées par Ryan Collins et il semble plus avancé et complet que ses concurrents.
Une comparaison totalement biaisée, cf http://reddit.com/r/programming/comments/56elc2/nodejs_vs_swift_serverside_frameworks_benchmarks/d8itl11
Deja la comparaison exclue Java qui reste le poids lourd du secteur.
Ensuite il n'y a effectivement pas que la vitesse d'excecution mais aussi l'adaptation a la tache (le modele de programmation par exemple) et surtout il y a la masse et la dimension de l'usage.
NodeJS n'est certainement pas le plus performant ni le plus representé, mais son modele evenementiel et le fait que ce soit du Javascript, tres utilisé en programmation WEB, lui offre un avantage majeur.
De fait Swift se positionne plus contre Java, que contre Javascript (NodeJS).
Apres en terme de performance, c'est le meme modele pour tous: machine virtuelle!
Une fois la conversion en bytecode faite, c'est a ce niveau que ce fait l'optimisation, et la c'est la bataille des VM et des compilateur JIT.
Mais une chose est certaine, c'est que Swift a un developpement tres rapide et qu'il arrive a tous les niveaux (ou presque) ou la programmation est necessaire. Et c'est un vrai langage, avec une vraie puissance. Par contre il est encore trop instable en terme de normalisation pour s'affirmer face a Java, C++ et Python.
Mais la politique d'Apple semble tenir la route et il est probable qu'a terme Swift va prendre la place de beaucoup d'autres langages et framework. Si on pouvait avoir Swift a la place de Javascript et PHP ce serait deja une tres grosse avancée pour le WEB, c'est evident.
Faudrait que les navigateurs supportent déjà Swift pour ça. On en est loin pour l'instant.
@byte_order :
?????
On parle de Back end, pas de Front end
Théoriquement c'est pas compliqué, la machine virtuelle de Chrome peut autant faire tourner du JS que n'importe quoi d'autre.
D'ailleurs le moteur de NodeJS c'est généralement V8, et V8 est utilisé pour motoriser le projet Dart chez Google, qui peut faire tourner potentiellement n'importe quel langage et vise plus particulièrement a unifier la programmation coté serveur et coté client.
Il suffit qu'Apple de son coté supporte Swift dans Webkit, et la programmation coté client va basculer sur Swift très vite. D'ailleurs l'arrivé de l'environnement de programmation Swift sur l'iPad est un signe avant coureur assez clair.
On a aussi l'exemple avec la VM de Java qui peut faire tourner aujourd'hui du Python au Lisp. La question de fond c'est d'arriver a avoir un langage robuste et unifié qui couvre le client et le serveur. Java avait tenté d'etre cette unification, mais la lourdeur de Java et sa complication syntaxique l'on ejecté du client. Javascript, s'il a avec NodeJS un certain succes, reste Javascript avec ses lacunes et son modele si particulier difficilement compatible avec les contraintes au niveau programmation backend. Swift a la qualités nécessaires pour transformer l'essai.
@ C1rc3@0rc
Sous Sierra, l'application Console.app a été ré-écrite en Swift si j'ai bien compris.
(Et elle est pas mal boguée, et c'est une horreur côté dev, tout log qui n'est pas un log d'erreur partant vite dans le nirvana.)
...un moteur de blog codé en utilisant...
En 2016, plus personne ne code, sauf besoin extrêmement particulier, et c'est tant mieux.
Celui qui n'a jamais utilisé ce type de terminal http://aconit.inria.fr/omeka/archive/files/99010a4ab2fbcc715fae4a6d4e402650.jpg n'a jamais codé de sa vie et ne sait pas ce que c'est que de coder, et c'est tant mieux.
Halte à l'appauvrissement du langage et de la pensée ! Halte au vautrage dans la médiocrité !
@heret
Tu peux pas changer de disque un peu ? T'es lourd.
AAaaaah un p'tit enculage de mouche de temps en temps ça ne fait de mal à personne
@françois bayrou
La sodomie de drosophile est un noble art ne supportant absolument pas la médiocrité ;-)
Sur des usages largement partagées même par les plus hautes autorités de la science informatique depuis des décennies, ce n'est pas de la sodomie de drosophile, mais du sectarisme égotique obtus vaguement réactionnaire et rance.
Par contre l'enculage de mouche sur l'abus de langage consistant a parler des coder en lieux et place de chiffrer me semble encore avoir sa placer pour la cryptographie :-)
@ Mickaël Bazoge
C'était pas de l'humour ?
@marc_os :
Non c'est une vieille antienne du gars :-)
@heret :
Cool off, hombre.
“To code” en anglais courant est devenu synonyme de programmer, et vous le savez sans doute mieux que la plupart d'entre nous.
Au point que l'IEEE précise :
« For the purpose of clarity ‘source code’ is taken to mean any fully executable description of a software system. It is therefore so construed as to include machine code, very high level languages and executable graphical representations of systems. »
Tout est dit.
Que l'usage anglophone déteigne sur l'usage francophone peut être regretté, mais c'est probablement inévitable :
https://code.org
https://code.visualstudio.com/?utm_expid=101350005-28.R1T8FshdTBWEfZjY0s7XKQ.0
Les chances de renverser la tendance sont commensurables avec la probabilité de survie d'un mollusque gastéropode dans une supernova.
@occam
S'il emplois les vocables de quincaille et mentale en lieu et place de Hardware et Software, il peut continuer à faire le malin avec ce combat d'arrière garde reposant qui plus est dur rien de réellement fondamental même d'un point de vue théorique.
Alfred Aho, Peter Weinberger et Brian Kernighan ont tous utilisé le terme, cela suffit pour moi à le valider :-)
@awk :
Pour une fois que j'y vais mollo et que je m'essaie à la pédagogie douce...
@heret :
L'usage du vocable coder pour désigner l'acte de programmer est on ne peut plus ancien, classique et largement partagé dans la communauté même parmi ses membres les plus éminents et reconnu.
Il faut arrêter avec cette fausse rigueur
Et pourtant le Larousse qui ne s'illustre pas par l'appauvrissement de la langue française nous dit "Appliquer un code à des données ; écrire un programme pour ordinateur.".
A ce qu'on sache, un fichier source javascript est bien un programme à destination des ordinateurs. Donc un code. Donc codé.
J'attends de voir ton moteur de blog codé en assembleur à l'œuvre ^^
@heret
cela fait à peu près 25 ans que j'utilise cet anglicisme/barbarisme/qu'importe "coder" pour le fait d'écrire du code informatique pour mes ordinateurs, au travail et hobby.
Et tous mes collègues font de même. Il en état de même quand j'étais étudiant et je vois la même chose continuer avec les étudiants actuels et un peu partout.
Alors, peut être qu'on aurait pu sauver l'Humanité de Son Triste Et Funeste Sort si on avait évité l'usage d'un énième argot mais c'est à mon avis complètement inutile et illusoire de croire influencer qui que ce soit sur ce point.
"Coder" est clairement gravé comme un synonyme de programmer un ordinateur. Cette expression est banale, courante, vielle et utilisée du plus illustre ingénieur de l'industrie jusqu'au plus obscure webcomics en passant par une foule de hackers à casquette...
sans espoir.
Tiens, qu'en dit XKCD ? (sur les polémiques sans intérêt, toujours vérifier l'opinion de XKCD).
Avis perso : c'est une expression que j'apprécie et qui m'apparait totalement légitimée de nos jours.
-
sur ce, je retourne sshiser sur mon serveur ^^,
oomu, t'es magique :)
C'est quoi ? Un orgue électronique ? Jean-Michel Jarre utilise ça ? Lol
@pim
Intéresse toi un peu à l'histoire de l'informatique tu découvrira plein de choses étonnantes ;-)
Pas équipé pour comprendre l'ironie ?
@ codeX
Tu sais, l'ironie sur ce genre de forum a souvent du mal à passer.
Pourtant, le commentaire initial de heret était visiblement de l'humour tellement c'était gros.
Comme si on disait (au hasard) qu'aujourd'hui rien ne vaut les cartes perforées.
Mais non, certains préfèrent gloser sur l'usage de certain mots, répondant par là même à la définition du troll, à savoir du fouteur de merde qui détourne les gens du sujet initial.
Pour preuve, compter la proportion de commentaires ici parlant de Swift vs. Node.js... :/
En plus, les trolls les plus virulent ont double casquette, ils sont en plus donneurs de leçons ! Détestable.
@marc_os
Non le commentaire d'heret n'est pas de l'humour c'est un de ses combats ne reposant hélas sur rien de sérieux et de défendable.
@codeX
Toujours délicat à détecter surtout quand on ne connait pas la personne :-)
Bonne chose en soit, de pouvoir « lier » … une machine à une autre lors du développement.
Ici iOS avec n'importe quel système sur lequel, en théorie on installe Clang
… et zooo, ça roule pour exécuter n'importe quoi écrit en Swift ???
"node.js qui est connu pour sa lenteur" !!!
Si je suis cela de loin, je suis tout de même surpris par la qualification de lenteur pour node.js.
Ok, cela doit bouger en permanence. il me semble tout de même que la montée de node.js reposait justement sur sa rapidité face aux anciennes versions de php.
Sinon, le concept d'un langage pour ces deux usages je trouve cela plaisant. Surtout pour des programmeurs du dimanche comme moi, pour lequel applescript (avec par exemple pashua) et php permettent de "mal" écrire des petits trucs mais sont limités dans leur usage (GUI pour php avec un suivi aléatoire). D'ailleurs la pléthore de langages qui apparaissent, réapparaissent est surprenante pour un néophyte.
Je suppose que swift n'est pas le seul langage avec ce double usage.
stat à considérer avec prudence, indicative sur l'usage des langages au sens très large :
http://www.tiobe.com/tiobe-index/
@cv21 :
Sur php je t'invite a te mettre à jour sur l'état de l'art et des usages ;-)
ben justement je suis resté à l'approche de php3 (ça date !) ! ;-)
Des programmes écrit en linéaire, je ne sais plus quel est le terme exact, avec 2, 3 fonctions pas plus. Les objets c'est beau, compréhensible mais bon vu le niveau et le besoin... alors quand le "moteur" de php 7 est mise à jour, ben ok, cela ne change pas grand chose pour mes petits trucs.
Je suis plutôt dans le gribouillis que dans l'art ! ;-)
Au moment ou les circonstances m'ont amené à apprendre et choisir entre jsp, asp, le choix s'est porté sur php sans regrets. Depuis, je "traîne" effectivement la dessus et cela me rend service.
Je suppose que la remarque porte sur "GUI pour php". Au bon vieux temps, php GTK était marrant, puis quand j'ai essayé de regarder à nouveau c'était en veille il n'y en avait plus que pour python et des tas de GUI. Cela a peut-être encore changé. L'avantage c'est que cela m'a éloigné de ce type de truc pas forcement durable. QT + C, rien à faire je n'ai pas le cerveau pour. Free Pascal/Lazarus (souvenirs de Delphi), ben j'aime toujours beaucoup mais sur mac grosso modo ça colle moins, toujours pour mon cerveau. Avec php je me débrouille, allé hop peut-être qu' avec swift...je me sentirais aussi à l'aise. Le côté double usage avec l'outil de développement fourni avec l'Os c'est un peu grand luxe pour un amateur. Si vous voyez un jour un programme écrit par cv21 fuyez :))
@cv21
Sur tous les langages et framework gravitant autour du net les choses bougent très vite.
PHP 7 n'a plus grand chose à voir avec PHP 3 et ce n'est qu'un exemple.
"node.js qui est connu pour sa lenteur"
Moi aussi, je suis surpris, j'aimerais bien savoir d'ou ça sort.
@françois bayrou
Là tu t'aventure sur des terres dangereuses de guerres de chapelles tout aussi opposée et parfois radicales voir stupide que celles opposant les utilisateurs d'iPhone et d'Androphone.
Qui de PHP et de Node.js est le plus performant ? Dans certains cercle tu peux déclencher une bataille d'Hernani s'étalant sur des jours avec cette simple question.
C'est clair...
En fait, j'avais relevé, mais pas réagi. Je me suis même demandé si le rédacteur n'avait pas posé un piège à troll. C'est en lisant le commentaire de cv21 que j'ai rebondi dessus.
Si ils ont des sources ça m'intéresse, par simple et saine curiosité. Mais sinon, les guerres de religion, oui, je préfère éviter ...
@françois bayrou :
Tu as pas mal de trucs sérieux sur le web analysant les avantages et les inconvénient dès diverses solutions
Au final: there is no silver bullet :-)
Et c'est surtout la qualité des équipes qui va faire la différence dans bien des cas ;-) (Je ne reviendrai pas sur le constat qui t'avait énervé sur l'état du dev sur le web)
"Et c'est surtout la qualité des équipes"
Oui.
Pour le constat sur l'état du dev sur le web : ca ne m'a pas énervé. Je trouve qu'il est faux, tout simplement.
Pour tout te dire, le seul dev que je connaisse et qui pioche comme un cochon sur SO, ne bosse pas dans le web. Il fait des apps iOS.
En même temps comment lui en vouloir : sort de l'école, zéro expérience, et on lui impose des délais tendus. Il n'a pas vraiment le choix.
Après si tu as envie de répéter que tout le monde sur le web fait du copier coller SO, vas y ! Après tout, c'est une chapelle comme une autre :)
@françois bayrou :
Comme toujours les constats se basant sur un échantillon faible et un horizon proche sont sujet à caution;-)
Tout à fait
Et c'est bien pour ça que je ne me permettrais pas, par exemple, de porter un jugement sur l'état de l'art du dev aujourd'hui :)
@françois bayrou
Cela va paraitre présomptueux, vu que je n'ai aucun moyen d'étayer la légitimité de ce qui me permet d'avancer ce jugement, mais je suis dans une position où l'horizon que je peux observer est relativement large et global.
Mais naturellement rien ne t'oblige à me croire,: il y a un vrai soucis ayant d'assez graves conséquences sur, entre autre, les questions de sécurité.
"Cela va paraitre présomptueux, vu que je n'ai aucun moyen d'étayer la légitimité..."
Eh oui : une plume, aussi acide soit elle, montre très vite ses limites quand elle ne signe pas :)
@françois bayrou :
Mais si elle signe, c'est une triple entité ghost in the shell formée pour l'occasion macgesque de Alfred Aho, Peter Weinberger et Brian Kernighan, awk ;)
@SMDL :
Gloire à eux ;-)
@françois bayrou :
C'est un des intérêts de la démarche que d'interagir sans la force de son identité sociale ;-)
C'est assez intéressant
@@françois bayrou
"Après si tu as envie de répéter que tout le monde sur le web fait du copier coller SO, vas y ! "
Au fait résumer les ressorts de mon constat à la pratique servile du "Copying and Pasting from Stack Overflow" c'est une caricature.
Il y a bien d'autres pb fondamentaux que j'avais mis en avant, entre autres sur les fondements théoriques et méthodologiques ;-)
@cv21
Mais ça a l'air génial Pashua ! Comment ça se fait que je ne connaissais pas jusque là ?
Merci pour la découverte ! ?
euh, Vive PHP ! bououh Node.js !
et surtout ne me demandez pas pourquoi :))
@cv21 :
On en connaît qui tiennent une nuit de pseudo débat sans avoir beaucoup plus de cartes en main:-)
Si on choisissait les technologies serveur (ou client d'ailleurs) uniquement sur le critère de la rapidité, ça se saurait. Et heureusement que Swift est plus rapide, sa conception inclus cet aspect dès le départ.
Après évidemment, il faut s'entendre sur "rapide". Pourquoi, comment, dans quelles conditions, avec quels frameworks et technologies, sur quel système et machine, avec combien de clients connectés et quel type de requêtes, usage mémoire, etc. Parce que "plus rapide" sans une page pleine de spécifications et de critères d'évaluation, ça ne veut strictement rien dire.
@fte
En paraphrasant Henri Queuille : "Les benchmark n' engagent que ceux qui les reçoivent."
Et à minima l'analyse des résultat d'un benchmark demande un lourd travail de contextualisation et de questionnement.
Après la dynamique qui se met en place autour de Swift est très intéressante, je trouve
Très intéressant.
Pas le faut qu'il batte Node.js sur leur test (j'suis pas allé lire en détails ce que ça faisait exactement, et ça m'est un peu égal à vrai dire), mais le bon point est plus que Swift essaye tout du moins de se faire une place sur les serveurs, ce qui pourrait nettement éviter d'apprendre aux développeurs iOS/OSX un autre langage.
Bon, reste la question des frameworks, mais vu que ça tente de se faire une place, espérons qu'ils arriveront et seront efficaces.
Pages