Git introducing Rust into their base

[drhowarddrfine]

[PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty - Patrick Steinhardt

this small patch series introduces Rust into the core of Git. This patch
series is designed as a test balloon, similar to how we introduced test
balloons for C99 features in the past.

 

[Charlie_]

It's discussed here.

Git haas gone wild (Rust)

 

[kpedersen]

In many ways, this might make a proper port to Windows feasible. Assuming they replace the Perl cruft with Rust rather than just adding more shite into it. Currently the Windows ports needs Cygwin/msys2 to function which is gross.

Game Of Trees is likely going to be the preferred Git client for FreeBSD anyway (due to the licensing), and luckily due to the disciplined community developing it, Rust will unlikely ever be allowed to cause issues (bootstrap, portability, build, maintenance, bindings) there.

 

[mer]

So basically, the tools that "I" use to access git repos are going to be Rust based instead of C/Perl/Python/whatever they are right now?
If that is what they're are doing, does it really matter to a user as long as the tools work correctly?

 

[lost_in_c]

I suppose the concern is more about the long term impact of spreading Rust in code. It may matter to the user indirectly in that sense.

 

[mer]

I suppose the concern is more about the long term impact of spreading Rust in code. It may matter to the user indirectly in that sense.

I'm not sure I follow. I don't care what a word processor is coded in as long as it works correctly. Why should this be any different?

 

[lost_in_c]

I'm not going to pretend to know the ins and outs of Rust. I barely have a grasp over the basics of C.

However, from what I have read regarding resistance to things written in Rust, there are structural misgivings about the language.

If that is the case, it would be different in the same sense that, say, a functional application with a serious, though yet unexploited, security risk is different from one that does not have that structural risk.

The user might not immediately notice a problem. They may not even notice any problems if the risk becomes exploited. These are just scenarios in which problems may exist that affect a user even if the user has no direct experience of any bugs.

 

[T-Aoki]

Game Of Trees is likely going to be the preferred Git client for FreeBSD anyway (due to the licensing), and luckily due to the disciplined community developing it, Rust will unlikely ever be allowed to cause issues (bootstrap, portability, build, maintenance, bindings) there.

If I recall correctly, Game Of Tree has (had?) some issues.

• Differences in command line arguments (usage other than command git itself).
• Slowness compared to git (if I understand correctly, because of single-threaaded).

The former would cause needs for a kind of wrapper (script or binary) to be compatible with git, not to force existing documents to be rewritten (would be horrible waste of time!).

Not sure the latter is resolved, as I myself not yet tried it (as of the former isssue).

So basically, the tools that "I" use to access git repos are going to be Rust based instead of C/Perl/Python/whatever they are right now?

If I understand the discussion in freebsd-hackers ML correctly, it would be some part of git, not the whole bunch of git.

I don't care what a word processor is coded in as long as it works correctly.

It (usually) depends on how reliable the external crates used are, too.

Just my personal opinion, but crates provided via official repo for crates should be thoroughly audited by the Rust devs (and/or "SHALL-BE-RELIABLE third parties like ISO, IEC, ANSI, MIL, JIS, ...) on first registration and EVERY SiNGLE UPDATES, and only passed and considered SAFE ones are provided (anything that vulnerabilities are found should be blocked to be downloaded until it is fixed and passed audits).

I usually don't say such a things, but any language (including its [semi-]official ecosystem) stating memory "SAFETY" should kept to be SAFE (at least what it states "safe" like "memory safe").

 

[cracauer@]

So basically, the tools that "I" use to access git repos are going to be Rust based instead of C/Perl/Python/whatever they are right now?
If that is what they're are doing, does it really matter to a user as long as the tools work correctly?

The most immideate consequence is that if you build git from ports you also build Rust as a build dependency. That makes it "slightly" slower.

Did they make any statements about what kind of git code should use Rust?

 

[drhowarddrfine]

The most immideate consequence is that if you build git from ports you also build Rust as a build dependency. That makes it "slightly" slower.

And significantly larger to use git.

 

[T-Aoki]

And significantly larger to use git.

Unless installing Rust itself via pkg.
And at least some of pure Rust consumers take significantly long build time, i.e., x11/wezterm.

 

[bakul]

# pkg install rust
...
The process will require 1 GiB more space.
...
# ldd /usr/local/bin/rustc
librustc_driver-710b6e98787b0886.so => /usr/local/bin/../lib/librustc_driver-710b6e98787b0886.so (0x347188a00000)
...
# ls -lh /usr/local/lib/librustc_driver-710b6e98787b0886.so
-rw-r--r-- 1 root wheel 192M Sep 12 23:15 /usr/local/lib/librustc_driver-710b6e98787b0886.so
....
# size /usr/local/bin/rustc
text data bss dec hex filename
1727 600 1072 3399 d47 /usr/local/bin/rustc


# pkg install v
...
The process will require 38 MiB more space.
...
# ldd /usr/local/bin/v
... [nothing v specific as v itself is transcompiled to c]
# size /usr/local/bin/v
text data bss dec hex filename
4185482 18444 9008 4212934 4048c6 /usr/local/bin/v