Apple va faciliter l’utilisation de Swift sur les serveurs
Swift a été pensé dès le départ comme un langage de programmation multitâche, adapté autant aux apps iOS qu’aux systèmes d’exploitation et même à des applications côté serveur. Depuis qu’Apple propose une version adaptée à Linux de son nouveau langage, des développeurs ont commencé à l’utiliser pour créer des back-ends sur leurs serveurs.
Cette solution est bien pratique pour ne pas avoir à gérer différents langages au quotidien : un développeur iOS peut créer son app en Swift et le module serveur associé également en Swift. Mais ce langage est aussi très performant et il peut aussi avoir son intérêt face aux autres langages et frameworks déjà bien en place sur les serveurs (lire : Sur le serveur, Swift est nettement plus rapide que Node.js).
Face à l’intérêt grandissant des développeurs, Apple a décidé de prendre les choses en main en organisant un groupe de travail chargé de mettre en place des API pour les serveurs. Ce groupe est chapeauté par un employé Apple, mais aussi par un employé IBM et des représentants des frameworks déjà existants. Son objectif sera de proposer une série d’API prêtes à l’emploi pour utiliser Swift sur le serveur.
Apple ne compte pas remplacer les frameworks en place, mais plutôt leur simplifier la vie. Très concrètement, ces API se chargeront des bases indispensables, comme la gestion des protocoles TCP/IP et UDP, la prise en charge des IPv4 et IPv6, de la sécurité des flux avec SSL/TLS ou encore tout ce qu’il faut pour gérer les données en HTTP et HTTP/2. Bref, tout ce qu’il faut pour bien commencer, mais les concepteurs de Swift ne veulent pas proposer des solutions clé en main, ce sera aux créateurs de frameworks de le faire.
Cette nouvelle initiative n’a pas de calendrier défini à ce stade et Apple veut au contraire prendre son temps et accompagner la sortie de Swift 4, la prochaine évolution majeure du langage. Néanmoins, c’est bien le signe que le serveur devient un élément plus important pour le langage.
Et voilà, on est plus très loin d'avoir des petits frameworks pour gérer des API REST en Swift. Les développeurs iOS n'auront bientôt qu'un seul langage à connaître pour développer un service du client au serveur. Très bon coup de la part d'Apple.
+1
Si cela pouvait deborder aussi en dehors des applications et que Swift prenne la place de l'infame Javascript... Python a raté ça, Ruby a raté ça, Java a raté ça, peut etre que Swift...
Ce serait aussi bien qu'Apple aille plus vite et plus loin en livrant une version de Swift pour remplacer l'infame Apple Script, parce que le WEB c'est une chose, reste qu'avant tout le besoin d'automatisation et de programmation touche le terminal, aussi...
l'infâAAAaame applescript n'est pas là pour avoir une syntaxe efficace pour créer des logiciels optimisés
Elle était là pour ressembler grosso-modo à l'anglais pour que monsieur et madame tout-le-monde puisse bricoler deux ou trois automatisations de ses logiciels. Ni plus ni moins. Applescript expose des commandes des logiciels dans un simili anglais logique.
Automator (que tout le monde se fout maintenant) repose sur Applescript, il fait très bien son job, et on lui demande pas plus.
mon point : les usages n'ont aucun rapport et les choses doivent rester sé-pa-rées.
bien sur bien sur.
Apple avait une technologie qui permettait a monsieur et madame tout le monde de faire de la programmation, voire meme du développement, si si, cela etait nommé Hypercard, et le langage, elegant et logique c'était HyperTalk. AppleScript, c'est une mélasse qui a essayé de reprendre l'Hypertalk, en abscons, et sans la structure d'Hypercard...
C'est a la fois un des pires langages qui ait été produit, et c'est aussi un systeme particulièrement inefficace. Automator, c'est la reconnaissance de l'échec d'AppleScript, mais c'est aussi un gros foutoir improductif.
Je veux bien que l'utilisateur puisse faire du parametrage, parce qu'on peut pas parler d'autre chose la, mais faut des outils qui soient un minimum fonctionnels. La on a surtout un beau gros tas de n'importe quoi sans queue ni tete qui s'escrime a compliquer les choses... et encore, c'est sans parler de l'inconsistance de l'IAP qui en est l'épine dorsale (pour ne pas dire dans le pied)
Si tu prends les softs pro de dessin d'en face (non pas la fenetre, le pinguin) le parametrage programmé se fait avec du Ruby, du Python, du Closure, et meme parfois du JS... Et ça marche!
ruby, python, etc n'ont pas de performances suffisantes pour des applications utilisateurs. Certes leur approche plutôt relaxe de la programmation a permis l'éclosion de nombreuses applications.
Mais comme on le voit sous linux, si seulement on pouvait remplacer le zoli programme GTK/pythonné par un bon et performant équivalent Gnome/C, merci. ha oui, c'est pas le même boulot là.
-
Javascript est peut être lui aussi infâAAAame, mais sa syntaxe est limpide, il n'est pas bardé de fonctionnalités ésotériques, il a manifestement permis l'éclosion d'une industrie prospère (tous les fameux services et applications webs) et ses performances ont été redoutablement améliorées.
Il n'est pas un langage infâme, il fait son job (qui est: dire à ce que fichu ordinateur ce qu'on veut qu'il fasse)
"Il n'est pas un langage infâme"
Merci …
A tous ceux qui passent leur temps à le critiquer, et qui d'ailleurs, bien souvent répètent ce qu'ils ont entendu sans se faire une opinion par eux même, je suggère d'abord de lire Douglas Crockford
http://javascript.crockford.com/javascript.html
Et puis ensuite, de s'y mettre, au JS ! :)
"JavaScript is the Wrrrld's Most Misunderstood Programming Language"
@oomu
«Javascript est peut être lui aussi infâAAAame, mais sa syntaxe est limpide, il n'est pas bardé de fonctionnalités ésotériques,»
Un langage reposant sur le modele du prototype, limpide? Sérieux!
La majorité des programmes en JS se limitent au procédural et a des primitives objets sans que soient utilisées les spécificités dont ce langage herite. Pourquoi, parce que c'est un monstre d'inconsistances (bon c'est vrai que la dernière révision a été une belle purge) et d'ambiguitées.
Le seul avantage qu'il permet c'est la programmation événementielle, mais pas parce qu'il est bon pour ça mais parce qu'il est mauvais pour les autres alternatives. L'art du callback decoré avec des methodes qui sont montées en chemin, c'est bien, ça permet de faire du destructuré sur toute la ligne. Apres, va tracer les bug et les les failles introduites... mais la on s'en fout, comme c'est coté client, c'est la faute du client... sauf pour NodeJS, mais voila se mettre a NodeJS c'est autre chose que mettre 2 callback dans un questionnaire HTML...
Et des gars sont en train de porter Swift sur Android. Je le sens bien cette histoire ?
Je n'ai jamais vu un langage remplacer sérieusement Java sur Android sans faire un espèce de truc dégueulasse.
Il n'y a éventuellement que Kotlin, mais il ne semble pas décoller plus que ça.
@ErGo_404 :
Java prend du retard par rapport à la concurrence.
Swift a une sacrée vitesse de croisière pour un langage si jeune. Oracle a franchement besoin de se mettre au travail.
Et j'aime bosser Android. Je ne dis pas ça pour le fun.
@Hasgarn
Java n'est pas en retard, Java est calé dans un paradigme et souffre de l'heritage du C. Le paradigme objet de Java c'est celui de C++ ou Modula, cela en reponse au laxisme inherent du C. Mais on reste sur du procedural, fortement typé explicitement, et de l'objet rajouté.
Swift reprend le paradigme objet, mais aussi le paradigme fonctionnel. Le typage est aussi un mix entre les deux approches. On est sur une conception et des contraintes d'applications totalement différentes de celles qui ont présidé a la création de Java.
Et puis faut pas trop compter sur Oracle. A part la dynamique monopolistique et l'isolation de la clientele captive, y a pas grand chose d'autre qui existe dans cette boite.
@ C1rc3@0rc
« Java [...] souffre de l'heritage du C »
Tiens donc, vous m'en direz tant.
"Et puis faut pas trop compter sur Oracle. A part la dynamique monopolistique et l'isolation de la clientele captive, y a pas grand chose d'autre qui existe dans cette boite."
oui.
s/C++ ou Modula/Smalltalk
@harisson
APL y a que ça de vrai ?????
Ben Java sur Android est degueulasse, ceci explique cela.
Apres, par définition Java est construit sur un VM, générer le bytecode a partir de Java ou de Swift ça revient strictement au meme...
Très bonne nouvelle...
étant développeur iOS à la base et swift de manière général depuis la sortie du langage, j'utilise déjà Vapor pour développer des API REST :)
Pour Android, je trouverais ça génial d'utiliser ce langage, mais c'est actuellement encore trop compliqué.
Apple fait vraiment du sans faute sur la gestion de Swift depuis le début ! C'est limite surprenant quand on compare à la gestion d'autres produits... Mais on aura peut-être de bonnes surprises demain...
Sans faute, non, il y en a eu beaucoup, mais Apple a eu l'intelligence d'en faire un vrai projet open source et la on en voit toute la puissance.
Les nombreuses erreurs sont corrigées tres vite, le langage evolue vers un pragmatisme et un developpement qui est fonctionnel et pas dogmatique. C'est aussi ça l'avantage de l'Open source.
@C1rc3@0rc
Les décisions intelligentes ont été prises avec l'ouverture vers l'open source : Swift était déjà très très bon, bien pensé et puissant.
La mise en open source est ainsi une décision intelligente en plus.
@Domsware
Oups. Les doigts ont fourché ! Les décisions intelligentes ont été prises "avant" le passage à l'open source.
Ah ben tu vois le lapsus est revelateur de la realité... Allez un exemple: la boucle "a la C" qui a ete récemment exclue du Swift, c'est une connerie lors de la conception... que l'Open source a rectifié.
Y en a d'autres...
La comparaison entre Swift et Java pour le côté serveur est un peu prématurée je trouve.
Question framework et libraries, Java est a des années lumières devant Swift!
Même si l'enthousiasme ne diminue pas, ça va prendre au moins 10 ans à Swift pour rattraper Java. Je ne parle pas du language ici, mais de l'écosystème.
Faut bien distinguer le langage de son "ecosysteme"
Tu peux utiliser la plupart des librairies et framework Java a partir de Python, Ruby, Closure,... c'est pas le probleme et l'adaptation a un nouveau langage se fait vite.
Comparer Java et et Swift a du sens, les deux etant des langages generalistes, mais Swift a une etendue plus importante que Java.
Java est un langage médiocre en soit, très verbeux, plein de choses inutiles et superflues, mais qui manque aussi des avantages qu'apporte la programmation fonctionnelle. Bien sur, il y a des libraries qui permettent compenser les manques de Java, mais c'est externe au langage.
La programmation serveur demande des qualités au langage spécifiques, et Swift a plus dans ce domaine que Java. Reste que l'on voit avec NodeJS un aspect qui manque autant dans Java que Swift, et on va espérer qu'il va arriver dans Swift très vite.
Ce qui manque le plus a Swift aujourd'hui c'est la gestion interne de la programmation parallèle, ce qui est assez incompréhensible pour un langage né après 2010. Il y a d'ailleurs un autre langage qui n'a rien a voir mais qui se nomme aussi Swift qui lui est un pur du parallélisme.
quand on pense Java, on pense à tout l'univers qui est construit autour.
Java Enterprise, les serveurs applicatifs, les projets Apache et j'en passe.
-
théoriser sur la beauté des syntaxes et fantasmer qu'une syntaxe et parti-pris d'un langage pour tout couvrir (la programmation fonctionnelle, la réutilisation objet, le parallélisme, le typage fort, le typage faible, le dynamique, le statique, la performance, la facilité...) doit à un moment être mise de coté.
A un moment, il faut mettre en place des outils de travail pour les gens qui doivent produire et pour l'heure, un monde entier est bâti sur java et il fonctionne.
-
Cela n'enlève rien à l'intérêt que peut susciter Swift à la fois coté client et coté serveur.
Par exemple avec le web, je n'ai jamais été satisfait par le mix entre javascript sur le web et php/nodejs/python/ruby on rail/autres lubies du jour coté serveur.
Remplacer tout ça par du swift des deux coté, au moins pour les applications clientes, et le serveur serait déjà séduisant.
Mais le problème est le framework applicatif (l'environnement de développeur, les apis, le runtime, l'administration, etc).
Tant qu'on a pas un framework qui est à la fois coté client et coté serveur (conçu ensemble pour couvrir dans une même logique, une même documentation, une même cohérence) on aura pas amélioré le boulot et on fera juste que remplacer une lubie par une autre.
Bref, swift ? ok, cool, mais parlez moi Bibliothèques et _FRAMEWORK_.
Java c'est bien pour les bœufs, quelle lenteur, ne parlons même pas des failles de sécurité par millions, ou encore de la config... Swift n'est pas prêt de faire la moitié de ce qu'on peut faire en Java, mais pour le reste, le fait bien mieux.
Par quelle miracle les framework Switch n'auront/aient pas eux aussi leurs failles ?!
Jack ferait bien de se mettre à jour ou de s'arrêter de parler de qu'il ne comprend pas.
La lenteur de Java tient du passé et souvent de la légende parce que c'est un langage qui est fait pour tourner sur une VM. Swift utilise lui aussi une VM, meme s'il peut être compilé en natif.
Apres, le gros problème de Java c'est pas la vitesse d'exécution, les compilateurs JIT arrivent souvent a des performances très suffisantes, le gros problème c'est la gestion de la mémoire. C'est la ou ça plante et que l'on trouve les principales failles!
Maintenant savoir si Swift va faire mieux que Java niveau gestion de la mémoire, ça reste de l'avenir, le modele actuel est loin d'etre optimisé...
@C1rc3@0rc
Où est-ce que Swift tourne sur une VM?
La partie "VM" est au niveau du compilateur LLVM, qui génère d'abord du Swift Intermediate Language (SIL), lui-même optimisé à différents niveaux selon la plateforme, et qui finalement génère du code machine.
@C1rc3@0rc
non.
@C1rc3@0rc
??????????
WTF !
"A mauvais ouvrier il n' y a pas de bons outils."
Ce vieux dicton devrait souvent être méditer sur les enjeux de dev.
La tendance est souvent de se focaliser sur les langues et les framework, ce qui est bien pratique pour occulter d'autres considérations bien plus prégnantes sur les enjeux de qualités, de sécurités et de performances.
Croire que le "bien programmer" peut se résoudre à des considérations d'outils et de langages est un des aveuglement les plus contre productif du milieu ?
Finalement, y va p'têt se passer quelque chose au niveau des serveurs OS X
@béber1
Combien de divisions ? ;-)
awk
tu lis trop ton bréviaire stalinien http://yelims5.free.fr/Violence/Violence03.gif
@béber1
Je suis plutôt IVem internationale que vieux stal
mais je connais mon petit père des peuples ??
mouais, mais au fond t'es un vieux anarchisto-sceptique. ?
Ô homme de peu de foi
@béber1
Tendance Groucho ayant fini sa crise maximaliste ?
soit un Utopisto-Freedonien...
On est mal barré ?
@béber1
????