Linus is a bit obsessed with making the software he uses fast. I don't think it'd be as easy to make git as fast as it is if it was written in something other than C.

Subsurface though probably could be written in a different language and not feel any slower.

>Is C the best possible choice for Git? For Subsurface? For the embroidery template converter thingie he wrote for his wife?

Sure -- since he also wrote those himself, so a good requisite would be "language Linus can quickly write shit in".

And for git there are other reasons too: portable, fast, lots of people can hack in C, etc.

> "Is C the best possible choice for Git?"

Well, I mean...

  SLOC  Directory       SLOC-by-Language (Sorted)                              
  100691  top_dir         ansic=80140,perl=10458,sh=7523,python=2570           
  98482   t               sh=97926,perl=546,ansic=10                           
  38293   builtin         ansic=38293                                          
  22256   contrib         sh=9888,perl=5838,python=3130,lisp=1786,ansic=1449,  
                          php=120,csh=45                                       
  18056   compat          ansic=18004,perl=52                                  
  13754   git-gui         tcl=10299,sh=3455                                    
  10859   gitk-git        tcl=10745,sh=114                                     
  6225    gitweb          perl=6225                                            
  5400    perl            perl=5400                                            
  2350    xdiff           ansic=2350                                           
  1288    vcs-svn         ansic=1288                                           
  689     git_remote_helpers python=689                                        
  292     Documentation   perl=155,sh=137                                      
  266     templates       sh=266                                               
  203     block-sha1      ansic=203                                            
  173     ppc             asm=98,ansic=75                                      
  0       mergetools      (none)                                               
  0       po              (none)                                               
                                                                               
                                                                               
  Totals grouped by language (dominant language first):                        
  ansic:       141812 (44.42%)                                                 
  sh:          119309 (37.37%)                                                 
  perl:         28674 (8.98%)                                                  
  tcl:          21044 (6.59%)                                                  
  python:        6389 (2.00%)                                                  
  lisp:          1786 (0.56%)                                                  
  php:            120 (0.04%)                                                  
  asm:             98 (0.03%)                                                  
  csh:             45 (0.01%)

Git's design is such that different parts of it can be written in different languages with no hassle. The majority is in C, but typically new features are prototyped out in other languages first until it becomes clear that speed will be important (and it generally will, since a major usage pattern of git is scripts and other commands calling your command many times in a row. Does git-add need to be fast if you're just doing 'git add ...'? Perhaps not. Does it need to be fast if my fancy-smancy script is wailing on it several thousand times? Yeah; particularly it needs to have a fast startup time. Does git-difftool need to be in C? Probably not, which is probably why it is still Perl instead. Test-cases? No reason in the world for them to be in C, so they're in sh.)

Linus has stated his opinion about C++ code at the kernel. You just have to search it, you'll find.

The TLDR is very alike his TLDR for bool. C++ is too complex, it's hard to know about everything it's doing behind the scenes, and he wants total control of the code on the kernel.