Quelle langue - D, Go ou Rust a de meilleures chances de remplacer C et pourquoi?

Malgré mon statut et mon parti pris évident en tant que créateur de D, je vais essayer de répondre franchement; J'ai suivi les chemins de Go et Rust, et je sais absolument où le linge sale est lavé en D. J'encourage les personnes occupant des postes similaires dans les communautés de Rust and Go à partager leurs opinions. Alors voilà.

Pour commencer, quelque part dans la question devrait apparaître C ++. S'il doit être remplacé par C, ou s'il est l'un des candidats pour remplacer C, mais en tout cas, C ++ est un élément clé de l'équation. C'est le langage le plus proche de C et un pas en avant évident. Étant donné l'âge du C ++, je suppose en outre dans cette affaire que le C ++, avec C, est l'objectif de remplacement.

Chaque langue a un certain nombre d'avantages fondamentaux (je les appelle "un avantage d'ordre de grandeur", ci-après dénommé "bonus 10x", car ils se qualifient dans la ligue principale en ce qui concerne les approches typiques), et un certain nombre de problèmes. L'avenir de ces langages et leur succès dans l'éviction de C dépend de la façon dont ils déploient stratégiquement leurs bonus 10x et comment surmonter leurs problèmes.

Laisse-moi d'abord me débarrasser de D

Évidemment, c'est une démonstration de ma propre maison, donc je sais où aller afin de ne montrer correctement que ce qui est nécessaire et de cacher les endroits sales. Je peux aussi parler plus de D que du reste de la paire, pour la simple raison que je le connais beaucoup mieux. Parlant avec une simplicité grossière, les principaux problèmes de D sont:

• Mauvaise réception du public après de nombreuses années d'existence nominale. Les long-nés de la communauté peuvent critiquer une telle affirmation (D dans sa forme actuelle est relativement jeune, la popularité augmente, etc.). Mais cette attitude persiste et affecte la croissance de la popularité et c'est un fait. En conséquence, les gestionnaires et les ingénieurs sont sceptiques quant à la vulgarisation d'une langue qui a été perdante pendant si longtemps. De plus, le temps joue contre D jusqu'à ce qu'il n'y ait pas d'augmentation évidente de la popularité.
• La triste histoire de D liée à la collecte des ordures (GC). GC est une grande invention, mais la décision de l'utiliser en D l'a instantanément isolée du public cible principal - les programmeurs C et C ++. Pour eux, la ligne du parti ressemblait à «Vous ne voulez pas d'un GC? Pas de problème! Vous pouvez également utiliser D avec RAII ou avec une commande manuelle! » Bien que cela soit généralement vrai, cette approche était pratiquement inutile en raison du manque de prise en charge d'une telle bibliothèque standard, ce qui signifiait que l'utilisateur prévu devait être dépouillé et commencer par la création d'une infrastructure de base. Même pour ceux qui ne se préoccupaient pas du GC, la qualité de sa mise en œuvre était plutôt discrète. En général, nous pouvons dire que D a obtenu toutes les lacunes du GC, mais n'en a pas profité.
• Manque historique de visionnaires. Privé du soutien de l'entreprise, D a fait avancer la communauté, où il est plus facile de trouver un ingénieur astucieux qu'un chef de projet ou un leader charismatique. Au fil du temps, le succès des efforts de D en matière de promotion et d'autopromotion a eu un résultat négatif. Le premier document de planification est daté du 1er janvier 2015, et la prochaine itération (Vision / 2015H2 - D Wiki) est sortie quatre mois plus tard que prévu, ce qui est un excellent exemple d'auto-ironie en termes de planification

Il y a eu, bien sûr, d'autres problèmes, mais ils étaient soit une conséquence de ce qui précède, soit avaient des conséquences bien moindres.

Je pense que les 10x bonus pour D sont les suivants (encore une fois, quand je dis 10 fois, c'est familier "mieux par ordre"):

• En 10x, la compilation est plus rapide que C ++ pour un code comparable. Ce trou ne peut pas être fondamentalement fermé en C ++, et il est extrêmement difficile de sauter dans d'autres langages. (Go compile un peu plus vite que D, mais le code résultant est plus lent) L'expérience de l'utilisation d'un langage système qui se compile si rapidement en code rapide transforme les anciennes pratiques et est très prometteuse. Combiné avec la puissance des abstractions en D, cela fait essentiellement de D un bon choix pour écrire du code hautement optimisé pour la simple raison que l'expérimentation est bon marché.
• 10 fois plus rapide que les langages de script avec des équipements comparables. D est bien adapté pour écrire facilement des tâches quotidiennes. Le cycle de compilation / lancement reste tout aussi rapide et les avantages en termes de vitesse sont immenses. De plus, il n'y a pas de problème "courir dans les limites" - si le script devient volumineux, en D il y a toujours assez d'outils de langage et de modularité. Il y a bien sûr une mouche dans la pommade, par exemple en Python il y a beaucoup plus de bibliothèques prêtes à l'emploi. Mais le bonus 10x est fondamental ici - les langages système n'ont pas autant de sucre syntaxique et les langages de script sont désespérément en retard de vitesse.
• 10x est plus facile à intégrer avec C et C ++ que tout autre langage. D utilise les mêmes structures en mémoire que C et C ++; et s'appuie sur eux, mais la lecture des couches sous-jacentes reste libre en termes de vitesse. La bibliothèque C standard est entièrement accessible sans aucune pénalité - ni en termes de vitesse, ni de syntaxe, et bien que certaines améliorations soient nécessaires pour une simplicité similaire en termes de bibliothèque C ++, de nombreuses bibliothèques C sont déjà disponibles (https://github.com/D- Programmation ...). On peut dire littéralement qu'aucune autre langue ne peut atteindre ce niveau d'intégration.
• 10 fois mieux que tout autre langage système dans les génériques et la métaprogrammation. En D, l'introspection statique, l'informatique à la compilation (CTFE) et la génération de code basée sur le mixage (mélange de code) constituent le cocktail Molotov, qui est très difficile à mélanger correctement dans d'autres langues, ni nouvelles ni survivantes; dans ce jeu, Go est tellement fou qu'il ne coupe même pas une puce; C ++ 17 est désespérément perdu dans une forêt sombre; et Rust essaie juste de babiller.

Aller à Aller

Je dois souligner que ce n'est que mon avis, qui mérite néanmoins votre attention. Les problèmes de Go sont les suivants:

• Ralentissement fondamental dû aux appels indirects et au ramasse-miettes (GC). Presque aucune application Go significative ne peut être écrite sans recourir aux appels indirects et au GC, qui sont la fonctionnalité centrale. Ce sont des obstacles majeurs à la performance de base de Go. La réponse de Go a été principalement tactique - par exemple, l'amélioration des performances du GC. Cependant, il est peu probable de gagner le défi de remplacer C tactiquement.
• La politique. La ligne du parti chez Go est disproportionnellement forte et dure sur un certain nombre de questions, petites et grandes. Un exemple d'un gros problème - l'approche des génériques était si dénuée de sens et impitoyable qu'elle a fait des génériques le mot dans la lettre "G"; l'ensemble du sujet s'est transformé en larmes sanglantes, entravant toute tentative d'établir un dialogue constructif. Je pense que politiser les problèmes techniques à long terme est un modèle extrêmement préjudiciable, et j'espère que Go trouvera un moyen de résoudre ce problème.
• La simplicité est pire que le vol. Aller est très simple (jeu de mots, Go - marche, note) - il y a même des blagues à ce sujet. Cependant, avec le temps, cela devient problématique; Le code Go est désespérément piéton - les codeurs Go se retrouvent à écrire les mêmes choses encore et encore du point de vue d'une fourmi, car Go ne peut pas abstraire même les concepts ou les algorithmes les plus simples. Les concepts qui ne sont pas encore implémentés par les bibliothèques d'intégration sont difficiles à implémenter. Il y a une réaction négative des programmeurs qui ont utilisé Go pour un projet et ne veulent plus le réutiliser. Ce serait bien si Go améliorait la vie des clients réguliers.

Go 10x les bonus selon moi sont les suivants:

• 10x en stratégie de compétences. Après une brève période où Go a été positionné comme langage système, il a été décidé de le positionner pour les services réseau. Ce fut une grande initiative marketing qui a exploité les forces de l'équipe Go (certains des meilleurs ingénieurs de services réseau au monde). C'est un marché très chaud et Go est devenu une bouffée d'air frais pour le monde, qui était auparavant dominé par Java EE avec sa bureaucratie et ses langages de script lents. Maintenant, Go est le principal acteur dans ce domaine et sera difficile à déplacer.
• 10x dans la compétence Ingénierie. Go a une solide équipe d'ingénieurs derrière elle, et c'est le principal facteur qui influence la qualité de la langue, et en particulier la bibliothèque réseau et le jeu d'outils. Jusqu'à présent, une bonne ingénierie a entièrement compensé la faiblesse du langage.
• 10x dans l'image de marque de compétence. Beaucoup d'entre nous sont prêts à admettre que la principale motivation pour utiliser Go est sa connexion avec Google. Cela lui donne l'autorité du professionnalisme, de la qualité et de la stabilité. Bien sûr, une marque n'est pas tout, mais elle fait déjà de Go une langue digne; il ne devrait pas être incroyablement bon. La marque fera le reste.

Last but not least, Rust

Permettez-moi de vous rappeler à nouveau que ce n'est que mon avis. Je pense que Rust fait face à des problèmes intéressants:

• Personnalité disharmonieuse. Après avoir lu une certaine quantité de code Rust, des anecdotes telles que "Mec raté jours de jambes qui se balancent" apparaissent, illustrées par des bandes dessinées avec des gens avec un torse et les jambes croisées (traduction approximative. En russe, "Colosse sur des pieds d'argile", mais inexact) La gestion précise et sécurisée de la mémoire passe avant tout et représente le centre du monde. Du coup, c'est rarement un problème, ce qui conduit au fait qu'une grande partie de la planification et du codage est consacrée, en fait, au travail de bureau (que les langages avec GC automatisent sans regarder). La réutilisation sécurisée et prédéfinie de la mémoire est une tâche sérieuse, mais pas la seule, ou du moins pas la plus importante du programme. En conséquence, Rust consacre une quantité disproportionnée de ressources de conception de langage à cela. Il serait intéressant de voir comment Rust gonfle pour d'autres aspects de la langue; la seule option est d'étendre le langage, mais la question est de savoir dans quelle mesure l'abstraction peut aider avec le besoin désagréable de contrôler les ressources à tous les niveaux.
• Syntaxe étrangère. La syntaxe de Rust est différente [de tous], mais il n'y a aucun avantage évident dans un tel exotisme. Cela agace les personnes issues des langues de la famille Algol, qui doivent composer avec une syntaxe radicalement différente, en plus de la nécessité de gérer manuellement toute la comptabilité avec des ressources.

Les bonus 10x de Rust sont:

• 10 fois les meilleurs théoriciens. Parmi ces trois, seul Rust a des théoriciens de classe mondiale dans le développement d'un langage de codage. Cela se voit dans l'exactitude de la description technique de la langue et dans les profondeurs de l'approche technique.
• 10 fois plus de sécurité que les autres langues du système. Bien sûr, cela devrait être ici, nous ne pouvons que débattre du coût de cette approche.
• 10 fois le meilleur PR (PR, publicité, environ Per.) Il y a eu une période assez longue où Rust était le favori de la communauté, ce qui ne pouvait être confondu: pour tout problème, Rust avait une solution ou devait l'obtenir avec la version 1.0. La réalité de la sortie de 1.0 a interrompu cette lune de miel et a été marquée (dans mes mesures et attentes) par une forte baisse de l'intérêt général, bien que ces facteurs tendent à se prolonger. De plus, au final, Rust est un langage décent avec de réelles réalisations, et il est bien placé pour transformer ce battage médiatique prolongé en un marché stable.

Brièvement

Que l'un de ces langages soit capable de remplacer progressivement le C, le C ++ ou les deux dans les systèmes logiciels existants, et que ces langages deviennent prioritaires pour les projets qui choisissent aujourd'hui le C ou le C ++ par défaut, tout dépend de la capacité de ces langages à utiliser leurs avantages et trouver des solutions créatives à leurs problèmes respectifs.

Traducteur de notes.
Désolé pour l'ancien article, je viens de le rencontrer à la fin de ma série sur la programmation fiable, et semblait assez amusant à citer. Dans RuNet, cependant, aucune traduction, et même une discussion complète, n'a été trouvée.