For example, most of the entries in the Python one are utterly inane, and won't apply to your project. You can easily trim that file to 1/5 it's size. It includes the ignores for a bunch of directories I've never see any project ever have, two unit test frameworks, two web frameworks, pip's files that are already better covered by virtualenv ignores, four different ways of naming your virtualenvs…
This isn't measuring language complexity; this is someone trying to pre-cover any potential case generated by any popular-today third party library.
The visual studio one seems to cover just about every way you could use VS, and every plugin made for it. This measurement comments more on the neatness of the IDE(s) than any kind of language complexity.
Agreed. VS supports dozens of languages across web, desktop, mobile, etc. C#, VB, F#, C, C++, JavaScript, T-SQL, Python... and that's just what I can list off the top of my head. Even with single languages in the list it's not apples-to-apples. "Language complexity" should be removed from the link title.
It also probably depends on what development tools people use. If everyone on the project uses a different IDE that's different patterns for each of them, but they all have to be in the ignore file.
Well, that is what a global gitignore file [1] is all about. Entries specific for your working environment (IDE-files) should be defined in your global gitignore, while everything project-specific (object files, build-directory etc.) should be in the project-gitignore.
Elaboration: the number of rules in .gitignore files scale pretty linearly with the number of options you have for tooling. If there are lots of tools that work with your language, your .gitignore template will be big. If there is only one or a few tools, your .gitignore template will be small.
Whether or not "language complexity" correlates with "number of options for tooling" is left as an exercise for the reader. Personally, I think there's an argument to be made for popular languages having more tooling options...
For example, most of the entries in the Python one are utterly inane, and won't apply to your project. You can easily trim that file to 1/5 it's size. It includes the ignores for a bunch of directories I've never see any project ever have, two unit test frameworks, two web frameworks, pip's files that are already better covered by virtualenv ignores, four different ways of naming your virtualenvs…
This isn't measuring language complexity; this is someone trying to pre-cover any potential case generated by any popular-today third party library.