5 ms·

I wonder if Linus has ever tried better languages.

by dscrd 13y ago

aa0 13y ago
Ruby on Rails and your single-origin latte is calling. C is the most performant for years now, a large part of the kernel is in assembly. Remember to download your gems tonight, rude boy.
dima55 13y ago
Are you proposing the kernel be rewritten in a "better" language?
- enneff 13y ago
  I have no idea how you derived that from that comment.
  - coldtea 13y ago
    He derived by you saying "better". For what he does there is NO better language than C. So what would be a "better language"? Haskell? In what way would it be better -- since it wouldn't be better for the tasks he wants? Abstract better? Sorry, I don't believe in that.
    - aa0 13y ago
      You forget you're on HN where slow ass designer languages are all the hail. Sigh..
    - dmit 13y ago
      Is C the best possible choice for Git? For Subsurface? For the embroidery template converter thingie he wrote for his wife? Linus used C for all of those, but was it because C was technically the best choice in each case, or because it was good enough to get the job done and because it's the language he's most comfortable with?
      - FreeFull 13y ago
        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.
      - coldtea 13y ago
        >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.
      - jlgreco 13y ago
        > "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.)
    - frozenport 13y ago
      Windows has large portion of its code written in C++ MacOS has large portion in embed C++ and objective C Like any good video game, NetBSD supports kernel scripting in LUA Linux implements some C++ features like the `virtual`.
      - marcosdumay 13y ago
        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.
    - enneff 13y ago
      > you saying "better". I didn't make the original comment.
maxk42 13y ago
Well assembly is unwieldy for writing the entire kernel, but he's written portions of it that way.

I wonder if Linus has ever tried better languages.

by dscrd 13y ago

I wonder if Linus has ever tried better languages.

aa0 13y ago

Ruby on Rails and your single-origin latte is calling. C is the most performant for years now, a large part of the kernel is in assembly. Remember to download your gems tonight, rude boy.

dima55 13y ago

Are you proposing the kernel be rewritten in a "better" language?

enneff 13y ago
I have no idea how you derived that from that comment.
- coldtea 13y ago
  He derived by you saying "better". For what he does there is NO better language than C. So what would be a "better language"? Haskell? In what way would it be better -- since it wouldn't be better for the tasks he wants? Abstract better? Sorry, I don't believe in that.
  - aa0 13y ago
    You forget you're on HN where slow ass designer languages are all the hail. Sigh..
  - dmit 13y ago
    Is C the best possible choice for Git? For Subsurface? For the embroidery template converter thingie he wrote for his wife? Linus used C for all of those, but was it because C was technically the best choice in each case, or because it was good enough to get the job done and because it's the language he's most comfortable with?
    - FreeFull 13y ago
      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.
    - coldtea 13y ago
      >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.
    - jlgreco 13y ago
      > "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.)
  - frozenport 13y ago
    Windows has large portion of its code written in C++ MacOS has large portion in embed C++ and objective C Like any good video game, NetBSD supports kernel scripting in LUA Linux implements some C++ features like the `virtual`.
    - marcosdumay 13y ago
      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.
  - enneff 13y ago
    > you saying "better". I didn't make the original comment.

maxk42 13y ago

Well assembly is unwieldy for writing the entire kernel, but he's written portions of it that way.