IBM ne veut plus participer au développement de Swift
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.
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 » 🤦♂️
@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.
Ah ok... j’étais surprise de la façon dont c’etait formulé 👍
@Nicolas Furno
Donc le tire de l'article est faux. C'est pas grave ça va faire des clics !
@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.
@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...
@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.
Kitura n’a pas eu le succès de Vapor. C’est peut-être un mal pour un bien pour la communauté Swift.
Supporters externes. Des soutiens plutôt.
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.
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 ?
@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...
@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…
@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.
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)
«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]" ?
@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.
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.
@oomu
"Swift ne comble aucun manque"
Dit autrement, il ne sert aucun besoin. Il ne sert à rien. Pile poil.
"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
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...
@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 ?)
@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.
@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.
@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.
@harisson
"Je trouve tes questions & réponses étranges... Qu'est-ce que tu essayes de me démontrer ?"
Rien.
Je suis également étonné par tes questions et réponses.
Je n’ai par exemple jamais vu nulle part qu’utiliser le même langage sur divers OS réduisait les coûts d’une quelconque façon. Utiliser un seul framework multiplateforme, oui, absolument, tel que Electron.
Or la proposition actuelle de Swift n’est aucunement de proposer un framework universel.
Pourtant tu mets cette réduction de coûts en avant comme si c’était une évidence.
Je comprend l’argument de confort par contre. Mais c’est de la flemmardise. Techniquement ça ne tient pour ainsi dire jamais la route...
"Je suis également étonné par tes questions et réponses."
C'est parce que je n'apprécie guère le mépris...
"Je n’ai par exemple jamais vu nulle part qu’utiliser le même langage sur divers OS réduisait les coûts d’une quelconque façon."
Ce qui est sûr, c'est qu'il faut 3 équipes pour faire du dev avec Android + iOS + backend.
"Or la proposition actuelle de Swift n’est aucunement de proposer un framework universel.
La première étape, c'est que le langage soit disponible sur les 4 plateformes principales : Android/Linux, macOS, iOS et Windows.
La deuxième étape, c'est de proposer des APIs/libs/apps (Open Source ou non) sur d'autres plateformes, soit faites en interne chez Apple, soit en valorisant les développeurs tiers communautaires (et business comme IBM dans l'exemple de la news).
"Pourtant tu mets cette réduction de coûts en avant comme si c’était une évidence."
Ce n'est pas une question d'évidence, je n'ai pas écrit "permet"
"Je comprends l’argument de confort par contre. Mais c’est de la flemmardise."
C'est vraiment chiant au quotidien de gérer plusieurs archi soft et hard, ça n'a rien à voir avec de la flemmardise...
@harisson
"C'est parce que je n'apprécie guère le mépris..."
Pas compris.
"Ce qui est sûr, c'est qu'il faut 3 équipes pour faire du dev avec Android + iOS + backend."
Sûr ? Non. J’ai participé à des projets mobilisant 5 équipes, ou 1 équipe.
Le nombre de langage n’a jamais été un critère pour determiner le nombre d’équipes. Ni le nombre de plateformes. La nature des projets, les budgets, les délais, par contre, clairement.
"La première étape, c'est que le langage soit disponible sur les 4 plateformes principales : Android/Linux, macOS, iOS et Windows."
Ça existe. Est-ce si fabuleux ? L’une d’elles est très utilisée. Mais appréciée ? Qualitative ?
C’est une loi informatique universelle. S’il n’existe pas de solution universelle, une apparaîtra naturellement. Puis une deuxième pour combler les manques de la première. Une troisième. Une quatrième. Une cinquième pour unifier les quatre premières et être vraiment universelle. En fin de compte cette solution standardisée universelle n’est qu’une cinquième solution. Il y en aura vite une sixième.
Swift serait quoi ? La douzième solution universelle pas vraiment universelle ? Tu espères vraiment que ce ce sera mieux que ce qui existe déjà ?
Il y en aura une treizième de toute manière.
"C'est vraiment chiant au quotidien de gérer plusieurs archi soft et hard, ça n'a rien à voir avec de la flemmardise..."
Oh oui c’est chiant, à qui le dis-tu. C’est notre job note bien, on l’a choisi je pense. Si, c’est de la flemmardise.
Les solutions universelles ne sont jamais sans compromis, ni universelles. Les compromis affectent tous les acteurs, designers, développeurs, utilisateurs. Certaines solutions affectent moins les développeurs et plus les utilisateurs.
Mais notre job est de réduire les frictions pour les utilisateurs. Pas de les emmerder un maximum pour notre propre confort. On a choisi notre job. Les utilisateurs n’ont pas choisi.
Les développeurs devraient viser plus haut que pourrir la vie des utilisateurs. Ne pas leur ruiner leurs journées serait un objectif fabuleux, et trop rare.
C’est totalement de la flemmardise. C’est totalement ce qui fait que Catalina et la direction choisie par Apple pour les logiciels Mac pue du bec immensément. Electron, Catalyst, ne sont pas pensés et designés pour les utilisateurs, mais pour le bénéfice des éditeurs ou développeurs. Économies et flemmardise. Très souvent uniquement flemmardise lorsqu’on regarde les choses de près. Les économies perçues ne sont que des déplacements de coûts.
Les douze solutions passeront de mode. Mais la quatorzième sera vraiment universelle. La treizième, personne ne l’a jamais aimée de toute façon.
"Pas compris"
"Ça m'éviterait de faire"
Ah. Ça c’est plus intéressant...
"flemmardise"
Swift serait quoi ? La douzième solution universelle pas vraiment universelle ? Tu espères vraiment que ce ce sera mieux que ce qui existe déjà ?
La question n'est pas _"mieux"_, mais d'avoir une possibilité en partant d'une solution tout Swift (plutôt que tout Java ou tout .NET).
"Mais notre job est de réduire les frictions pour les utilisateurs. Pas de les emmerder un maximum pour notre propre confort. On a choisi notre job. Les utilisateurs n’ont pas choisi."
Je trouve ce propos incompréhensible. Notre job, c'est de manager une conception technologique et une implémentation sur un projet défini, pas de "réduire les frictions pour les utilisateurs ou les emmerder".
"Les développeurs devraient viser plus haut que pourrir la vie des utilisateurs. Ne pas leur ruiner leurs journées serait un objectif fabuleux, et trop rare."
Donc, tu n'es pas développeur ?
"C’est totalement de la flemmardise. C’est totalement ce qui fait que Catalina et la direction choisie par Apple pour les logiciels Mac pue du bec immensément. Electron, Catalyst, ne sont pas pensés et designés pour les utilisateurs, mais pour le bénéfice des éditeurs ou développeurs. Économies et flemmardise. Très souvent uniquement flemmardise lorsqu’on regarde les choses de près."
Tu as un problème avec ce terme...
@harisson
""Pas compris""
Toujours pas.
"Donc, tu n'es pas développeur ?"
Plus depuis 4 mois. J’espère ne plus jamais l’être.
Je suis devenu un vieux con. Je crois que j’étais déjà un vieux con il y a 25 ans.
"Tu as un problème avec ce terme..."
Pas du tout. Mais avec les décideurs qui compromettent la qualité (l’expérience utilisateur bien que je n’apprécie pas l’expression), oui, absolument.
@fte
Ça a (et sera) toujours été compliqué les relations entre décideurs et informaticiens, c'est pour ça que de nouveaux métiers (DevOps, UX Design,...) et de nouvelles méthodes de management (scrum entre autres) sont apparus.
"Plus depuis 4 mois. J’espère ne plus jamais l’être."
Ok, j'ai trouvé étonnant que tu imputes la faute aux développeurs sur des problèmes d'UX, alors que ça devrait être celle du décideur.
Après, c'est sûr que quand on a été formé au cycle en V (qui avait aussi des avantages), l'apparition du WebDev et aussi l'écrasante domination de Windows sur le desktop (qui il faut bien le dire en terme d'UX a toujours été limite), il y a de quoi être un poil nostalgique.
Catalyst, c'est parce que le Mac n'a pas réussi à décoller en pdm face aux constructeurs PC (les clients Apple n'ont pas eu le courage de vider leur portefeuille plus que de raison ^_^).
Et Electron, c'est pour satisfaire la logique WebDev/WebApp. J'ai repéré des choses assez cocasses comme l'utilisation d'un "petit bout" d'Electron sur une app parce qu'Apple n'a pas implémenté de pile bluetooth BLE dans macOS.
@harisson
"Ok, j'ai trouvé étonnant que tu imputes la faute aux développeurs sur des problèmes d'UX, alors que ça devrait être celle du décideur."
Il y a beaucoup de choses dont les développeurs sont responsables, qu’ils aient ou non un rôle de décideurs (l’un n’exclu pas l’autre).
Ils sont responsables de leurs actes, ou de leurs inaction.
Par exemple la triche sur les émissions polluantes des diesels. Le code n’a pas pu être pondu et testé sans savoir ou au minimum avoir un indice de ce qui se tramait. Accepter de faire ce codage est une décision qui n’est pas que technique. Qui ne l’est pas du tout. Des développeurs (entre autres) en portent la responsabilité.
Ils ne devraient plus pouvoir exercer. Jamais.
Par exemple ce bug du logiciel de freinage de certaines Toyota. Entré dans le bug tracker. Pas marqué comme bloquant. Au mieux c’est une faute grave de jugement, au pire c’est une équipe entière qui laissé un bug pouvant avoir des conséquences mortelles catégorisé non bloquant voire abaissé de bloquant à non bloquant.
Ils ne devraient plus pouvoir exercer. Jamais.
Tu es développeur ?
Es-tu absolument confortable à l’idée de confier ta vie à un programme écrit par un collègue anonyme ? Sans pouvoir jeter un œil sur le source, ni toi ni personne ?
Je ne l’ai jamais été ni ne le serai jamais.
Plus modestement, les développeurs sont responsables des logiciels merdiques qu’ils mettent entre les mains des gens et qui pourrissent leurs journées. Je porte la responsabilité d’avoir emmerdé des millions de gens avec du soft médiocre. J’ai abandonné ce client important et de longue date parce qu’il me commandait du logiciel médiocre qui emmerdait les gens.
Bref. Du bel ouvrage ne se réalise en général pas avec un language universel adapté à aucun cas spécifique. À chaque plateforme ses usages et guidelines, langages, API, frameworks, spécificités, librairies tierces, communautés... et s’il faut bosser un peu plus pour maîtriser deux ou trois langages et environnements, so be it.
@fte
"Par exemple la triche sur les émissions polluantes des diesels. Le code n’a pas pu être pondu et testé sans savoir ou au minimum avoir un indice de ce qui se tramait. Accepter de faire ce codage est une décision qui n’est pas que technique. Qui ne l’est pas du tout. Des développeurs (entre autres) en portent la responsabilité.
Ils ne devraient plus pouvoir exercer. Jamais."
Perso, je défendrai toujours l'informaticien qui a pondu le code parce que les ordres viennent d'en haut (et de la logique marché)...
Par exemple ce bug du logiciel de freinage de certaines Toyota. Entré dans le bug tracker. Pas marqué comme bloquant. Au mieux c’est une faute grave de jugement, au pire c’est une équipe entière qui laissé un bug pouvant avoir des conséquences mortelles catégorisé non bloquant voire abaissé de bloquant à non bloquant.
Ils ne devraient plus pouvoir exercer. Jamais.
Toyota n'a pas fait de rappel de véhicules pour ces problèmes ? Après, c'est eux qui ont impulsé ce changement de paradigme, ça leur a permis de se hisser au sommet des constructeurs autos...
Et un certain nombre de véhicules subissent des rappels (aucune marque n'est épargnée): https://www.auto-moto.com/techno/securite-techno/rappel-voitures-liste-complete-defauts-incidents-222889.html#item=1
"Es-tu absolument confortable à l’idée de confier ta vie à un programme écrit par un collègue anonyme ? Sans pouvoir jeter un œil sur le source, ni toi ni personne ?"
Ça fait partie de la vie... Il y a beaucoup choses dont on ne connaîtra/maitrisera jamais rien. Je ne vais pas me pointer chez Boeing pour leur demander le code source de leur 737 Max.
Sinon, je ne possède plus de voiture depuis très longtemps, donc je m'en fiche un peu ^_^
"Je porte la responsabilité d’avoir emmerdé des millions de gens avec du soft médiocre. J’ai abandonné ce client important et de longue date parce qu’il me commandait du logiciel médiocre qui emmerdait les gens."
Pourquoi diable endosses-tu cette responsabilité (si le soft est "merdique", c'est parce que le décideur l'a voulu ainsi) et pourquoi avoir continué après ton premier contrat avec ce client (de longue date) ?
"Du bel ouvrage ne se réalise en général pas avec un language universel adapté à aucun cas spécifique. À chaque plateforme ses usages et guidelines, langages, API, frameworks, spécificités, librairies tierces, communautés... et s’il faut bosser un peu plus pour maîtriser deux ou trois langages et environnements, so be it."
C'est un poil trop manichéen pour moi.
Rien n'empêche un langage d'être adapté à plusieurs plateformes même si il n'est pas forcément optimal/parfait.
J'ai fait du Java pendant plus d'une décennie : de l'embarqué, aux serveurs d'entreprises. C'est bien aussi d'avoir la possibilité de développer dans un même langage, on en maîtrise les tenants et les aboutissants (et on peut pallier à certains problèmes de perfs en codant les modules "quivontbien" en c/c++).
Il y a des gens qui font du web sérieusement en Swift ? Des sites à fort trafic reconnus ?
Globalement le marché du web est principalement occupé par PHP, NodeJS, Python, Go, Java JEE, Ruby et .net. Il y a quelques tentatives tierces mais pour le moment rien ne se démarque réellement.
"qui font du web" = Qui propose de services via Internet ? Alors je ne suis pas sûr que les sociétés à fort trafic passent en "prod" une techno si récente que Swift.
Mais, je serais très surpris qu'ils ne testent pas en interne ces différents langages compilés (Go, Rust, Switf ..etc..) rien que pour des raisons de coûts et de sécurité.
Mais, c'est sûr qu'effectivement la communauté étant extrêmement petite comparé aux autres solutions, le choix des bibliothèques beaucoup plus restreintes, cela est forcement beaucoup plus confidentiel. Mais le "sérieusement" oui je le pense. Pour l'instant probablement plus pour des microservice permettant d'évaluer cette solution d'ailleurs.
Amazon propose par exemple une solution intéressante : https://github.com/amzn/smoke-framework