Fuchsia : le mystérieux OS de Google fera tourner des applications développées en Swift
Un langage supplémentaire après Go, Rust et Python

Le , par Patrick Ruiz

131PARTAGES

12  0 
Fuchsia, le nouvel OS de Google dont la vidéo de présentation a filtré sur cette plateforme au mois de mai continue son bout de chemin de façon plus ou moins furtive. Si ce dernier dispose bien d’un dépôt sur une des plateformes de partage open source les plus en vue du moment, il faut bien souligner que la firme de Mountain View ne communique pas trop à son sujet. De récentes publications font cependant état de ce que Google s’intéresse au langage de développement Swift d’Apple.

À la réalité, la firme de Mountain View va au-delà de l’intérêt. À date, il existe un dépôt GitHub pour la prise en charge du langage Swift par le mystérieux système d’exploitation. L’information est de Zack Bowling de Google, l’un des développeurs qui ont travaillé sur le portage du langage Objective-C sur la plateforme Android. Des exemples de code d’applications développées en langage Swift pour l’OS Fuchsia sont fournis. Se référer aux liens dans les sources pour le détail. À noter que Swift vient allonger une liste de langages plus ou moins fournie avec Java, Dart, Go, Python, Rust et bien sûr C/C++ pour le développement d’applications natives, le système d’exploitation lui-même étant principalement développé en C/C++.


Swift est un langage de programmation développé par le géant de la marque à la pomme pour la création d’applications destinées aux systèmes d’exploitation iOS, macOS, tvOS et watchOS. La perspective de pouvoir compiler des applications développées en langage Swift pour la plateforme Fuchsia ne signifie aucunement qu’une application développée pour l’un des OS précités est de facto portable sur ce dernier. Noter à ce propos qu’il faudra retravailler les éléments d’interface utilisateur dont les bases de code sont maintenues sous licence propriétaire par Apple.

Si l’on fait le parallèle avec les PC, la prise en charge d’un nouveau langage de programmation par cet OS en développement ne peut qu’être une bonne chose. Dans ces conditions en effet, la plateforme devient plus attrayante pour les développeurs du fait de la liberté qui leur est accordée d’utiliser le langage avec lequel ils sont le plus à leur aise. Rien n’a pour le moment filtré sur le rôle que Google réserve effectivement à cet OS en gestation dans un écosystème où il retrouve au moins le très répandu Android et Chrome OS. Toutefois, d’après des confidences de développeurs, Fuchsia intègre l’API Mojo de Chromium.

Mojo permet le support d’applications Android sous Chrome OS. De plus, l’API serait le socle sur lequel le support des langages de programmation pris en charge repose. Il semble donc que Fuchsia est destiné à être un pont entre les plateformes logicielles que sont Android et Chrome OS. Vu sous cet angle il y a en effet du boulot. Fuchsia devrait corriger des soucis avec les applications Android qui, dit-on, s’exécutent uniquement via le shell sous Chrome OS. Il ne s’agit que d’hypothèses ; on demeure dans l’attente d’une communication de Google qui viendra lever le mystère qui entoure cet OS.

Sources

The Verge

GitHub

Codes source d’applications Swift pour Fuchsia

Votre avis

Quel commentaire faites-vous de la disponibilité du langage Swift sur Fuchsia ?

Voir aussi

Projet Fuchsia : Google serait en train de développer un nouvel OS destiné à faire tourner des appareils allant des objets connectés aux ordinateurs

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de AoCannaille
Membre émérite https://www.developpez.com
Le 13/04/2018 à 11:46
Citation Envoyé par vayel Voir le message

Concernant l'aspect consommation mémoire/cpu on est en 2018, même l'embarqué le plus modeste aujourd'hui peut faire tourner du java...
Quand je vois les smartphones sortir avec 8GB de ram, je pense que c'est une problématique du passé
Je suis d'accord avec le reste de ton message. Mais pas avec ça.
Quand on voit ce que consomme Android, qui demande autant que windows 7, en n'en faisant moins que windows XP (et en reprennant tous ses défauts), on voit que beaucoup de dev arrivent à la même conclusion que toi, et que du coup font n'importe quoi. Tout explose sans que ce ne soit nécessaire... Android est l'OS le plus catastrophique de l'histoire des OS à succès...
Un peu de rigueur bon sang!
8  0 
Avatar de sergio_is_back
Membre émérite https://www.developpez.com
Le 13/04/2018 à 12:06
Citation Envoyé par MikeRowSoft Voir le message
Si à partir d'une modélisation, UML ou merise ou ALM ou autres il est possible d'obtenir du code source C et C++ quelques soit la complexité "objet/code.source" de celui, alors je veux bien croire qu'il y aura une égalité voir même au moins une équivalence de code source...

Sachant que le compilateur est souvent le même, au stade d'équivalent, le résultat au linkage devrait donc être le même...
Rappelle-moi de ne pas t'embaucher...
7  0 
Avatar de AoCannaille
Membre émérite https://www.developpez.com
Le 13/04/2018 à 14:57
Citation Envoyé par vayel Voir le message

Et puis je vais dire un truc politiquement pas correcte (c'est pas la 1ere fois sur ce forum ), pourquoi économiser la ram, elle est faite pour être utilisé ! Si j'ai 8GB de ram sur mon smartphone c'est pour les exploiter, je préfère que l'applie se charge à 100% en ram et m'offre une meilleur fluidité.

je préfere que mon JV consomme mes 16GB de ram mais réduit les temps de chargement.
Toutafé, je suis d'accord pour une utilisation intensive unique, par exemple ton jeux vidéo. Ou un gros IDE.
Mais déjà :
- Dés que tu atteins les 100%, tu swap. Du coup tu divises les perf par 10 et tu uses prématurément une mémoire dont l'espérence de vie se compte en cycle de lecture/écriture (contrairement à la ram on est d'accord)
- Si tu fais tes efforts de dev, et que tu prend 200Mo au lieu de 400Mo, tu te charges toujours à 100%, donc tu laisse plus de place aux voisins et avant d'user la mémoire.

Et encore, là on parle d'optim basique... à l'origine, la RAM à justement pour objectif de swap le cache processeur... En C++ on peut encore faire ce genre d'optim, en java on déborde du cache processeur, de la ram, et des fois même de la swap...
5  0 
Avatar de sergio_is_back
Membre émérite https://www.developpez.com
Le 13/04/2018 à 15:26
Citation Envoyé par vayel Voir le message

Et puis je vais dire un truc politiquement pas correcte (c'est pas la 1ere fois sur ce forum ), pourquoi économiser la ram, elle est faite pour être utilisé ! Si j'ai 8GB de ram sur mon smartphone c'est pour les exploiter, je préfère que l'applie se charge à 100% en ram et m'offre une meilleur fluidité.

je préfere que mon JV consomme mes 16GB de ram mais réduit les temps de chargement.
Y'a le pour et le contre.

Si tu n'utilise "qu'une seule" (entre guillemets) application à la limite rien n’empêche de monopoliser le maximum de RAM dispo (charger toutes les bibliothèques et tout ce qui
peut lui être utile d'un seul coup) elle sera d'autant plus réactive

Le problème est que sur les OS multi-utilisateurs/multi taches lorsque l'on passe d'une tache à l'autre ça va entrainer du SWAP et donc fatalement finir par dégrader les performances
5  0 
Avatar de SimonDecoline
Membre expert https://www.developpez.com
Le 13/04/2018 à 15:18
Citation Envoyé par vayel Voir le message

Et puis je vais dire un truc politiquement pas correcte (c'est pas la 1ere fois sur ce forum ), pourquoi économiser la ram, elle est faite pour être utilisé ! Si j'ai 8GB de ram sur mon smartphone c'est pour les exploiter, je préfère que l'applie se charge à 100% en ram et m'offre une meilleur fluidité.
Tout à fait, et si les applis étaient bien codées, comment on ferait pour saturer la ram, vendre des iphones à un smic obsolètes en deux an et gaspiller les ressources de la planète inutilement ?
4  0 
Avatar de stef-13013
Membre actif https://www.developpez.com
Le 13/04/2018 à 9:24
Bon la, en même temps, si on regarde rapidement juste la portion de code du post, cela ressemble plus à du "C++ as better C"
qu'à du C++ pur et dur (classes, template, STL, ...)

Pourquoi pas...
2  0 
Avatar de Aurelien.Regat-Barrel
Expert éminent sénior https://www.developpez.com
Le 15/04/2018 à 20:39
Citation Envoyé par vayel Voir le message
on peut faire un kernel avec quasi n'importe quel langage...
Ca me rappelle cette citation :

Y'a deux types de développeurs kernel : ceux qui disent qu'il y a 36 façons de faire les choses, et ceux qui expliquent pourquoi les 35 autres ne fonctionnent pas.
Citation Envoyé par vayel Voir le message
Pour ma part j'opterais pour du tous dynamique, j'aime les structures flexible comme les listes doublement chainé par exemple plus pratique qu'un tableau statique.
L’avantage je dirais c'est moins de bug donc moins "d'écrans bleu", surtout si il font des try catch pass qui est préférable si on cherche la stabilité à un exit 1
Le mécanisme try...catch de C++ ne fonctionne pas "out of the box" en mode noyau. Pareil pour l'allocation dynamique : tout cela doit être recodé à la main. Et y'a pas d'exit non plus : le kernel étant à la base de tout, il ne peut pas rendre la main à quelqu'un d'autre. Et pour les listes chaînées, c'est sympa oui mais c'est une catastrophe en terme de performance autant à l'allocation / destruction (l'alloc dynamique coute cher!) qu'au parcours car elles ne sont pas "sympathiques" vis à vis du hardware (data prefetching).

Quant à Python ou "n'importe quel langage", faut déjà pouvoir produire un binaire exécutable qui ne soit lié à aucun runtime ! (pour rappel Python s'appuie sur un interpréteur développé en C).

Sinon, à mi-chemin entre le vrai kernel et l'application C++ il y a includeOS, un "unikernel" C++ : https://github.com/hioa-cs/IncludeOS
2  0 
Avatar de hl037
Membre du Club https://www.developpez.com
Le 20/04/2018 à 20:07
...On peut aussi faire du C++ sans allocation dynamique...
Pour ma part, entre C et C++, la question ne se pose pas trop : C++.
D'abord, c'est (à quelques différences sémantiques prêt) presque un superset du C. Ensuite, C++ atteint un niveau de fiabilité côté les compilateurs assez proche du C.
Et puis... On n'est pas non plus obligé d'accepter TOUTES les fonctionnalité de C++, par exemple, on peut interdire l'allocation dynamique, ainsi que certaines syntaxes obscures. Par contre, les templates, ainsi que la possibilité de redéfinir les opérateurs peuvent s'avérer vachement pratique côté lisibilité et facilité / vitesse de développement, et permettent parfois une analyse statique plus fine. ...On a aussi accès à un héritage pris en charge par le langage et éviter ainsi des hack avec les structures du C...
1  0 
Avatar de UndeadangerousK
Membre habitué https://www.developpez.com
Le 03/01/2018 à 10:05
Même si green OS (comme Android, avant leur rachat en 2005) n'a pas été spécifiquement initié par Google, il reste très orienté Google. On pourrait presque dire que c'est aussi un OS Google.. Même s'il n'est pas maintenu. Du coup, ca fait 4 OS a leur actif.
0  0 
Avatar de nhugodot
Membre régulier https://www.developpez.com
Le 07/01/2018 à 11:49
Java n'est sûrement pas supporté nativement par Fuschia: c'est justement parce que Java a été racheté par Oracle via le rachat de Sun que Google, poursuivi, harcelé, par Oracle, veut s'en défaire, comme il s'est défait de GWT, et a donc créé Go et Dart (hop, Java et Javascript à la poubelle, une page se tourne... idem C et C++ remplacés par Rust autant que possible: bienvenue dans le 21e siècle)

Quant à Swift, ce serait beau... On aurait ainsi Dart (avec Flutter) et Swift capables de tourner sur 2 OS... Mais comme alors Google aurait aussi accepté Swift sur Android pour nous faciliter la tâche, je ne vois pas pourquoi il l'accepte sur Fuschia et pas Android? Donc là aussi, j'ai un gros doute...
0  0 
Contacter le responsable de la rubrique Accueil

Partenaire : Hébergement Web