Je suis assez d'accord avec ceux qui, au cours de la discussion, ont mis en avant la complexité du C++.

Cependant, ils oublient un truc très simple: le C++ compile du C presque correctement (il existe quelques différences, genre le fait que i++ et ++i aient autre chose que la priorité des opérateurs comme différence, une sombre histoire de constructeur par copie pour les objets...).

Autre chose, la complexité plus grande du C++ par rapport au C, n'est pas obligatoire à l'usage.
On peut très bien ne pas faire de classes. Ou on peut très bien ne pas utiliser les templates. On peut ne pas utiliser les exceptions (quoiqu'il me semble que C les gère? J'ai un doute à ce sujet, il n'y a pas une lib standard qui les traite?)...

Le C++ possède simplement des possibilités supérieures au C. En contrepartie, il possède un léger embonpoint dès que l'on utilise ses ajouts au C, dépendant des implémentations des compilateurs (ce qui, d'ailleurs, est aussi vrai pour le C, vu que la norme fonctionne de la même façon pour ces langages: l'implémentation est libre, seul le "contrat" si je puis dire, est fixé). En gros, le fait de devoir passer l'adresse de l'objet aux méthodes non statiques (et non-inline, mais d'une certaine façon ce ne sont pas vraiment des fonctions, plus des macros) qu'il possède coûte un peu de mémoire et de processeur. Cela dis, utiliser une structure en C et passer son adresse à une fonction à le même coût.
Un autre embonpoint est causé par le support de la RTTI, mais une fois encore, il faut utiliser cette fonctionnalité du C++, pour "subir" cette charge supplémentaire.
Et il en va ainsi pour toutes les fonctionnalités ajoutées du C++, à l'exception des template, dont le coût n'est pas répercuté à l'exécution du programme, mais à la compilation (quoique, ils génèrent du code supplémentaire, donc une augmentation de la consommation mémoire du segment ".text" - pour les assemblistes -- s'ils sont utilisés à tord et à travers.)

Mais chacune de ces fonctionnalités, bien utilisée, permet l'augmentation soit de la stabilité, soit des performances, soit de la maintenabilité du code (laquelle peut d'ailleurs résulter résulter en stabilité et performance...) ou de sa réutilisabilité (bien que quand on me sors qu'avant la POO le code était pas réutilisable - et un prof me l'a dis et répété à plusieurs reprises encore il y a peu de temps... j'aurai peut-être pas dû reprendre mes études après avoir bossé... - cela me file de l'urticaire!).
Les problèmes causés par ces baisses de performance sont en fait de simples maux moindres comparé à ceux que ces fonctionnalités résolvent.

Bien sûr, abuser d'une fonctionnalité - en fait, ne pas savoir s'en servir, ou ne savoir se servir que d'elle - cause plus de problème que ça n'en corrige. Utiliser une massette pour enfoncer un clou parce qu'on ne sait pas utiliser un marteau, par exemple, vous brisera vite les mains, et utiliser la même masse pour couper une planche...
Pour autant, la massette est un outil merveilleux lorsqu'utilisée correctement.

Un langage doit être utilisé selon le contexte? Je ne suis pas entièrement d'accord. Pour moi, la plupart des langages peuvent résoudre la plupart des problématiques. Les gens confondent trop souvent langage et bibliothèque officielle du langage. C'est pour ça que "C++ n'est pas fait pour faire des scripts CGI alors que JAVA est super pour ça" me fait sourire. C++ avec une bibliothèque pour gérer les CGI tiens la route aussi. C'est juste que c'est pas "par défaut", pas intégré officiellement. (Je parle de JAVA parce que c'est le 1er qui me viens à l'esprit, hein, et uniquement pour cette raison)
L'utilisation d'un langage plutôt qu'un autre, a mon humble avis est décidée par le fait que les programmeurs devant développer un programme ont une préférence/facilité pour tel ou tel langage ou que la base de code existant est en tel autre langage. Ensuite, niveau technique, toujours selon moi, la seule réelle distinction se situera sur le fait qu'un langage soit compilé "pour de vrai" en code machine (asm, C, C++, d'autres que je ne connaît pas), "pseudo-compilé" en un code machine fait pour tourner sur une machine virtuelle (C#, JAVA, je crois OBJ-C mais j'ai peur de dire une immense co***rie) ou encore juste interprété (vba, python, php, perl), qui, selon le cas, permettent de refiler plus ou moins rapidement un programme sur une quantité variée d'architectures (d'où l'utilisation pour moi pertinente de java pour les applets que l'on trouve sur certaines pages web), selon les contraintes que cette architecture impose (on va pas utiliser du JAVA dans une puce électronique, je pense... et pas que pour son manque de fonctionnalités matérielles, mais parce que la JVM pèse son poids).

Par contre, chaque fonctionnalité d'un langage/framework (ou bibliothèque, peu importe le nom) doit être utilisée selon le contexte.
Utiliser une liste doublement chaînée pour gérer un vulgaire tableau alloué dynamiquement est fonctionnel mais stupide: augmentation du coût en temps et en mémoire du programme, alors qu'un vector, ou mieux, une allocation de variable via un pointeur intelligent (ou pointeur classique, si on veut vraiment les performances maximum) est bien plus approprié.

Donc, en conclusion, oui, j'ai envie de dire que Linus à été beaucoup trop loin dans son mail (quand à qualifier comme il le fait les gens qui font boost et la stl, qui sont quand même des pointures (et pas pointeurs xD) c'est tout simplement une belle démonstration de bêtise). Mais pour autant, vu que Linus est bien plus à l'aise avec le C qu'avec le C++, il a eu entièrement raison d'utiliser ce langage pour GIT.
Par contre, clairement, le C++ est supérieur au C, parce qu'il permet de faire les mêmes choses, et bien plus encore (hummm pourquoi la chanson "denver le dernier dinosaure[...]c'est mon ami et bien plus encore[...]" me reviens en tête? Faut vraiment que je dorme plus moi...).

Voila pour ma contribution au troll ^^ (bon, j'ai essayé de pas trop troller quand même, notez l'effort )

Ah, petit commentaire final tout de même:
L'ASM permet de faire des choses plus souplement que le C et le C++: il est possible de passer un nombre dynamique d'arguments aux fonctions... (Je suis précisément en butte sur un problème de ce type en ce moment...) alors Linus devrait coder en ASM, parce que, franchement, les dev C, ce sont vraiment des boulets qui ne savent rien faire proprement, le C c'est vraiment la porte ouverte à toutes les fenêtres, et je suis sûr que vous serez tous d'accords avec moi xD