Vala, le futur

Il y a quelques jours j’ai lu ce post, qui suggérait d’utiliser Rust dans le développement d’applications et de bibliothèques GNOME. Dans ce billet, l’auteur, qui a utilisé et utilise Vala, dit qu’il aime ce langage, mais qu’un de ces principaux problèmes est qu’il est très dur à déboguer. Et je confirme, Vala est une horreur à déboguer : le compilateur génère parfois des erreurs dans le code C alors qu’il ne devrait pas, il n’y a pas de débogueur « officiel », et donc on se débrouille avec GDB et/ou Nemiver en mettant des points d’arrêts sur les noms des fonctions en C. Au final j’utilise plus souvent la technique des print un peu partout dans mon code, pour voir à quel niveau ça plante et quelle tête ont les différentes variables à ce moment-là. Bref, ça fait des sorties de trois kilomètres de long, c’est sale et pas super efficace…

En lisant les commentaires, on voit que ce n’est pas le seul reproche qui est fait à Vala : il est difficile d’être sûr que la prochaine version du compilateur sera compatible avec l’actuelle. Le projet n’a jamais atteint de version stable depuis sa création, il y a environ dix ans.

J’ai moi-même des reproches à faire à l’écosystème Vala (même si j’adore ce langage). Pour commencer, l’installation de bibliothèques est très compliqué. Si on a une distribution Linux dérivé de Debian ou de Fedora, il ne devrait pas y avoir trop de problèmes, mais dès qu’on part dans quelque chose d’un peu plus exotique, voir sur du Windows ou du Mac OS X, ça devient très problématique. Essayez de compiler VSGI sous Windows, vous allez hurler : une fois que vous aurez remplacer les parties du code ne fonctionnant que sous UNIX-likes par des versions plus mutiplateformes, vous devrez installer les différentes dépendances. Prenons par exemple la bibliothèque FastCGI utilisé par ce projet : le fichier .vapi est fourni, mais pour trouver le fichier .h et la DLL qui correspond, c’est une autre histoire !

Un autre problème : c’est la documentation. Valadoc.org pourrait être un million de fois mieux fait. Il y a trop de JavaScript inutile partout, certaines parties n’ont pas la moindre petite explication (ou alors c’est la documentation de l’API correspondante en C, avec les noms de méthode en C…), depuis quelque temps la recherche ne marche plus (heureusement un miroir avec une recherche fonctionelle a été mis en place) et les liens ne valent rien : essayer par exemple d’accéder à la documentation du type string, avec ce lien http://www.valadate.org:8000/#!api=glib-2.0/string, vous allez arriver sur la page d’accueil à tous les coups ! Il n’y a pas d’API, alors que ça pourrait être très utile pour, par exemple, Valhalla. Ajouter un paquet à l’air assez complexe (il faut passer par GitHub, puis attendre que le site soit mis à jour et surtout ça à l’air d’être un mix de différents types de fichiers…), lors qu’un formulaire avec envoi de fichiers du code source (ou juste un lien vers un dépôt Git/autre) puis une validation par l’administrateur du site me semble bien mieux (plus logique, plus simple pour tout le monde). L’outil pour générer la documentation en local n’est aussi disponible que sous Debian et dérivé, et je n’ai pas réussi à le compiler sous Fedora (je n’ai même pas tenté Windows, vous imaginez l’horreur que ça doit être). Et enfin, même si ça n’est pas très grave, c’est un peu un comble, car le site n’est pas écrit en Vala, mais en PHP ! Et on sait faire des sites en Vala : il suffit d’utiliser Valum, Valse ou même quelque chose de plus bas niveau comme LibSoup !

Il y a aussi un manque de ressource pour les vrais débutants (tutoriels pour ceux qui ont déjà programmé, et pas toujours très à jour). Et si on a un problème on doit en général passer par la mailing-list, ce qui ne me donne pas vraiment l’impression d’être en 2016.

Pour résumer, Vala : - Est une horreur à déboguer ; - Est instable (pas sûr que les différentes versions seront compatibles) ; - N’a pas de moyen simple et multiplateforme d’installer des bibliothèques (à l’instar de pip, gem, npm, cargo et tant d’autres) ; - A une documentation pour le moins… pas terrible ; - Est réservé aux personnes ayant déjà une certaine expérience en programmation.

La mort de Vala ?

À ce stade de la réflexion, on pourrait se dire qu’il vaut mieux laisser mourrir Vala, et passer progressivement à Rust comme l’a suggéré Alberto Ruiz sur son blog. J’ai juste envie de répondre : non. Vala est fantastique : il représente un gain de temps énorme (quand on a pas à déboguer le code), et il allie une syntaxe très agréable, compréhensible et haut-niveau (et il ne l’est pas seulement dans la syntaxe, il l’est réellement), tout en gardant une vitesse d’exécution exceptionnelle et il permet de générer du code réutilisable dans n’importe quel autre langage grâce à GObject. À l’heure de l’Internet des Objets, à l’heure où des applications plus intelligentes que jamais doivent tenir dans des grille-pains, prendre peu de placer dans la mémoire et être rapide est un grand avantage pour un langage, mais si en plus il permet de développer des applications complexes (IA, réseau, etc) et peu de temps et de lignes, ce langage peut être réellement utile. Vala est resté cantonné à quelques applications GNOME, mais il pourrait tourner n’importe où : du plus puissant serveur Linux, au PC Windows, en passant par l’iPhone, la tablette Android ou la carte Arduino. En se débrouillant bien, je suis sûr qu’il y a moyen de créer des bibliothèques qui supportent ses plateformes en ne fournissant qu’une seule interface de développement, grâce à Vala.

Mais bon, Rust peut surement en faire autant, alors pourquoi garder Vala ? Déjà parce que même si le langage n’est pas massivement utilisé, un certains nombre de logiciels, peut-être que vous utilisez sont écrits en Vala, et si on abandonne le langage, je ne pense pas que les développeurs aient envie de tout réécrire en Rust (ou autre) depuis zéro. Ensuite, c’est très subjectif, mais je trouve que Vala a une syntaxe très élégante, surtout si on respecte les conventions de style d’elementary OS. Et enfin, si vous voulez créer une bibliothèque utilisable à peu près dans n’importe quel autre langage, Vala est surement la meilleure solution, grâce à GObject et la syntaxe qui permet d’être très productif par rapport au C.

Abandonner Vala ne semble donc pas vraiment possible. Seuleument le projet est en manque de nouveaux contributeurs, les principaux développeurs n’ayant plus le temps de s’en occuper. Et je pense que si le projet n’attire pas, c’est parce que les outils utilisés sont trop old-schools : cgit et Bugzilla, ça donne pas trop envie de contribuer. Ce n’est pas le workflow auquel la plupart des développeurs sont maintenant habitués avec Github/Gitlab. Et si Vala était hébergé sur un de ces deux services, j’aurais, personnellement, déjà contribué. Ensuite il n’y a pas à ma connaissance d’intégration continue, ce qui semble un peu problématique pour ce genre de projet…

Comment améliorer les choses ?

Pour améliorer les choses, il faudrait :

  • Améliorer les outils, ce qui passe par :
    • Avoir un npm-like. Je me suis lancé dans la création de poulp, arteymix (le principal développeur de Valum) avait commencé à réfléchir à drakkar, mais le projet est encore au stade de la spécification. On peut déjà utiliser des sous-modules Git et Meson pour se faciliter un peu la tâche, mais ce n’est pas idéal ;
    • Avoir un vrai IDE. Il y a plein d’éditeurs de texte qui supportent plus ou moins bien Vala, mais en général on se limite à de la coloration syntaxique. GNOME Builder avait l’air plutôt intéressant, mais le support de Vala n’a pas l’air d’être une priorité, et c’est pas encore ça. J’ai écrit Valhalla (un plugin pour Atom pour aider à écrire du Vala), mais il manque encore beaucoup de choses pour arriver à quelque chose d’utilisable et surtout d’utile au quotidien. Il y a aussi elementary-ide, mais il est lui aussi en cours de développement, et niveau multiplateforme je ne suis pas sûr que ça soit trop ça…
    • Faciliter le débogage, mais ça se range aussi dans la catégorie IDE.
  • Avoir des bibliothèques intéréssantes pour à peu près tout : sites web, GUI, machine learning, etc ;
  • Avoir une documentation meilleure que l’actuelle. Ça passe par :
    • Réécrire le site de Valadoc depuis zéro et refaire tout ce qui ne va pas (voir plus haut), en ajoutant la possibilité de modifier les descriptions via une interface simple ;
    • Rendre l’outil de génération de documentation locale (la commande valadoc) multiplateforme et installable facilement ;
    • Avoir des tutoriels à jour et que même des grands débutants en programmation peuvent aborder, des exemples pour les différentes bibliothèques, des guides pas-à-pas, bref des ressources pour ne jamais rester bloqué face à une bibliothèque qu’on ne sait pas utiliser et être obligé d’aller chercher la documentation C.

Déjà, si on arrive à ça, Vala deviendra mille fois plus utilisable. Ensuite j’ai quelques idées d’améliorations sympa à apporter au projet en lui-même :

  • Déjà, fixer un maximum de bugs, surtout que certains trainent depuis plusieurs années maintenant ;
  • Au niveau du langage, pourvoir définir des opérateurs personnalisés serait un gros plus. Et avoir ce qui s’appelle en C# des méthodes d’extension aussi (c’est juste des idées qui me passe par la tête et je suis sûr qu’il y aurait plein de choses à ajouter) ;
  • Ensuite il faudrait « moderniser » le développement : installer une instance de Gitlab et mettre en place de la CI ça doit être faisable, non ? Bon en fait, GNOME veut garder son workflow actuel (je ne sais pas pourquoi) et donc à moins de forker le projet, ça risque d’être compliqué…
  • Rendre Vala vraiment multiplateforme : pouvoir compiler pour différentes plateformes et pouvoir transpiler vers plusieurs langages : on passe une option au compilateur et il nous génère le code Swift de notre application qu’on pourra ensuite compiler pour iOS, avec une autre option il génère du JavaScript près à être utilisé dans un navigateur, ou bien une application écrite en Rust (un peu comme ce que fait Haxe). Mais bon, arriver à ça va être très compliqué, même si le langage deviendrait alors super intéressant. On peut déjà avancer vers plus de multiplateforme en facilitant le développement et la compilation sous Windows et Mac OS X.

Et bien sûr, communiquer, parler du projet, sans quoi même s’il est génial, personne n’en entendra parler.

Conclusion

On peut faire quelque chose de génial de Vala, il faut juste le faire. En écrivant cet article, je me suis rendu compte qu’il fallait que je me concentre sur poulp et Valhalla, car parmi tous mes projets ce sont ces deux-là qui sont les plus importants pour le futur de Vala.

Je ne dis pas non plus qu’utiliser Rust pour GNOME est une mauvaise idée : au contraire si il permet de faire gagner du temps et de sécuriser certaines parties du code qui en ont besoin, c’est très bien. Au final, passer du tout C qu’on a un peu actuellement dans GNOME vers du C + Vala + Rust, respectivement pour ce qui peut rester en C, ce qui est utile de passer à du plus haut niveau (pour gagner du temps) et ce qui a besoin d’être « sécurisé ».

Et juste un petit mot à propos de la série d’article sur Valhalla : le dernier article n’arrivera pas tout de suite parce que le module de documentation risque de pas mal changer dans les prochaines versions. J’attendrai donc d’avoir un fonctionnement plus stable pour en parler.