Git introducing Rust into their base

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.
 
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?
 
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.
 
lost_in_c said:
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.
Click to expand...
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?
 
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.
 
kpedersen said:
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.
Click to expand...
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).

mer said:
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?
Click to expand...
If I understand the discussion in freebsd-hackers ML correctly, it would be some part of git, not the whole bunch of git.

mer said:
I don't care what a word processor is coded in as long as it works correctly.
Click to expand...
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").
 
mer said:
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?
Click to expand...

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?
 
# 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
 
This rust trend has gone too far. Why is it just being added into every single program? I think that if rust ever stabilizes and stops getting updates every 3sec, then they should make the rust compiler use the LLVM copy in base. In my opinion, unless it is necessary, things probably shouldn't require a duplicate LLVM. The ports LLVM should just be maintained for things that rely on the quirks of a specific version.
 
Git was forked by the Xlibre project leader with the goal to continuously provide a Rust free version of Git.

As lead developer Enrico Weigelt states as reason behind the fork: "Making sure Git remains running on any kind of platform and cpu-architecture, as well as realiable and stable, instead of being limited to a few architectures only and depending on a non-trusted compiler that can't even be fully bootstrapped without some untrusted binary."

github.com

GitHub - Libre-WD-40/git: Git with WD-40 applied

Git with WD-40 applied. Contribute to Libre-WD-40/git development by creating an account on GitHub.
github.com github.com
 
people trust a guy who has, more than once, tried to exponentiate in C with the XOR operator, to maintain both an X and git fork? wild.
 
lost_in_c said:
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.
Click to expand...
So Mer's comment is kind of true, except that unfortunately devs adopt strong religious views in favor of specific tools/tech, so what will happen is that the devs will attack features and bugs in the context of "how can I mold my work to fit the new religion's view of the world" instead of "how can I use the new tools to support my existing world view or needs". Look at the absolute crap hardware stack support programs that have grown up around the linux bluetooth and network stacks. The programs just scream "I'm a windoze script kiddy and this is how we write software for windows"
 
kent_dorfman766 said:
So Mer's comment is kind of true, except that unfortunately devs adopt strong religious views in favor of specific tools/tech, so what will happen is that the devs will attack features and bugs in the context of "how can I mold my work to fit the new religion's view of the world" instead of "how can I use the new tools to support my existing world view or needs". Look at the absolute crap hardware stack support programs that have grown up around the linux bluetooth and network stacks. The programs just scream "I'm a windoze script kiddy and this is how we write software for windows"
Click to expand...
Ahh good stuff.
Code, life strong religious/ideology views may tend to stifle advancement (my opinion only) simply because "anyone that disagrees with me is the enemy/wrong/stupid".
In the complete abstract, lets look at "git".
As a user I need to:
git clone
git merge
git update
git commit
git branch
plus a few others (but I think you get the idea).

In order to do these things, does it matter how it's implemented? No, should not, but as pointed out could a git clone be hijacked to support/disavow a specific position? Don't know, I can't see one unless they want every git clone tied to my credit card and making donations.
 
mer said:
In order to do these things, does it matter how it's implemented? No, should not, but as pointed out could a git clone be hijacked to support/disavow a specific position? Don't know, I can't see one unless they want every git clone tied to my credit card and making donations.
Click to expand...
For NetBSD people for example it matters, because they are supporting platforms on which Rust does not exist yet, but they might need/want a working git.
 
You must log in or register to reply here.
Back
Top