Apple va faciliter l’utilisation de Swift sur les serveurs

Nicolas Furno |

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.

Le logo de Perfect, lun des frameworks serveur en Swift les plus populaires.
Le logo de Perfect, l’un des frameworks serveur en Swift les plus populaires.

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.

avatar Rez2a | 

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.

avatar C1rc3@0rc | 

+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...

avatar oomu | 

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.

avatar C1rc3@0rc | 

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!

avatar oomu | 

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)

avatar françois bayrou | 

"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"

avatar C1rc3@0rc | 

@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...

avatar SkeletonGamer | 

Et des gars sont en train de porter Swift sur Android. Je le sens bien cette histoire 😀

avatar ErGo_404 | 

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.

avatar Hasgarn | 

@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.

avatar C1rc3@0rc | 

@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.

avatar marc_os | 

@ C1rc3@0rc

« Java [...] souffre de l'heritage du C »

Tiens donc, vous m'en direz tant.

avatar oomu | 

"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.

avatar harisson | 

s/C++ ou Modula/Smalltalk

avatar awk | 

@harisson

APL y a que ça de vrai 😱🙃🙃🙃🖖

avatar C1rc3@0rc | 

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...

avatar IGerard | 

Très bonne nouvelle...

avatar zarghol | 

é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é.

avatar stivjobs | 

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...

avatar C1rc3@0rc | 

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.

avatar Domsware | 

@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.

avatar Domsware | 

@Domsware

Oups. Les doigts ont fourché ! Les décisions intelligentes ont été prises "avant" le passage à l'open source.

avatar C1rc3@0rc | 

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...

avatar tleveque | 

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.

avatar C1rc3@0rc | 

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.

Pages

CONNEXION UTILISATEUR