IBM ne veut plus participer au développement de Swift

Nicolas Furno |

Quand Apple a présenté Swift, son nouveau langage de développement, l’entreprise a bien insisté sur son caractère open-source. Son développement ne devait pas se limiter aux seuls appareils pommés et pour prouver son sérieux en la matière, le constructeur avait lancé un groupe de travail pour faire de Swift une solution viable sur le serveur. IBM faisait partie des gros acteurs invités sur cette initiative, mais l’entreprise a annoncé son souhait de s’en retirer.

Après une évaluation en interne, IBM a choisi d’abandonner son travail sur Swift en 2020. Ses deux employés qui co-dirigeaient le groupe de travail sur les serveurs vont se retirer, et IBM va aussi passer la main à la communauté pour l’image Docker officielle de Swift qu’elle gérait jusque-là. Pas un mot pour le moment sur l’avenir de Kitura, un framework qui permettait de créer des applications serveurs en Swift. On imagine bien que son développement ne sera plus maintenu, mais est-ce qu’IBM offrira une solution pour transférer le projet à la communauté open-source ?

C’est un coup dur pour Swift sur le serveur, même si on ne connaît pas les motivations d’IBM. Est-ce qu’Apple a montré de son côté aussi un désintérêt pour son usage sur les serveurs ? Le langage va-t-il se recentrer sur son usage dominant depuis sa création, à savoir la conception d’apps pour iOS, macOS et les autres variantes conçues par la firme de Cupertino ?

La décision d’IBM seule ne permet sans doute pas de répondre à ces questions, mais le langage d’Apple perd à tout le moins l’un de ses plus gros soutiens externes.

Source
Tags
avatar SyMich | 

L’un des plus gros supporters externes... si ils avaient 2 salariés mobilisés sur le sujet (peut-être même pas à plein temps), je n’ose imaginer ce que font les « petits supporters » 🤦‍♂️

avatar Nicolas Furno | 

@SyMich

Pardon, c'est une erreur de ma part. Ces deux employés étaient à la tête du groupe de travail, il y en avait sans doute bien d'autres qui travaillaient sur Swift.

avatar SyMich | 

Ah ok... j’étais surprise de la façon dont c’etait formulé 👍

avatar Benitochoco | 

@Nicolas Furno

Donc le tire de l'article est faux. C'est pas grave ça va faire des clics !

avatar Nicolas Furno | 

@Benitochoco

Non, IBM annonce se retirer de tout ce qui concerne Swift. Cela concerne les deux employés à la tête du groupe, mais aussi tous ceux qui travaillent sur Swift.

avatar redchou | 

@SyMich

Deux employés qui co-dirigeait un groupe de travail... Donc il ne devait pas être que deux..

Après le maintien d’un langage ne nécessite pas 10 000 personnes...
La communauté qui gère le langage swift ne dépasse pas 1 000 personnes...

avatar fte | 

@redchou

"Après le maintien d’un langage ne nécessite pas 10 000 personnes..."

D’un langage, non, mais ici l’ambition n’était pas que le langage mais une palette d’outils divers dont server side.

La concurrence est forte, dynamique, établie, robuste, stable... il y a d’autres nouveaux acteurs beaucoup plus intéressants... et des communautés diverses beaucoup plus nombreuses et actives.

L’outil pour l’outil n’est pas très intéressant et stratégique. L’outil pour faire des trucs l’est beaucoup plus.

avatar Florent Morin | 

Kitura n’a pas eu le succès de Vapor. C’est peut-être un mal pour un bien pour la communauté Swift.

avatar Adrienhb | 

Supporters externes. Des soutiens plutôt.

avatar ben67fr | 

Pour comprendre son retrait, il ne faut pas oublier qu’IBM a racheté RedHat il y a 6 mois. La partie Open Source d’IBM migre en ce moment vers RedHat, pendant qu’IBM intègre les solutions RedHat à son catalogue infra.

avatar Chamalo | 

Désolé de mon ignorance mais ça veut dire quoi : Swift sur les serveurs ?
On parle de language la ou d’application qui tournent sur des serveurs ?

avatar redchou | 

@Chamalo

L’inverse serait swift sur iPhone, Mac, PC, etc...

Une Application est souvent composé d’un Front-End et d’un Back-End...

Le Front-End est l’interface que l’utilisateur va manipuler, site web, application iOS... Le Back-End est l’application serveur, qui va renvoyé des infos à l’application, les dernières news, leur contenu, pour l’app macg par exemple..

Du coup quand on parle de swift sur serveur, on parle de développer des applications qui tournent sur des serveurs dans des centres de données, en opposition aux applications qui tournent sur iPhone, Mac, etc...

avatar Ded77 | 

@Chamalo

On parle d’application écrite en Swift qui tourne sur un serveur (et pas un client comme un iPhone par exemple). Ce peut être un site web, ou simplement une API exposée à un client.

Ces applications sont généralement écrites en Java, PHP, JavaScript…

avatar fte | 

@Ded77

"Ces applications sont généralement écrites en Java, PHP, JavaScript…"

Python, Ruby, C#, Go, Scala...

Surtout, pour des frameworks backend. Pour un écosystème de librairies. Pour une communauté où trouver support et réponses.

Swift n’a rien de tout ça, ou presque rien, comparativement.

avatar Manu | 

Aujourd’hui qui dit serveur dit Cloud. Niveau développement c’est docker/kubernetes et les langages de dev il y en a déjà pas mal du tout. SWIFT bien qu’open source est très coloré Apple. Il n’etait ni ne sera pas vu comme un langage de dev important sur ce type de plateforme(docker/k8s)

avatar BLM | 

«faire de Swift une solution viable sur LE serveur […] coup dur pour Swift sur LE serveur»
Pourquoi "le" ? Il s'agit d'un serveur particulier ?
N'est ce pas plutôt "solution viable sur serveur[s] / coup dur pour Swift sur serveur[s]" ?

avatar fte | 

@BLM

"Pourquoi "le" ? Il s'agit d'un serveur particulier ?"

Non non, pas un serveur particulier. Juste un serveur anonyme. Mais il est du coup assez célèbre parce que c’est le serveur qui fait backend Swift.

Tu n’imaginais pas que c’était une solution largement déployée et très populaire ? Si ? Naaa.

avatar oomu | 

bah, du C et du Fortran, y a que ça de vrai ! :)

-
Swift ne comble aucun manque dans un univers de python, js, et un million de langage par an lancée par des entreprises internet qui s'ennuient...

Je suppose aussi qu'avec la fusion de Redhat, IBM n'a pas vraiment d'intérêt à perdre du temps dans un langage de plus.

Redhat fournit tellement d'outils et langages.

avatar fte | 

@oomu

"Swift ne comble aucun manque"

Dit autrement, il ne sert aucun besoin. Il ne sert à rien. Pile poil.

avatar amnesic | 

"Swift ne comble aucun manque dans un univers de python, js, et un million de langage par an lancée par des entreprises internet qui s'ennuient..."

Aucun manque ? Je serais plus nuancé. Ce n'est pas juste un caprice d'informaticien tous ces nouveaux langages utilisés côté serveur (Swift, Go, Rust, Scala ..etc...). C'est souvent pour des raisons économiques et de productivité qu'il commence à être utilisé :

- Plus rapidité et plus économe en mémoire (= réduction des factures d'infrastructure)
- Accès mémoire sécurisé par défaut, prévisible et déterministe.
..etc..

Mais pour revenir à Swift, c'est un langage très jeune, mais la progression de l'écosystème de Vapor est intéressant à suivre je trouve.

Pour ceux qui voudraient en découvrir un peu plus des avancées, il y a des conférences intéressantes à visionner ici : https://www.serversideswift.info/2019/videos

avatar harisson | 

C'est quand même bien dommage, Apple devrait faire un peu plus d'efforts pour valoriser son langage hors de son éco-système...

avatar fte | 

@harisson

Pourquoi ?

Je veux dire, quel serait l’avantage pour Apple ?

Ou pour les devs en général, ou iOS en particulier ? (Reste-t-il des devs macOS ?)

avatar harisson | 

@fte

Ça réduirait les coûts de développement pour les acteurs tiers sur mobile.

Ça permettrait d'avoir une architecture software homogène (surtout côté client-serveur) dans des environnements matériels hétérogènes (on peut maintenant faire du python sur quasi n'importe quoi, du micro-contrôleur au HPC par exemple).

Ça m'éviterait de faire de la XR via .NET/C# et Unity, du Java/Kotlin sous Android, du PHP/Javascript pour du web, du Python pour l'IA (ou du .NET/Java pour des apps d'entreprises).

Et éventuellement de lui décoller cette étiquette d'entreprise à la logique un peu fermée (et chère) qu'on lui colle, amha, à juste titre.

avatar fte | 

@harisson

"Ça réduirait les coûts de développement pour les acteurs tiers sur mobile."

Ah ? Comment ? Combien ? Pour quels projets ?

"Ça permettrait d'avoir une architecture software homogène (surtout côté client-serveur) dans des environnements matériels hétérogènes (on peut maintenant faire du python sur quasi n'importe quoi, du micro-contrôleur au HPC par exemple)."

C’est déjà possible hors iOS. iOS plateforme minoritaire.

"Ça m'éviterait de faire"

Ah. Ça c’est plus intéressant...

"de la XR via .NET/C# et Unity, du Java/Kotlin sous Android, du PHP/Javascript pour du web, du Python pour l'IA (ou du .NET/Java pour des apps d'entreprises)."

Pour quels bénéfices concrets, hormis ton confort ou préférences ?

"Et éventuellement de lui décoller cette étiquette d'entreprise à la logique un peu fermée (et chère) qu'on lui colle, amha, à juste titre."

Ça, il faudrait beaucoup plus qu’un Swift populaire côté serveur. Beaucoup beaucoup plus.

avatar harisson | 

@fte

Je trouve tes questions & réponses étranges... Qu'est-ce que tu essayes de me démontrer ?

C'est coûteux d'avoir deux équipes, une pour iOS et une pour Android (surtout sur des petites structures non GAFAM).

Multiplier les langages, c'est pénible et j'aurais préféré faire tout en Swift en partant d'iOS (au final, c'est souvent l'inverse qui se passe).

Apple a déjà une longue expérience avec les langages informatiques via Objective-C, entre autres, qui n'est resté cantonné qu'aux plateformes Mac, OpenStep et GNUStep.

Quand je vois l'attitude d'Apple avec les autres "langages historiques" exploitables sur macOS, je me pose des questions : Java qui n'est plus intégré (ça n'est pas trop grave vu que c'est l'hydre Oracle derrière maintenant), Applescript viré, Python/Ruby/Perl qui ne sont plus fournis par défaut, ainsi que la tentative d'adapter les APIs d'iOS à macOS, je me dis qu'il y a un truc qui cloche*, surtout que Swift n'est pas, amha, correctement soutenu par Apple face aux autres langages en expansion (de mon point de vue, l'abandon d'IBM est un échec pour Apple).

* Perso, j'impute ça à Timmy et à sa mauvaise gestion technologique software en interne, et b2b-tech en externe.

Pages

CONNEXION UTILISATEUR