Google s’implique dans le développement de Swift [MàJ]

Nicolas Furno |

Google a « forké » le projet Swift sur Github, ce qui prouve que le géant de la recherche s’intéresse encore davantage au nouveau langage de développement d’Apple. Dans le jargon informatique, un fork est une nouvelle branche basée sur un projet en général open-source. En clair, Google a repris le langage Swift tel qu’il était et a créé une variante, avec ses propres modifications.

Cliquer pour agrandir
Cliquer pour agrandir

Une telle opération a deux objectifs, pas forcément exclusifs. Elle peut servir, d’une part, à modifier un projet et ensuite proposer à son créateur les modifications sous la forme d’une « pull-request », c'est-à-dire une modification qui doit être validée avant d’être intégrée au projet initial. L’un des responsables de Google a déjà indiqué que c’était pour cette raison que son entreprise avait réalisé le fork.

C’est vrai, mais un fork peut aussi servir à créer un nouveau projet open-source à partir d’une base existante. Google a déjà utilisé ce mécanisme par le passé, et c’était déjà avec Apple : Chrome utilisait dans un premier temps WebKit, le moteur d’affichage de Safari, qui, pour être complet, était lui-même un fork de KHTML, un moteur d’affichage développé pour Linux (lire : 15 ans de WebKit : les origines "machiavéliques" de Safari). Quelques années plus tard, Google avait finalement créé sa propre version, nommée Blink, et même si les deux moteurs restent proches, ils se différencient de plus en plus depuis.

Google est peut-être en train de répéter l’histoire avec Swift. Peut-être qu’une future version d’Android sera compatible avec le langage d’Apple et peut-être qu’à terme, un nouveau langage spécifique à Android fera son apparition, basé sur Swift, mais différent. Après tout, cela fait près de deux ans que des travaux préliminaires ont commencé pour que Swift soit compatible avec Android, la firme de Mountain View est peut-être simplement passée à la vitesse supérieure.

Le fork du projet sur GitHub ne suffit pas à connaître les motivations de Google. Il prouve au moins une chose : l’entreprise est très intéressée par Swift, au point de lui accorder des ressources et d’essayer d’améliorer le langage. Ce n’est pas le seul langage de développement qui l’intéresse ces derniers temps : Kotlin s’est ajouté à Java comme langage pris officiellement en charge depuis la dernière Google I/O.

Cliquer pour agrandir
Cliquer pour agrandir

Google devrait publier rapidement un communiqué qui éclaircira peut-être ses objectifs, nous mettrons à jour notre article en fonction de son contenu.

[MàJ 16/11/2017 14h25] : Google a communiqué sur le sujet, notamment par la voix de Chris Lattner, créateur du langage quand il était chez Apple et qui travaille désormais chez Google. Il a indiqué sur Twitter et à Business Insider que ce fork n’était absolument pas une première mesure pour prendre le contrôle sur le langage ou en créer une nouvelle version pour Android.

Un grand nombre d’ingénieurs travaillent avec Swift chez Google, ne serait-ce que pour créer les apps iOS du groupe, mais aussi pour réaliser des outils en interne. Tous ces développeurs rencontrent de temps en temps des bugs ou ont des suggestions à apporter et c’est pour cette raison que le géant de la recherche a créé sa propre branche. Elle servira à améliorer Swift en parallèle du développement officiel et soumettre ensuite à Apple les modifications.

avatar valcapri | 

En tout cas, c’est une très bonne nouvelle. Swift va certainement intégré les languages accepter en interne chez Google. Et on aura certainement droit à des supers libraires open source en Swift et des nouveaux épisodes de route 85.

avatar C1rc3@0rc | 

Bonne nouvelle, peut etre, si ce n'est pas pour faire comme Microsoft avec Javascript ou HTML et tenter d'imposer sa norme au reste du monde...

Le probleme aussi c'est que Google fait du tres inegal en terme de developpement et ressources dediées. Les langages de Google reçoivent des critiques serieuses et ses objectifs sont assez obscures.

Je sais pas si Google va integrer Swift en interne, mais pourquoi pas, ils ont deja une platée de langage sur le fourneau, donc un de plus...

Mais faut se poser la question par rapport a Android.
En acceptant Kotlin comme alternative a Java, Google a fait preuve d'intelligence. Le langage est simple, adapté et offre ce qu'il faut pour des developers meme debutants. Et puis ça permet d'avoir une porte de sortie le jour ou Oracle remettra une charge pour enquiquiner son monde.

Pourquoi pas Swift pour developper sur Android?
Ça faciliterait la vie des studio qui produisent sur les deux plateformes.
Maintenant, qu'est ce que Swift apporte de mieux par rapport a Kotlin? Faut vraiment poser la question en terme de developpement applicatif.

Et pourquoi Google ne validerait pas Scala comme langage officiel pour Android? D'autant que Swift va continuer d'emprunter a Scala.

En tout cas on va esperer que Swift ne va pas multiplier les versions, deja que le langage manque encore de coherence et souffre de manques incomprehensible (absence de paralellisme et de concurrence deja)

On va voir, mais la plus grande reserve s'impose.

avatar occam | 

@C1rc3@0rc

"pour faire comme Microsoft avec Javascript ou HTML "

« Embrace, extend, and extinguish. »
De sinistre mémoire.

avatar C1rc3@0rc | 

Moais et la mise a jour de l'article va helas dans le mauvais sens:
«Elle servira à améliorer Swift en parallèle du développement officiel et soumettre ensuite à Apple les modifications.»

Il est bien question de modifier Swift hors du processus communautaire etabli puis de soumettre [a] Apple [les] modifications... si on supprime "a" et qu'on remplace "les" par "aux", on a helas le sens qui se profile... Pourquoi Lattner a donc quitté Apple alors que chez Apple il etait l'architecte en chef?

avatar RyDroid | 

> En acceptant Kotlin comme alternative a Java, Google a fait preuve d'intelligence. […] Et puis ça permet d'avoir une porte de sortie le jour ou Oracle remettra une charge pour enquiquiner son monde.

Kotlin est très proche de Java et a été fait pour être compatible avec lui (en terme de bytecode et d'APIs). Il me semble qu'Oracle attaquait sur l'API, or Kotlin utilise la même API pour la bibliothèque standard, donc je doute que Kotlin est un réel intérêt face à Oracle.

avatar C1rc3@0rc | 

Il faut que tu regardes plus en details Kotlin: il permet de compiler hors de Java et de la JVM... en fait il permet meme de produire du code Javascript actuelement et c'est plutot performant.
Le jour ou Google veut changer le moteur d'Android pour virer Java, le code ecrit en Kotlin sera recompilable directement...

L'avantage de Kotlin c'est d'etre compatible avec Java... pour en prendre la place.

avatar RyDroid | 

> Kotlin: il permet de compiler hors de Java et de la JVM

Je n'en avais pas entendu parler.

> en fait il permet meme de produire du code Javascript

Comme plein de langages, comme le C/C++ avec Emscripten et Java avec GWT (Google Web Toolkit).

> Le jour ou Google veut changer le moteur d'Android pour virer Java, le code ecrit en Kotlin sera recompilable directement...

Pas sûr pour autant que ça résolve la question juridique, les APIs appelées dans le code seront toujours les mêmes, même si elles différeraient à l’exécution suite à une phase de transpilation.

> L'avantage de Kotlin c'est d'etre compatible avec Java... pour en prendre la place.

Je doute qu'il arrive à faire éjecter Java. Le C++ est par exemple loin d'avoir fait disparaître le C, idem pour l'Objective-C, même s'ils ont effectivement pris un certain poids.

avatar Lightman | 

@C1rc3@0rc

Tu me l'as enlevé de la bouche : ça me fait penser à Microsoft.
Je ne sais pas si c'est une bonne nouvelle ce fork de Google. Mettre la pagaille dans Swift en proposant plusieurs versions, c'est la garantie de mettre des bâtons dans les roues d'un concurrent.

avatar iGeek07 | 

Je ne pense pas que Google veuille faire un fork de Swift comme elle l'a fait avec WebKit… et même si c'est le cas elle ne va pas le faire maintenant. Pour l'instant je suis sur que c'est juste pour faire des PR et participer à l'effort OpenSource.
(Il ne faut pas oublier que Chris Lattner est chez Google maintenant ?, et je suis sur qu'il voudrait faire des choses intéressantes avec Swift là bas)

Peut être qu'ils veulent utiliser Swift dans Fuschia… l'avenir nous le dira ^^
Mais je ne les vois pas faire plus d'efforts que ça pour mettre Swift dans Android alors qu'ils abandonnent le navire pour faire un nouvel OS.

Il ne faut pas oublier que la première utilisation de Swift chez Google comme chez tout le monde est simplement de faire des applications iOS ?

avatar C1rc3@0rc | 

@ iGeek07

Au dernieres nouvelles Lattner est toujours bien present dans le developpement de Swift, je le vois mal forker pour le faire evoluer separement chez Google.

Le projet Fuschia... oui, bon on va voir s'il en sort quelque chose un jour. Pour l'instant Google a 2 OS qui "marchent": Android et ChromeOS. Ce serait plus simple d'avoir un seul OS avec des interfaces qui sont specifiques, comme le fait Apple, mais Fushia a pas l'air le prendre cette voie et semble surtout un 3eme OS pout IoT... Et il est deja construit avec une platee de langages, donc pourquoi Swift???

«Il ne faut pas oublier que la première utilisation de Swift chez Google comme chez tout le monde est simplement de faire des applications iOS ?»

Ça c'est indeniable, mais le Swift pour faire des application pour les OS d'Apple, c'est le Swift de Xcode... alors a moins que Google n'ait des informations en avant premiere qui indiquerait qu'Apple va abandonner l'exclusivité de Xcode et Mac OS pour produitre des app iOS (ce qui veut dire l'arret e mort de MacOS et des Mac), quel interet de forket Swift???

avatar iGeek07 | 

@C1rc3@0rc

L'intérêt de forker Swift est simplement d'y ajouter des correctifs pour des problèmes qu'ils rencontrent dans leurs applications et/ou proposer des améliorations via Pull Request. (C'est bien le problème quand le même mot veut dire deux choses différentes : je parle de forker dans le sens avoir leur copie où faire leurs modifications avant de contribuer ces modifications au repo central, et non forker et adapter à leurs besoins dans leur coin comme ils ont fait avec WebKit (et Blink))
Donc à mon avis le fork d'aujourd'hui n'est fait que pas leurs développeurs iOS qui veulent aussi participer au niveau du langage et rien de plus.

Quand je parle de Lattner, je ne dis pas qu'il veut faire un fork spécifique à Google, mais bien au contraire qu'il sera un avocat d'une participation de Google à Swift comme membre de de la communauté.

Et enfin quand je parlais d'utiliser Swift dans Fuschia, ce que je veux dire c'est que tout le userland Android est basé sur la machine virtuelle Java, aux antipodes d'une compilation native qu'utilise Swift.
C'est quand on fait un nouvel OS qu'on a l'opportunité unique de se poser la question : sur quelle stack logicielle va-t-on pousser le développement des applications ? Et là ils peuvent regarder Swift comme ils pourraient rester avec des langages JVM (Java/Kotlin).
Après il ne fait pas de doute que l'OS en lui même est certainement développé en C++…

avatar C1rc3@0rc | 

«Quand je parle de Lattner, je ne dis pas qu'il veut faire un fork spécifique à Google, mais bien au contraire qu'il sera un avocat d'une participation de Google à Swift comme membre de de la communauté.»

La procedure de developpement de Swift et pourtant tres claire et ressemble beaucoup au processus de Python: n'importe quel contributeur doit pondre un rapport tres coherent avec une mise en evidence des avantages et tenter au plus de garantir que cela n'enleve pas de coherence au langage, puis en fin de compte, c'est le dictateur bieveillant qui decide si Python integrera cette modification.

L'approche de Google, c'est : on fait evoluer Swift en concurrence, on depossede Apple de son role, et on tente de faire adopter le fork a la place de l'original...

Il y a un tres gros interet strategique et des consequences pour Google par rapport a Apple. Si Google prend la main et impose son fork, Apple va se retrouver avec deux options:
- adopter le fork
- n'utiliser que sa version de Swift.

Si Apple adopte le fork, y a bien des chance que cela fasse sauter le verrou Xcode comme seule solution pour developper nativement pour les OS d'Apple.
Si Apple n'adopte pas le fork, alors Apple va se retrouver en minorité avec un langage maison ne servant qu'a developper des appliccations MacOS/iOS... donc tout le cote universel de Swift s'ecroule.

Et oui, ça peut paraitre extraordinaire pour certain, mais je suis bien en train de defendre Apple et ses interets dans l'histoire.

avatar iGeek07 | 

@C1rc3@0rc

Oulah, attention, le "fork" sur GitHub c'est juste un clone du repository, et tu es obligé de Forker avant de commiter les changements dans ton fork puis de soumettre un pull request auprès du dépôt original pour y intégrer tes changements.
Le "fork" de Google n'est utile que pour pouvoir contribuer au projet (ils ont déjà fait un pull resuest pour intégrer le support de Fuchsia par exemple).

Ils ne sont PAS en train de "forker" Swift comme ils ont Forké WebKit (où là ils sont partis de leur côté comme tu l'évoques).

avatar harisson | 

@iGeek07

Le truc, de mon point de vue, c'est que si il y a des divergences de points de vues techniques (et "accessoirement" business) entre Apple et Google, ce dernier peut très bien créer une branche libre (ou non libre) du langage vu que Chris est maintenant employé Google. Et ça n'empêche pas qu'il pourrait y avoir une branche Google et une branche Apple qui coexistent (pour le meilleur et surtout pour le pire ^_^).

avatar iGeek07 | 

@C1rc3@0rc

Et il y a bien du travail sur un GUI pour Fuschia, ce n'est pas juste un Noyau destiné à l'IoT : https://arstechnica.com/gadgets/2017/05/googles-fuchsia-smartphone-os-dumps-linux-has-a-wild-new-ui/

Je pense personnellement que Fuschia est là pour remplacer Android et ChromeOS à terme, mais la transition sera douce car ils vont pouvoir faire tourner les applications Android dans un premier temps, et proposer des nouvelles API (un peu comme Apple a fait avec Carbon et Cocoa) pour le futur. Du coup les Smartphones de demain tourneront sous Fuschia, mais la plupart des consommateurs ne verront pas la différence entre ce nouvel Os et une nouvelle version d'Android… sauf peut être le jour où ils verront une mise à jour car je pense que ce genre de problème d'Android sera dans la liste des erreurs à ne pas reproduire pour leur prochain OS :)

avatar iGeek07 | 

@C1rc3@0rc

Et voilà le support de Fuchsia : https://github.com/apple/swift/pull/12955 ?

avatar clementgonzalvez | 

Swift a de l’avenir, c’est cool.

avatar Hasgarn | 

Je crois que Google aurait tout intérêt à conserver une proximité avec le Swift d'Apple : les développeurs iOS pourraient passer à Android avec un maximum de facilité voir carrément reprendre des portions de codes iOS et les intégrer à Android (il y a peu de chance mais soyons fou :) ).

avatar leolelego (non vérifié) | 
avatar marc_os | 

Méfiance, méfiance.
Je ne leur fait pas confiance du tout, comme avec webkit je ne doute pas qu'en vérité ils veulent profiter du travail des autres pour au final le rendre incompatible avec l'original. Et au fi bal lieux l'imposer comme avec leur cheval de Troie nommé Chrome !

avatar reborn | 

@marc_os

Pour les devs ios je doute de l'intérêt de suivre un fork Google, sachant que les API iOS ne sont pas open source.

avatar SartMatt | 

"Je ne leur fait pas confiance du tout, comme avec webkit je ne doute pas qu'en vérité ils veulent profiter du travail des autres pour au final le rendre incompatible avec l'original"
En gros, ce qu'avait fait Apple en forkant KHTML pour faire WebKit quoi... Paille, poutre, oeil, tout ça...

avatar occam | 

@SartMatt

"Paille, poutre, oeil, tout ça..."

C'est bien ce que dit @marc_os, non ?

avatar C1rc3@0rc | 

@SartMatt

Si ce n'est que KHTML et Swift sont dans 2 positions totalement opposées (l'un tres marginal et au point mort et l'autre en plein essort, fortement soutenu de toutes parts) et que leur seul point commun c'est d'etre opensource.

Il est probable que sans l'adoption de KHTML comme base pour Webkit, KHTML aurait totalement disparu depuis des annees... On peut - peut etre - reprocher a Apple d'avoir ete un charognard pour KHTML, mais certainement pas un predateur.

avatar harisson | 

@C1rc3@0rc

Apple a cannibalisé KHTML et n'a pas respecté l'esprit du libre quand il en a repris ses bases. Si Apple ne l'avait pas fait, KHTML serait toujours vivant (avec sa "lenteur et ses défauts").

De mon point de vue, le "fork" de Swift par Google permet à Chris Lattner de se réimpliquer dans le développement du langage qu'il a crée chez Apple pour permettre un langage alternatif compatible Android (et accessoirement de justifier son salaire ^_^).

avatar C1rc3@0rc | 

on va me taxer de pro-Apple, mais il faut etre juste et pas se refugier dans des guerres de chapelles: Apple a redonné vie a un projet qui etait mourant, et en a fait un des principaux moteur WEB libre. Si aujourd'hui Webkit est en concurrence directe avec le moteur de Firefox ou celui de Microsoft (je parle pas de Chromium, c'est toujours un fork de Webkit) c'est bien les bases de KHTML qui sont vivantes... sinon KHTML aurait probablement disparu ou serait dans une micro-niche et utilisé par un groupuscule de quelques membres persuadé d'avoir raison contre le reste du monde...

avatar harisson | 

@C1rc3@0rc

Le problème, c'est que KHTML, avant le fork, n'était pas un "projet mourrant" mais un projet libre avec un rythme (très) lent.

Le développeur Apple de l' époque (Don Melton) aurait très bien pu créer un nouveau moteur ex nihilo, mais étant donné les contraintes de temps, il a préféré partir d'un moteur existant. Et Apple a suivi en imposant ses "muscles financiers" face aux petites structures derrière KHTML (libristes et business via TrollTech).

Personnellement, je ne te qualifierais jamais de pro-Apple vu la façon dont tu dé[n^Wf]onces systématiquement Ive, et que ta dernière assertion pourrait très bien s'appliquer... à toi.

avatar iGeek07 | 

@SartMatt

De mémoire Apple avait reversé ses contributions à KHTML dans le projet, et non forké le projet. C'est une grosse différence.

Après comme ils sont arrivés avec un paquet de développeurs dont c'est le boulot quotidien dans un projet où il y avait une dizaine de volontaire avant, ils ont un peu fait un coup d'état, mais ça c'est une autre histoire ^^

avatar SartMatt | 

Ils ont bien forké. Ce qui n'empêche pas de reverser une partie des modifications (rester partiellement synchronisé après un fork, c'est courant, et ça permet aussi de reprendre des modifications faites dans l'original...).

Mais petit à petit, les deux projets ont divergé, et sont devenus incompatibles. Au point qu'aujourd'hui, il y a sans doute plus de boulot pour basculer le KHTML à WebKit (ou inversement) que pour basculer de WebKit à Blink.

avatar SugarWater | 

Le Pixel est il un fork de l'iPhone ?

avatar C1rc3@0rc | 

Google n'a jamais eu acces au source et Apple n'a jamais mis l'iPhone en licence libre...
Donc c'est pas un fork.

CONNEXION UTILISATEUR