Discussion :

[Jade Emy]

Un TypeScript 10x plus rapide : Anders Hejlsberg, architecte principal de Microsoft pour TypeScript, présente un nouveau portage de TypeScript qui offrira aux développeurs un outil de haute performance.

Microsoft annonce une réécriture de son langage de programmation TypeScript en le dotant d'un compilateur et d'un ensemble d'outils natifs. Cet effort vise à résoudre les problèmes de performance, en particulier dans les grandes bases de code, en portant le compilateur TypeScript existant de TypeScript/JavaScript au langage natif, Go. Anders Hejlsberg, architecte principal de Microsoft pour TypeScript, affirme : "L'implémentation native améliorera considérablement le démarrage de l'éditeur, divisera par 10 la plupart des temps de construction et réduira substantiellement l'utilisation de la mémoire".

Le 11 mars 2025, TypeScript a annoncé une réécriture complète de TypeScript en Go. Lors des tests, cette réécriture a permis une accélération de 10 fois dans certains dépôts - et jusqu'à 15 fois dans d'autres. Cette accélération affectera chaque partie de l'écosystème TypeScript : de l'exécution de tsc via CLI à la performance des survols et des erreurs dans votre IDE. Une fois la version publiée, vous serez en mesure d'adopter la nouvelle version de TypeScript sans modifier une seule ligne de code.

Pour rappel, TypeScript est un langage de programmation open-source et gratuit, développé par Microsoft, qui ajoute à JavaScript un typage statique avec des annotations de type optionnelles. Il est conçu pour le développement de grandes applications et se transpose à JavaScript. Depuis des années, l'amélioration des performances est la fonctionnalité la plus demandée par la communauté. Plusieurs tentatives ont été faites pour réécrire TypeScript dans un langage plus rapide, mais aucune n'a abouti.

Anders Hejlsberg, architecte principal de Microsoft pour TypeScript, a récemment présenté cette réécriture de TypeScript. Anders Hejlsberg est un ingénieur logiciel danois qui a co-conçu plusieurs langages de programmation et outils de développement. Il est l'auteur original de Turbo Pascal et l'architecte en chef de Delphi. Il travaille actuellement pour Microsoft en tant qu'architecte principal de C# et développeur principal de TypeScript.

Anders Hejlsberg présente un nouveau portage de TypeScript qui offrira aux développeurs un outil de haute performance

La proposition de valeur centrale de TypeScript est une excellente expérience pour le développeur. Au fur et à mesure que votre base de code se développe, la valeur de TypeScript elle-même augmente, mais dans de nombreux cas, TypeScript n'a pas été en mesure de s'adapter aux bases de code les plus importantes. Les développeurs travaillant sur de grands projets peuvent être confrontés à des temps de chargement et de vérification longs, et doivent choisir entre un temps de démarrage raisonnable de l'éditeur et une vue complète de leur code source.

Les développeurs apprécient de pouvoir renommer des variables en toute confiance, de trouver toutes les références à une fonction particulière, de naviguer facilement dans leur base de code et de faire toutes ces choses sans délai. Les nouvelles expériences basées sur l'IA bénéficient de larges fenêtres d'informations sémantiques qui doivent être disponibles avec des contraintes de latence plus strictes. Microsoft souhaitent également créer des builds en ligne de commande rapides pour valider que l'ensemble de votre base de code est en bon état.

Pour atteindre ces objectifs, Anders Hejlsberg affirme qu'ils ont commencé à travailler sur un portage natif du compilateur et des outils TypeScript. L'implémentation native améliorera le démarrage de l'éditeur, réduira la plupart des temps de construction par 10, et réduira substantiellement l'utilisation de la mémoire. En portant la base de code actuelle, ils prévoient d'être en mesure de présenter une implémentation native de tsc capable de vérifier les caractères en ligne de commande d'ici la moitié de 2025, avec une solution complète pour la construction de projets et un service linguistique d'ici la fin de l'année 2025.


Un TypeScript 10 fois plus rapide

L'implémentation native serait déjà capable de charger de nombreux projets TypeScript populaires, y compris le compilateur TypeScript lui-même. Voici les temps d'exécution de tsc sur quelques bases de code populaires sur GitHub de différentes tailles :

Bien que les fonctionnalités ne soient pas encore complètes, ces chiffres sont représentatifs de l'ordre de grandeur de l'amélioration des performances que vous constaterez en vérifiant la plupart des bases de code.

Anders Hejlsberg commente notamment ces gains : "Nous sommes très enthousiastes à l'idée des opportunités créées par cette augmentation massive de la vitesse. Des fonctionnalités qui semblaient autrefois hors de portée sont désormais à portée de main. Ce portage natif sera capable de fournir instantanément des listes d'erreurs complètes sur l'ensemble d'un projet, de supporter des refactorings plus avancés et de permettre des analyses plus approfondies qui étaient auparavant trop coûteuses à calculer. Cette nouvelle fondation va au-delà de l'expérience actuelle des développeurs et permettra à la prochaine génération d'outils d'IA d'améliorer le développement, en alimentant de nouveaux outils qui apprendront, s'adapteront et amélioreront l'expérience de codage."


Vitesse de l'éditeur

Les développeurs passent la plupart de leur temps dans les éditeurs, et c'est là que les performances sont les plus importantes. Les développeurs souhaitent que ces éditeurs chargent rapidement les grands projets et réagissent rapidement dans toutes les situations. Grâce à cette réécriture, TypeScript serait en mesure de fournir des expériences d'édition incroyablement rapides.

En utilisant à nouveau la base de code de Visual Studio Code comme référence, le temps de chargement d'un projet complet dans l'éditeur sur un ordinateur rapide est d'environ 9,6 secondes. Ce temps tombe à environ 1,2 seconde avec le service de langue maternelle, soit une amélioration de 8 fois le temps de chargement du projet dans les scénarios de l'éditeur. Cela se traduit par une expérience de travail plus rapide depuis l'ouverture de l'éditeur jusqu'à la première frappe dans n'importe quelle base de code TypeScript. Cepedant, il reste à voir si tous les projets bénéficieront de ce niveau d'amélioration du temps de chargement.

L'utilisation globale de la mémoire semble également être environ la moitié de l'implémentation actuelle. La réactivité de l'éditeur pour toutes les opérations des services linguistiques (y compris les listes d'achèvement, les informations rapides, les définitions et la recherche de toutes les références) connaîtra également des gains de vitesse significatifs. Ils passeront également au protocole de serveur de langue (LSP), un travail d'infrastructure de longue haleine visant à mieux aligner l'implémentation sur les autres langues.

Feuille de route des versions

Voici les projets futures pour TypeScript selon Anders Hejlsberg :

Notre dernière version de TypeScript était TypeScript 5.8, et TypeScript 5.9 sera bientôt disponible. La base de code basée sur JS continuera son développement dans la série 6.x, et TypeScript 6.0 introduira quelques dépréciations et ruptures pour s'aligner sur la base de code native à venir.

Lorsque la base de code native aura atteint une parité suffisante avec le TypeScript actuel, nous la publierons en tant que TypeScript 7.0. Cette version est encore en cours de développement et nous annoncerons les étapes de stabilité et de fonctionnalités au fur et à mesure qu'elles se produiront.

Par souci de clarté, nous les appellerons simplement TypeScript 6 (JS) et TypeScript 7 (natif), puisque telle sera la nomenclature dans un avenir prévisible. Vous pouvez également nous voir faire référence à « Strada » (le nom de code original de TypeScript) et « Corsa » (le nom de code pour cet effort) dans les discussions internes ou les commentaires de code.

Alors que certains projets peuvent être en mesure de passer à TypeScript 7 dès sa sortie, d'autres peuvent dépendre de certaines fonctionnalités de l'API, de configurations héritées ou d'autres contraintes qui nécessitent l'utilisation de TypeScript 6. Reconnaissant le rôle critique de TypeScript dans l'écosystème de développement JS, nous continuerons à maintenir la base de code JS dans la ligne 6.x jusqu'à ce que TypeScript 7+ atteigne une maturité et une adoption suffisantes.

Notre objectif à long terme est de maintenir ces versions aussi proches que possible afin que vous puissiez passer à TypeScript 7 dès qu'il répondra à vos besoins, ou revenir à TypeScript 6 si nécessaire.

Il est vrai qu'une amélioration des performances de 10x représente un saut massif dans l'expérience de développement TypeScript et JavaScript. Si Anders Hejlsberg et l'équipe TypeScript sont enthousiaste de cet effort, il est intéressant de rappeller quelques vérités sur TypeScript. En 2023, Stefan Baumgartner, un auteur de deux livres sur TypeScript, a notamment présenté "Cinq vérités inconfortables à propos de TypeScript".

Tout d'abord, il a rappellé que TypeScript n'est pas une version "corrigée" de JavaScript, mais plutôt un sur-ensemble de ce dernier. Il ne vous épargne donc pas JavaScript avec ses bizarreries et ses défauts. Malgré son approche graduelle, TypeScript ajoute aussi de la complexité aux projets en raison de ses nombreuses options de configuration.

En outre, ce n'est pas vraiment un langage à typage sûr, en particulier lorsque des interactions avec le "monde extérieur" sont impliquées. Stefan Baumgartner affirme également que TypeScript existe sous une multitude de variantes implicites, chacune avec ses avantages et ses inconvénients. Malgré tout, il estime que TypeScript reste un langage précieux pour améliorer la productivité et la maintenabilité des projets, à condition de comprendre ses compromis et de l'utiliser correctement.


Et vous ?

Pensez-vous que cette annonce est crédible ou pertinente ?
Quel est votre avis sur le sujet ?

Voir aussi :

Microsoft annonce la disponibilité de TypeScript 5.8, apportant des vérifications plus granulaires pour les branches dans les expressions de retour, ainsi que plusieurs autres améliorations

Le langage Go souffle ses 15 bougies et atteint sa position la plus haute sur l'indice Tiobe. Google annonce que le nombre d'utilisateurs de Go a plus que triplé au cours des cinq dernières années

Pourquoi je suis sceptique quant à la réécriture des outils JavaScript dans des langages "plus rapides", par Nolan Lawson

[Pyramidev]

Comme le but de cette réécriture est d'avoir de bonnes performances, si on ne connaît pas le contexte, le choix le plus évident est le langage Rust. Pourquoi avoir choisi Go ? Ryan Cavanaugh de chez Microsoft a répondu hier à cette question sur reddit. En résumé, c'est parce que le code existant en TypeScript était écrit de telle sorte qu'il était facile de le porter en Go, tandis que passer en Rust aurait nécessité une réécriture beaucoup plus longue et aurait présenté des risques de regression. Voici la réponse complète de Ryan Cavanaugh :

(Hi, dev lead of TypeScript here)

Lots of questions about why Go in thread, let me address.

We definitely knew when choosing Go that there were going to be people questioning why we didn't choose Rust (or others). It's a good question because Rust is an excellent language, and barring other constraints, is a strong first choice when writing new native code.

Portability (i.e. the ability to make a new codebase that is algorithmically similar to the current one) was always a key constraint here as we thought about how to do this. We tried tons of approaches to get to a representation that would have made that port approach tractable in Rust, but all of them either had unacceptable trade-offs (perf, ergonomics, etc.) or devolved in to "write your own GC"-style strategies. Some of them came close, but often required dropping into lots of unsafe code, and there just didn't seem to be many combinations of primitives in Rust that allow for an ergonomic port of JavaScript code (which is pretty unsurprising when phrased that way - most languages don't prioritize making it easy to port from JavaScript/TypeScript!).

In the end we had two options - do a complete from-scrach rewrite in Rust, which could take years and yield an incompatible version of TypeScript that no one could actually use, or just do a port in Go and get something usable in a year or so and have something that's extremely compatible in terms of semantics and extremely competitive in terms of performance.

And it's not even super clear what the upside of doing that would be (apart from not having to deal with so many "Why didn't you choose Rust?" questions). We still want a highly-separated API surface to keep our implementation options open, so Go's interop shortcomings aren't particularly relevant. Go has excellent code generation and excellent data representation, just like Rust. Go has excellent concurrency primitives, just like Rust. Single-core performance is within the margin of error. And while there might be a few performance wins to be had by using unsafe code in Go, we have gotten excellent performance and memory usage without using any unsafe primitives.

In our opinion, Rust succeeds wildly at its design goals, but "is straightforward to port to Rust from this particular JavaScript codebase" is very rationally not one of its design goals. It's not one of Go's either, but in our case given the way we've written the code so far, it does turn out to be pretty good at it.

[Kush Creates]

TypeScript se tourne vers Gopher : Microsoft mise sur Go pour multiplier la vitesse par 10, par Kush Creates

Microsoft mise beaucoup sur GO pour TypeScript, promettant un bond de performance de 10 fois.

TypeScript bénéficie d'une greffe de cœur alimentée par GO. S'agit-il seulement d'une question de vitesse, ou est-ce le signe d'un changement fondamental dans la façon dont nous construisons et mettons à l'échelle les outils de développement ?

Je vais disséquer les implications techniques, l'impact sur les développeurs, et si cela marque un changement de paradigme dans l'outillage des langages de programmation.

Introduction

Très bien, les amis, attachez vos ceintures. Si vous n'êtes pas au courant, Microsoft vient de prendre une décision qui a fait vibrer toute la communauté des développeurs comme une tasse de café fraîchement infusé. Ils portent TypeScript vers GO. Oui, ce GO, le langage créé par Google et qui ne cesse de gagner du terrain en tant que chouchou du monde « cloud-native ».

Avant d'entrer dans le vif du sujet, soyons clairs : il ne s'agit pas d'une simple modification mineure. Il s'agit d'un véritable changement de moteur. C'est comme si vous remplaciez le moteur crachotant de votre vieille voiture par une bête turbocompressée finement réglée. L'objectif ? Une vitesse fulgurante.

Selon l'annonce d'Anders Hejlsberg, ce portage natif promet une amélioration de 10 fois des temps de construction, une réduction de l'utilisation de la mémoire et une expérience d'édition plus rapide et plus fluide. Si ces chiffres se confirment, nous sommes en train de changer la donne. Imaginez que votre pipeline CI/CD devienne soudainement un sprint au lieu d'un marathon.

Lisez l'annonce ici : "Un TypeScript 10x plus rapide : Anders Hejlsberg, architecte principal de Microsoft pour TypeScript, présente un nouveau portage de TypeScript, qui offrira aux développeurs un outil de haute performance"

Ou regardez la vidéo d'annonce ici :

Pourquoi Go ? Pourquoi maintenant ?

La question évidente est : pourquoi GO ? Après tout, TypeScript a été écrit en TypeScript (inception !). La réponse, comme toujours, est la performance. GO est réputé pour sa vitesse, sa concurrence et sa gestion efficace de la mémoire. C'est le genre de langage qui vous permet de construire des choses qui marche efficacement.

C'est Anders Hejlsberg qui l'a le mieux exprimé : TypeScript doit évoluer pour gérer des bases de code de plus en plus importantes. Les développeurs veulent un remaniement instantané, une navigation rapide et des outils alimentés par l'IA qui ne les font pas attendre. L'implémentation actuelle, bien que solide, a ses limites. GO offre un moyen de dépasser ces limites et d'offrir aux développeurs une expérience vraiment exceptionnelle.

L'annonce d'Anders Hejlsberg ne concernait pas seulement la vitesse brute, même si la promesse d'une amélioration de 10 fois les performances est indéniablement séduisante. Il s'agissait de l'évolutivité, de la facilité de maintenance et de la possibilité d'offrir aux développeurs des expériences entièrement nouvelles. À mesure que les bases de code augmentent en taille et en complexité, les outils sur lesquels nous nous appuyons doivent évoluer pour suivre le rythme. C'est le pari de Microsoft sur la façon d'y parvenir.


Au-delà de la simple optimisation

Soyons clairs : le TypeScript existant, écrit en TypeScript, est une merveille d'ingénierie. C'est un témoignage de la puissance expressive du langage et du dévouement de l'équipe à la performance. Cependant, tout système a ses limites. Au fur et à mesure que l'adoption de TypeScript a explosé et que les projets se sont développés pour englober des millions de lignes de code, les contraintes de performance sont devenues de plus en plus évidentes.

C'est là que GO entre en scène. GO n'est pas seulement un langage « rapide » ; il est conçu pour construire des systèmes évolutifs, concurrents et fiables. Ses points forts sont les suivants :

• Gestion efficace de la mémoire : Le ramasse-miettes de GO est conçu pour une faible latence et un débit élevé, ce qui est essentiel pour minimiser les pauses dans les outils interactifs.
  
  
• Primitives de simultanéité : Les goroutines et les canaux de GO facilitent l'écriture de code concurrent qui peut exploiter plusieurs cœurs, accélérant les temps de construction et les opérations de l'éditeur.
  
  
• Des performances simples et prévisibles : La conception de GO met l'accent sur la simplicité et la prévisibilité, ce qui facilite le raisonnement sur les goulots d'étranglement des performances et l'optimisation du code.

Soyons clairs : le TypeScript existant, écrit en TypeScript, est une merveille d'ingénierie. C'est un témoignage de la puissance expressive du langage et du dévouement de l'équipe à la performance. Cependant, tout système a ses limites. Au fur et à mesure que l'adoption de TypeScript a explosé et que les projets se sont développés pour englober des millions de lignes de code, les contraintes de performance sont devenues de plus en plus évidentes.

Le choix de GO ne consiste pas à rejeter les capacités de TypeScript ; il s'agit plutôt de reconnaître qu'un outil différent est mieux adapté à un travail spécifique. C'est un peu comme choisir la bonne structure de données pour la tâche à accomplir, mais aussi parfois une hashmap, et parfois un B-tree.


Décoder les benchmarks

L'article de blog comprend des benchmarks impressionnants :

Une accélération de 10 fois dans tous les domaines ? Je suis preneur ! Bien sûr, il est important de se rappeler qu'il s'agit de résultats préliminaires. Mais même si les chiffres définitifs sont un peu moins spectaculaires, l'impact potentiel est énorme.

Les benchmarks présentés dans l'annonce sont convaincants, mais il est essentiel de comprendre leur contexte et leurs limites potentielles. Décortiquons-les :

Ces chiffres représentent le temps nécessaire pour exécuter tsc sur différentes bases de code. Une accélération de 10 fois est significative, mais il est crucial de la prendre en compte :

• Matériel spécifique : Les tests ont probablement été effectués sur des configurations matérielles spécifiques. La vitesse de compilation peut varier en fonction des spécifications de votre machine.
  
  
• Options du compilateur : Les performances dépendent des options spécifiques du compilateur utilisées. Les niveaux d'optimisation et d'autres paramètres peuvent avoir un impact significatif.
  
  
• Caractéristiques de la base de code : Le gain de performance variera probablement en fonction des caractéristiques spécifiques de votre base de code. Certains projets peuvent en bénéficier plus que d'autres.
  
  
• Complétude des fonctionnalités : L'implémentation native n'est pas encore complète. Les performances peuvent évoluer au fur et à mesure de l'ajout de nouvelles fonctionnalités.

Malgré ces mises en garde, les benchmarks fournissent une indication convaincante des améliorations potentielles en termes de performances. Même si les chiffres définitifs sont plus proches d'une accélération de 5 ou 7 fois, l'impact serait substantiel.


Ce que cela signifie pour les développeurs : L'impact "GOated"

Qu'est-ce que cela signifie pour nous, les utilisateurs de code ? Voici une analyse de la situation :

1. Cycles de développement plus rapides :
   
   
   • La réduction des délais de construction se traduit directement par une itération plus rapide. Passez moins de temps à attendre et plus de temps à coder.
     
   • Les boucles de rétroaction plus rapides vous permettent de détecter les erreurs plus tôt et d'expérimenter plus librement.
   
   
2. Amélioration de l'expérience de l'éditeur :
   
   
   • Complétion de code plus rapide, mise en évidence instantanée des erreurs et navigation transparente. Votre éditeur aura l'impression de lire dans vos pensées.
     
   • Le passage au LSP améliorera encore l'intégration et la compatibilité des éditeurs.
   
   
3. Amélioration de l'expérience de débogage
   
   
   • Des temps de construction plus rapides et une meilleure réactivité de l'éditeur rendent le débogage moins pénible et plus efficace.
   
   
4. Les compétences GO deviennent encore plus précieuses :
   
   
   • L'adoption de GO continuant à croître, les développeurs ayant de l'expérience dans ce domaine seront encore plus demandés.
     
   • Comprendre les forces et les faiblesses de GO vous donnera un avantage concurrentiel sur le marché du travail.

Ces améliorations ne consistent pas seulement à gagner quelques secondes sur les temps de construction ; elles visent à créer une expérience de développement plus fluide, plus réactive et plus agréable. Elles visent à éliminer les frictions et à permettre aux développeurs de se concentrer sur ce qu'ils font le mieux : CRÉER DES LOGICIELS DE QUALITÉ.



Un effet d'entraînement

La décision de Microsoft de porter TypeScript vers GO aura un effet d'entraînement sur l'ensemble de l'écosystème. Voici comment :

• L'adoption de GO prend de l'ampleur : Cette décision encouragera probablement davantage d'entreprises à adopter GO pour les tâches critiques en termes de performances. L'écosystème de GO continuera à se développer et à mûrir.
  
  
• L'interopérabilité devient une priorité : Il faut s'attendre à voir apparaître davantage d'outils et de frameworks qui facilitent l'interopérabilité entre TypeScript et GO. Les développeurs devront être en mesure d'intégrer de manière transparente le code écrit dans les deux langages.
  
  
• L'essor du développement polyglotte : L'avenir du développement logiciel est de plus en plus polyglotte. Les développeurs devront être à l'aise avec une variété de langages et d'outils pour tirer parti des forces de chacun.
  
  
• De nouvelles architectures de compilateurs émergent : Cette évolution pourrait inciter d'autres chaînes d'outils linguistiques à explorer d'autres architectures et implémentations afin d'améliorer les performances.

Vision à long terme de Microsoft

La décision de Microsoft de porter la base de code TypeScript sur GO n'est pas seulement une question de gains de performance immédiats ; il s'agit de positionner TypeScript sur le long terme. Il s'agit de s'assurer que TypeScript reste un langage pertinent et compétitif dans un paysage qui évolue rapidement.

En investissant dans les performances, l'évolutivité et la maintenabilité, Microsoft pose les bases de l'innovation future. Elle permet le développement de nouveaux outils et de nouvelles fonctionnalités qui auraient été impossibles avec l'architecture existante.

Cette décision témoigne d'un engagement en faveur de l'avenir de TypeScript et d'une conviction quant à sa valeur durable. C'est un pari que TypeScript continuera à jouer un rôle crucial dans l'écosystème JavaScript pour les années à venir.

Les parties "GOod"

Résumons les avantages de cette décision d'une manière que même le développeur le plus blasé peut apprécier :

• Des constructions plus rapides = plus de temps pour le café/thé : Soyons honnêtes, personne n'aime attendre les compilations.
  
  
• Compilateur plus rapide = moins de frustration : Dites adieu aux messages d'exception et d'erreur déroutants.
  
  
• Compétences GO = Vous connaissez déjà la programmation Cloud := sac vert IFYKYK

Conclusion : Une opportunité "GOlden"

La décision de Microsoft de porter TypeScript vers GO est une décision audacieuse qui pourrait remodeler l'avenir du développement JavaScript. Bien qu'il y ait sans aucun doute des défis à relever, les récompenses potentielles sont énormes.

Même s'il y aura sans aucun doute des défis à relever, les avantages potentiels, tels que des cycles d'itération plus rapides, une meilleure réactivité de l'éditeur et de nouvelles possibilités de développement basées sur l'intelligence artificielle, sont trop convaincants pour être ignorés.

Il ne s'agit pas seulement de rapidité, mais aussi de permettre aux développeurs de créer de meilleurs logiciels, plus rapidement. Il s'agit de créer une expérience de développement plus fluide, plus réactive et plus agréable. Il s'agit d'investir dans l'avenir de TypeScript.

En tant que développeurs chevronnés, nous devrions accueillir ce changement avec un optimisme prudent. Nous devons expérimenter, contribuer et aider à façonner l'avenir de la base de code TypeScript et de l'écosystème JavaScript. Le potentiel est là pour faire quelque chose de vraiment extraordinaire.

Alors, devriez-vous commencer à apprendre GO ? Si vous êtes sérieux au sujet de la performance, de la concurrence et de l'avance sur la courbe, la réponse est un OUI retentissant.

BONNE RÉPONSE !

Article sous licence Creative Commons Attribution 4.0 International. Les logos utilisés dans cet article sont des marques déposées de leurs propriétaires respectifs. Ils sont inclus à des fins d'information uniquement, et aucune affiliation ou approbation n'est implicite. Le logo TypeScript est une marque déposée de Microsoft Corporation, Le logo Go Gopher est une marque déposée de Go Authors. L'image de Go Gopher dans une combinaison spatiale est une œuvre dérivée inspirée de Go Gopher, et son utilisation est considérée comme équitable à des fins d'illustration dans le contexte de cet article.

Source : TypeScript Goes Gopher: Microsoft Bets on GO for a 10x Speed Boost


Et vous ?

Pensez-vous que cet avis est crédible ou pertinent ?
Quel est votre avis sur le sujet ?

Voir aussi :

Microsoft annonce la disponibilité de TypeScript 5.8, apportant des vérifications plus granulaires pour les branches dans les expressions de retour ainsi que plusieurs autres améliorations

Le langage Go souffle ses 15 bougies et atteint sa position la plus haute sur l'indice Tiobe. Google annonce que le nombre d'utilisateurs de Go a plus que triplé au cours des cinq dernières années

Pourquoi le « Vibe Coding » me donne envie de vomir, par Kush Creates

[jf.larvoire]

Deux remarques:

1) Je ne vois pas le rapport avec Gopher, qui à ma connaissance est un vieux protocole qui n'a strictement rien à voir avec le langage Go. J'ai d'abord pensé à un poisson d'avril, mais l'article original en Anglais date d'une semaine avant, et mentionne aussi Gopher dans son titre!?!

2) La vraie question qui m'interpelle sur le choix du langage, c'est pourquoi ils ont choisi Go, qui est un langage de la concurrence, et pas C#, le langage maison de Microsoft. Si tout ça est vrai, ça ressemble à un sacré désaveu de C#!

[Uther]

1) Je ne vois pas le rapport avec Gopher, qui à ma connaissance est un vieux protocole qui n'a strictement rien à voir avec le langage Go. J'ai d'abord pensé à un poisson d'avril, mais l'article original en Anglais date d'une semaine avant, et mentionne aussi Gopher dans son titre!?!

Le Gopher avant d'être un protocole est le nom en anglais d'un animal qui sert de mascotte au langage Go.

2) La vraie question qui m'interpelle sur le choix du langage, c'est pourquoi ils ont choisi Go, qui est un langage de la concurrence, et pas C#, le langage maison de Microsoft. Si tout ça est vrai, ça ressemble à un sacré désaveu de C#!

Probablement pour la même raison pour laquelle Rust n'a pas été choisi comme l'explique Pyramidev au dessus. Ils ont du considérer que le code JavaScript existant était plus simple a transformer en Go qu'en C#.

[marc.collin]

Deux remarques:


2) La vraie question qui m'interpelle sur le choix du langage, c'est pourquoi ils ont choisi Go, qui est un langage de la concurrence, et pas C#, le langage maison de Microsoft. Si tout ça est vrai, ça ressemble à un sacré désaveu de C#!

on pourrait dire la même chose avec angular... pourquoi prendre typescript au lieu de dart