NonStop discussion around adding Rust to Git [LWN.net]

Please consider subscribing to LWN

Subscriptions are the lifeblood of LWN.net. If you appreciate this
content and would like to see more of it, your subscription will
help to ensure that LWN continues to thrive. Please visit
this page to join up and keep LWN on
the net.

By Daroc Alden
November 22, 2024

The Linux kernel community’s discussions about including Rust have

gotten a lot of attention, but the kernel is not the only project wrestling
with the question of whether to allow Rust. The Git project

discussed the prospect in January, and then

again at the Git Contributor’s Summit in September. Complicating the
discussion is the Git project’s lack of a policy on platform
support, and the fact that it does already have tools written in other
languages.
While the project has not committed to using
or avoiding Rust, it seems like only a matter of time until maintainers will
have to make a decision.

Taylor Blau opened the discussion in January by listing some of the advantages
of Rust for the Git project: memory safety, lack of data races, easier
refactoring (in the absence of unsafe code), and making it easier for more
people to contribute to Git. “Given the allure of these benefits, I think it’s at least worth
considering and discussing how Rust might make its way into” Git’s mainline.
Blau also pointed out some questions that would need answering
before the project could consider using Rust: how the language would affect
platform support, which parts of Git would be easiest to migrate or extend (as
is nature of sprawling mailing list discussions, the participants later touched on
both), and how the
change would interact with ongoing maintenance efforts.

Elijah Newren

was excited about the idea, but suggested that one alternative would be to
allow Rust only in optional components, in the same way that the kernel
currently does.
He volunteered to rewrite

git-replay in Rust as a test case, noting
that since (at the time of posting) it hadn’t been included in a Git release, it
wouldn’t cause a regression. Newren was in favor of adopting Rust for different reasons
than the ones Blau had listed in his message, however. He said that the Git
developers often avoid making parts of the code execute in parallel, because of the
difficulty of doing that correctly in C. Using Rust might allow for performance
improvements from adding parallelism, and from switching to more efficient
algorithms and data structures that are “quite onerous” in C. He
specifically called out hash maps as a more performant alternative to the use of
flat arrays in core Git code.

Other contributors were also open to the possibility. For example, brian m. carlson

said “I’m very much in favour of this“. He did think that there were
serious obstacles to adopting Rust, however. He mentioned Rust’s rapid release
cycle as one such problem, but saw platform support as “probably the biggest
stumbling point“.

His main concern was with

NonStop, a relatively niche platform primarily used in the financial sector
for high-reliability computing.
Earlier NonStop systems are based
on Intel’s Itanium architecture, but more recent systems have used x86_64. Both
architectures run a proprietary operating system. The platform has its
own C compiler, but many common tools, such as GCC, have not been ported. Git,
however, has supported NonStop since Git 1.8.0 in 2012. That initial support
was added by Joachim Schmitz, but Git doesn’t have a policy
for when and how that support should continue — as Emily Shaffer

pointed out: “As far as I
can tell, the support policy now is ‘if you run make test on it and
breaks, and you let us know, we’ll try to fix it’ – without much in
the way of additional caveats.”

Randall Becker, one of the most currently active NonStop maintainers,

said that he thought Git’s wide portability was actually one of its most
important strengths. Git’s policy of not relying on Linux-specific tools means
that “we can take any developer from any platform and move them anywhere else without
having to design new processes or teach them new processes for their
workflows“. In Becker’s view, adopting Rust will “rapidly limit (or
eliminate) git’s long-term viability.”
He

went on to suggest that the Git project should consider the impact of
limiting platform support carefully, since it is such a fundamental
piece of infrastructure:

What is the broad impact of dropping support for a platform that has a significant investment in
git, where loss of support could have societal impact. There are platforms with 100 million to 1000
million lines of code managed by git today. This type of investment-related impact is specific to
git compared to other Open-Source products. Leaving debit or credit card authorizers without a
supported git would be, let’s say, “bad”.

Junio Hamano, the leader of the Git project since 2005,

wasn’t convinced, saying:

It depends but “investment-related impact” is unlikely cause
for us to personally care. But those $CORPS who will feel the
“investment-related impact” are welcome to hire quality developers
and to these employed developers, the “impact” might become an issue
they care more deeply about.

In another
message, he did suggest that the project might consider treating niche
platforms in the same way as platforms that package binary releases of Git —
that is, requiring the platform to carry its own patches on top of stock Git.
Newren

listed the many problems he saw with establishing a platform-support policy
that could guide the project in cases like this. Among other problems, he said
that “we don’t even know which platforms Git is used on“. Newren also
thought that any platform policy would need to address optional build components,
including the several optional components that Git already has, such as Tcl support.

The idea of treating items written in rust as optional components,
to be used only for non-essential uses,
caused some doubts. Patrick Steinhardt

expressed the opinion that once Rust had been permitted into any part of the
Git code, it was likely to spread. He said that if Rust was accepted, “it will only be a
matter of time before we want to start using it in central code paths“.

Ultimately, the January discussion petered out with the topic unresolved. Blau implicitly
reopened the topic in September when he

posted the notes from the Git
Contributor’s Summit. Becker

responded by noting that — while he does
“not fundamentally object to Rust” — the contributors who are discussing
it still have not answered whether or how Git could continue supporting NonStop
as a platform if Rust were allowed. Porting Rust to NonStop is non-trivial, but
beyond that,
he said that depending on a single toolchain
to determine which platforms are supported is “not
responsible, in my view“. Sean Allred

pointed out that any platform Git supports already depends on outside
toolchains. “Any platform-specific bugs
in the various C compilers used are not in this project’s control,
either“, he said.

Allred also thought that refusing to allow any new languages or libraries to be
used for the
project would essentially be a commitment to stop adding new features to Git:

It is hard to write correct, safe C. I worry that this
difficulty will eventually translate to significant, safe contributions
coming only from those with the resources to create them and not from a
more diverse pool of contributors. As grateful as I am to large
companies who fund Git contributions, I don’t think those companies,
given the choice in and of themselves, would think twice about dropping
support for a platform they don’t use — and that is probably a much
smaller set than ‘does the platform have GCC’.

Introducing Rust would be a pain for NonStop users, though, Allred acknowledged.
Becker

was not satisfied with that line of thinking. For one thing, he only
objected to adding non-portable dependencies. For another:
“Telling 10-20000 users that their core bit of infrastructure is insecure and
not fixable
is not a tenable position“, he said. The fact that old versions of Git would
remain usable on NonStop isn’t good enough, when there’s no guarantee or policy
for how long it would take to backport security fixes, nor how long a version
will remain supported.

Phillip Wood

thought that it would always be possible for communities of interested users
to backport their own security fixes, but agreed that adding Rust to the project
was a tradeoff:

I believe that those advocating for using rust are doing so because they
believe it will benefit both contributors and users. The problem we have
to wrestle with is whether those benefits outweigh the cost to the
relatively small proportion of users who do not have access to rust on
their platform.

Becker has raised the possibility of porting Rust to NonStop with the platform
vendor and

promised to keep the mailing list updated, but any potential port will be
at least a year away, assuming one is even possible. With this discussion
failing to reach a firm conclusion either, it appears that the Git project is
stuck with an ongoing tension between a small group of users, its legacy of
broad support, and its role as core infrastructure on one hand, and
increased security, performance, and ease of contribution on the other. Which
way the project (and specifically Hamano, as its leader) will decide remains to be seen.