AFAIK git already uses multiple languages, github says its 50% C, 38% shell, 4% perl, then 4% TCL python 1%

So "another language" here probably does not weigh as much, especially considering perl/TCL are the weirder one there.

But for big projects like linux and git, this could actually be a consolidation step: you spent decades growing, hacking things on top of each other.

You have mostly figured out what this project is and where it is going, it's time to think about safety, performance and remove old hacks.

Rust feels like a good fit, imho.

▲

fuhsnn 3 days ago | parent | next [-]

Perl, TCL and Python are all written in C, as well as many shells, so despite their interdependency the total complexity can be satisfied with a C11 compiler.

	▲	johnisgood 2 days ago \| parent [-]
		Oh no, we need Rust all the way to the core. /s

▲

bArray 3 days ago | parent | prev [-]

I did check this out. The shell, perl and python are likely for scripting and not used during runtime. TCL is likely some form of dynamic scripting.

I think we also have to be honest about what the project here is too, it's not to have both C and Rust together, but to replace all C with Rust. In which case, it probably makes sense to just clone to repo and work on a fork like they did with SSH.

▲

rbehrends 3 days ago | parent | next [-]

> The shell, perl and python are likely for scripting and not used during runtime.

Some git subcommands are implemented in these. git filter-branch is a shell script, git cvsimport is a Perl script, and git p4 (perforce interop) is a Python script. There are not too many left these days (git add -p/-i also used to call a Perl script), but they exist.

▲

tankenmate 3 days ago | parent [-]

I'm sure you are aware, reading between the lines of what you said, why, but for some others who aren't aware of the history of git; it was originally about 50% C and 50% Perl, the performance critical parts were written in C and then various git commands were written in Perl. Over time almost all the Perl was removed because there were less Perl monks than C devs.

Now it would seem the logic is reversed; even though there are less Rust devs than C devs, Rust is going to replace C. Maybe now that git is large enough and entrenched enough such a move can be forced through.

	▲	cesarb 3 days ago \| parent [-]
		> it was originally about 50% C and 50% Perl, the performance critical parts were written in C and then various git commands were written in Perl. IIRC, it was mostly shell, not Perl, and looking at the proportion is misleading: the low-level commands (the "plumbing") like git-cat-file or git-commit-tree were all in C, while the more user-friendly commands (the "porcelain") like git-log or git-commit were all shell scripts calling the low-level commands. Yes, even things we consider fundamental today like "git commit" were shell scripts.

▲

mook 3 days ago | parent | prev | next [-]

I believe gitk and git-gui are written in tcl. Those are definitely things that get shipped to the user, so (at least for those parts) you wouldn't need to have a toolchain on the build server.

▲

rascul 3 days ago | parent | prev [-]

A number of the git commands were implemented in perl and shell. Now I see only git-svn is perl here for me and there's still a few shell scripts in /usr/libexec/git.