Connexion
Abonnez-vous

Microsoft va rendre le TypeScript « 10x plus rapide »

Le 14 mars à 07h52

Sur son blog dédié aux développeurs, Microsoft a annoncé que le TypeScript (un surensemble de JavaScript) avait un problème de performances. Sa base en JavaScript ne lui permet pas une mise à l’échelle : les performances ne suivent pas la taille des projets. L’éditeur travaillait donc à rendre le compilateur et ses outils natifs.

Microsoft a choisi le langage Go pour ce portage natif. Le projet est en cours, mais les premiers résultats semblent à la hauteur des attentes avec un temps de compilation moyen divisé par 10. Des gains très élevés ont également été observés dans le chargement des projets, la réactivité dans les éditeurs ou encore dans la consommation de mémoire vive, en moyenne divisée par deux.

L’arrivée de cette version native n’est pas pour tout de suite. La prochaine révision sera la 5.9, qui sera disponible « bientôt ». Après quoi, Microsoft passera à la branche 6.0, qui « introduira quelques dépréciations et ruptures pour s'aligner sur la base de code natif à venir ». Ce n’est que lorsqu’une parité « suffisante » aura été atteinte avec le TypeScript actuel que la version native sera lancée, en tant que TypeScript 7.0.

Le choix du Go peut bien sûr intriguer : Microsoft semblait ne jurer que par le Rust depuis quelques années. Sur X, le choix interroge. Comme le signale Analytics India Mag, Ryan Cavanaugh, responsable du développement de TypeScript, est venu expliquer ce choix sur Reddit.

Selon le développeur, c’est essentiellement une question de contraintes, dont la principale était la portabilité. Toutes les approches tentées auraient présenté des « compromis inacceptables (performances, ergonomie, etc.) », dont l’obligation d’écrire son propre ramasse-miettes (garbage collector). L’équipe se serait parfois approchée d’un résultat correct, mais au prix de nombreux pans de code non sécurisés. En définitive, un portage vers Rust aurait nécessité des années et aurait abouti à une version incompatible « que personne n’aurait pu utiliser ».

Son de cloche identique pour Anders Hejlsberg, auteur du billet de Microsoft et créateur de TypeScript, dans une interview donnée à la chaine Michigan TypeScript sur YouTube.

Le 14 mars à 07h52

Commentaires (11)

votre avatar
Rust aurait sûrement permis de meilleures performances. Mais sur un projet de ce type je pense également que la portabilité est plus importante, surtout s'il y a tout de même un gain (non négligeable) en performances.

Clairement je trouve Go bien plus adapté pour nombre d'outils de dev du quotidien. Et si ceux-ci sont en OSS, c'est également faciliter la prise en main de leur code base (Go reste bien plus accessible que Rust).
votre avatar
Ils ont fait tout un billet expliquant pourquoi pas Rust. En gros l’argument principal de mémoire c’est qu’ils vont continuer à maintenir la codebase actuelle et la nouvelle codebase en go donc ils veulent avoir deux codebase qui se ressemblent et donc ça implique d’utiliser un langage avec des paradigmes pas trop différents, qui ne demandent pas de penser le code différemment donc (ce que Rust fait indiscutablement).
votre avatar
Ça tient la route comme argument :)
votre avatar
Anders Hejlsberg, une sacrée pointure ce danois : Turbo Pascal, Delphi, C#, TypeScript !
votre avatar
Heu, je ne fais pas de Go, mais il me semble qu'il permet de paralléliser massivement.

Dans ce cas, ce n'est pas forcément une optimisation pure (de celles de vrais codeurs assembleur avec la pilosité aggravée qui jouent leur vie sur un octet... que dis-je... un bit) mais peut-être le recours à une parallélisation massive. Qui requiert moins d'efforts de dev dans la conception ou la reprise de celle-ci.

Quelqu'un sait ?
votre avatar
Le compilateur "historique" de typescript est "lent" (par rapport au nouveau), car il est écrit en typescript... qui nécessite donc nodejs pour fonctionner (donc un interpréteur javascript).

L'idée de Microsoft a donc été d'améliorer les choses en passant sur un langage compilé sans VM (pour gagner du temps au démarrage du programme). Cela a donc exclu C# (l'AOT n'est pas toujours la panacée).

Ensuite, le compilateur typescript étant complexe (c'est un compilateur !), l'idée était de trouver un langage proche niveau paradigme. C'est le GO qui a gagné.

Go, contrairement à Rust, dispose d'un ramasse-miette. Cela permet de traduire beaucoup plus facilement le compilateur d'un langage à l'autre. Avec Rust, il aurait fallu le réécrire entièrement à cause du paradigme de gestion de la mémoire radicalement différent.

Une réécriture complète avec changement de paradigme aurait été la source d'innombrables bogues et incompatibilités qu'il aurait fallu corriger. Il le faudra toujours avec le programme écrit en Go, mais il sera beaucoup plus facile de "vérifier la traduction" que de "comprendre le pourquoi du comment" s'il avait été réécrit en Rust.

[edit] Je précise : c'est mon interprétation de la chose. Je sais qu'il y a un sujet qui traine sur un github, mais je n'ai pas eu le courage de le lire ^^
votre avatar
Je pense que tu es assez proche de la vérité de ce que j'ai lu suite à cet article que je comprenais mal.
votre avatar
Effectivement, j'ai pris un peu de temps pour lire le github, et je constate que j'avais plus ou moins vu juste ^^.
votre avatar
D'après Anders Hejlsberg, à peu près la moitié de ce gain de perf vient de la parallélisation

youtu.be YouTube
votre avatar
Dommage d'adopter Go au moment où un langage bien plus prometteur niveau surplus de taille de binaire, surplus de cycles d'exécution, au plus proche des performances de la référence C, existe : Rust.

M'enfin, on parle d'un ersatz d'ECMAScript/JavaScript port par une bien trop grosse entreprise aux choix technologiques douteux, de toutes façons…
votre avatar
Je t'invite à lire ceci : github.com GitHub

Le choix y est décrit. Après, on est d'accord ou pas d'accord (chacun son avis), mais c'est loin d'être un choix irréfléchi comme tu le laisses penser...

Microsoft va rendre le TypeScript « 10x plus rapide »

Fermer