
Gitoxide: Pure Rust Implementation of Git - todsacerdoti
https://github.com/Byron/gitoxide
======
dang
All: Rust has clearly reached the now-it's-a-flamewar-trigger stage of the
hype cycle. Nobody wants that. If you're posting to HN, please stick to
interesting specific things, not boring generic ones.

Programming language flamewar is not interesting, so please don't do it here.

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

~~~
pdimitar
This is really saddening to hear.

I am one of the devs who got attracted to Rust's advantages over C/C++ (no
double free or use after free, guaranteed memory ownership, relatively
fearless concurrency) and have been using it increasingly to the point of now
professionally working with it.

But I never felt the need to degrade others for not using it. I do have my
strong opinions about when and where it should be used but I almost never
escalate them to flaming (sadly it occasionally happens even to the best
humans).

I'd hate it if such an excellent technology's well-deserved adoption is held
back because its core user base is viewed as zealots.

:(

------
ByronBates
I am the author, and will be here for a few hours in case there are any
questions.

(proof: [https://keybase.io/byronbates](https://keybase.io/byronbates))

~~~
robert_foss
How does gitoxide perform compared to c-git? A slow operation I often
encounter is `git log --graph` for example.

~~~
ByronBates
Unfortunately I can't yet tell, as the corresponding code does not yet exist.
Object and pack lookup is competitively fast so I would hope that translates
well to everyday operations like that.

Actual numbers for what's there, pack access and traversal, can be found here:
[https://github.com/Byron/gitoxide/issues/1](https://github.com/Byron/gitoxide/issues/1)
and here:
[https://github.com/Byron/gitoxide/issues/5](https://github.com/Byron/gitoxide/issues/5)

------
dhbradshaw
There are several comments on the value of having this project be "pure rust".

Based on my experience, the main value is that it makes this code easily
portable.

Meaning, if you can compile rust on your device, you can just run this code
without worrying about also installing and appropriately linking the correct
version of some C library. It's a huge convenience.

Of course, this only works if all dependencies are also pure Rust. I haven't
verified that this is the case here. Here's hoping!

~~~
amelius
I think that ANSI-C is a lot more portable than Rust, to be honest.

~~~
steveklabnik
It depends on what exactly you mean by "portable." This is an extremely
complicated space with a ton of interlocking dependencies, but here are two
axes on which you could make opposite claims, and be correct:

* C is more portable than Rust because there are C compilers available for more platforms than there are Rust compilers for Rust platforms.

* Rust is more portable than C because Rust programs tend to be written in a more platform agnostic way, and are therefore more likely to be able to work on platforms that they weren't originally intended for.

(To make the second point more concrete, as a Windows user, pure Rust programs
almost always Just Work for me, but as soon as we get into C dependencies, it
becomes way, way way worse.)

~~~
kazinator
No, no, ... Turbo Pascal is what is more portable than C.

Proof: just look at graphics. You just write your graphics code in a platform-
independent way and use the correct .BGI file for your graphics hardware.

And it's safe: no pointer arithmetic or void; real array passing. Module
system for dependencies. No makefiles needed. No problem of linking a stale
object file that didn't get rebuilt due to a missing dependency rule.

Turbo Pascal is the golden future, my friends.

------
kanobo
If you're interested in a step-by-step guide on how to build your own git from
scratch, this book is excellent and incredibly educational:
[https://shop.jcoglan.com/building-git/](https://shop.jcoglan.com/building-
git/)

~~~
pankajdoharey
Trust me its way easier than you think and there are tons of free resource
available you dont need a $36 book to build git.

~~~
stdbrouw
You probably misunderstood: they're not talking about building from source
(which is easy), but rather about recreating Git from scratch in another
programming language (which is hard).

~~~
pankajdoharey
No I understood, and it is still easy.
[https://news.ycombinator.com/item?id=19386141](https://news.ycombinator.com/item?id=19386141)

[https://youtu.be/MYP56QJpDr4](https://youtu.be/MYP56QJpDr4)

~~~
kanobo
I didn't watch the video but I've gone through that guide you linked, it's
excellent but I don't think it's a great comparison. It only implements a
handful of commands and doesn't go into the same amount detail. The Building
Git book goes way more into the interesting bits.

~~~
pankajdoharey
My whole point was it is way easier than one thinks and there are good free
resources available. Once you do the basic of git filesystem , object storage
and sha basics implementing the rest of the API is trivial in comparison.

~~~
kanobo
It's true that you can find most content somewhere freely available in various
disparate corners of the web and everything is trivial if you have the info...
but that's a strange reason to automatically reject a book you haven't read.

------
rich_sasha
Does this address the cryptic-ness of git commands? E.g. are the various
commands we all know and love like `git reset HEAD`, `git co --track
origin/branch` etc. made clearer?

Even after years of using git, this is for me a major pain point.

~~~
letmeinhere
A stated goal is

> a simple command-line interface is provided for the most common git
> operations, optimized for user experience. A simple-git if you so will.

But an explicit non-goal is

> replicate git command functionality perfectly git is git, and there is no
> reason to not use it. Our path is the one of simplicity to make getting
> started with git easy. a simple command-line interface is provided for the
> most common git operations, optimized for user experience. A simple-git if
> you so will.

So it depends. They may refine some parts of the UX, others may be identical,
and other still will be left unimplemented because git still exists.

~~~
Communitivity
Git achieves that stated goal, to a degree, via git alias. You can define your
own simple versions of the commands or shortcuts.

What you've done is awesome!

What I would love to see is a pure-Rust reproduction of the git commands we
know, some simple-git flavor commands, a Git API we can call from Rust, and
the ability to add new Rust written git commands. I would love to put my money
where my mouth is and volunteer to help, but my job right now is consuming all
of my time not spent on family.

~~~
rich_sasha
Git alias is bittersweet to me, much the same as various GUIs on top of VCS,
like magit in Emacs etc. They give you a simplified interface to a subset of
the functionality. But when you need to escape out of that, suddenly you need
to use the full complex solution, and without the constant training of using
the 'real deal'. I see git aliases in the same category. Gitoxide sounds a lot
more complete.

Furthermore, git aliases work on your machine. Then you ssh to a server and
suddenly `git please-do-my-command-without-many-weird-options` don't work. Yes
you can sync them, but not super-easily. Whereas a complete tool you can just
distribute onto the machines you work on. Not entirely different, but not the
same either.

------
renewiltord
Fascinating, this doesn't use `libgit2` anywhere. I didn't expect that. Very
cool.

~~~
EE84M3i
What did you expect instead from "pure rust"?

~~~
dragonsh
Not sure what is meant by pure, probably another way of marketing to Rust
aficionados. It uses crates which still rely on unsafe ‘C’ code to interact
with operating system for interacting with files and file related OS calls.

It will be nice instead of proclaiming Rust as “C” replacement it should have
positioned as “A language complementing C/C++ to write safe code”.

Recently Servo project is abandoned by Mozilla for which Rust is a primary
language.

Now need to see, if Rust can fulfils it’s primary objective to write Firefox
in Rust, it looks more remote now. So it will take much longer for Rust to
become as ubiquitous and important as Go language for systems programming.
Probably Microsoft and others might pick to write some core new systems in
Rust, instead of just rewriting same working C/C++ code in Rust for marketing
purposes.

~~~
oblio
> Not sure what is meant by pure, probably another way of marketing to Rust
> aficionados.

"Pure" is not some Rust marketing ploy :-)

It's a pretty established term meaning "written only with". I've seen pure
Python, pure PHP, pure JavaScript, etc libraries and apps.

It generally means you don't need another compiler to build or you don't need
to know another language to contribute or fix things for yourself.

~~~
dragonsh
Rust market itself as replacement for C/C++ and proclaims as if all code
written in C/C++ is garbage and only Rust can solve it, when majority of it's
own useful crates heavily rely on unsafe "C/C++" code.

So "Pure Rust" is also marketing when you look at the crates used by this
software are not Pure Rust, but rely on unsafe code of C underneath.

Python, PHP do not claim as C/C++ replacement, indeed Python is synonymous
with CPython written in C.

In Rust community so far what I noticed is that they try to down-vote anything
which shows them that Go language or Swift are more important systems
programming language and Rust needs another 10 years to reach to write enough
useful software like Go or Swift.

Also in Python look at the example of pure python HTTP server Cheroot [1] and
check how many PyPI packages it relies on. Also it can run in CPython, PyPy or
Jython or any implementation of Python. Rust does not have anything like this
yet so using Pure is misleading given it only has one compiler dependent on
LLVM (written in C++) to generate target binary.

[1] [https://github.com/cherrypy/cheroot](https://github.com/cherrypy/cheroot)

~~~
oblio
Are you a C programmer threatened by the emergence of a C competitor? I have
nothing to gain by "promoting" Rust as I'm not a Rust dev. You have commented
a lot in these threads to complain about Rust.

If I'm right remember that both your self worth and your employability are
ultimately not tied to C. Programmers switching programming languages are not
life long miners that have to turn overnight into lawyers. You start building
something with Rust and you should be operational quite quickly, most of your
skills transfer over.

~~~
dragonsh
> You start building something with Rust and you should be operational quite
> quickly

Rust is anything but easy and simple like Go language.

Please try building something like Kubernetes in Rust instead of Go and you
will realize “Rust” is a a complicated language (worse than complex). Rust has
a steep learning curve and the standard library is quite limited. So you will
need to search and choose from different crates to do eve basic work.
Eventually one can be productive in it after 2-3 years of development.
Compared to it Swift, Go are much easier to pick up as systems programming
language and C++ 20 is advanced enough to write safety critical code. There is
a reason why large body of systems programming and software for
database,network servers is written in Go language not Rust.

~~~
hibbelig
OT: "Steep learning curve". Can someone give me an intuition that explains the
meaning? My understanding is that it means "requires a lot of effort to learn
to some degree", but when I see the words "learning curve", I imagine a graph
with time on the x-axis and knowlege on the y-axis, and when that curve is
steep, that means you acquire a lot of knowledge in a short time. Which is
kind of the opposite...

Can someone give me an intuition that doesn't clash with the intended meaning
like that?

~~~
CuriousSkeptic
Have the y-axis represent effort required to advance, and x-axis level of
mastery achieved.

F.ex “effort“ could be quantified as topics in a book to cover before being
ready for the next chapter, and “mastery” as simply number of chapters read.

------
MaxBarraclough
How much use of _unsafe_ is there?

'Pure Rust' counts for little if the code overuses Rust's unsafe features.

 _edit_ This was a sincere question. I'm glad the answer turned out to be that
there's very little of it.

~~~
est31
rg "unsafe " | wc -l tells me there are 19 occurences, for about 13.7k lines
of Rust in total. So it's not a lot.

~~~
MaxBarraclough
Good to hear. It's important to ask though.

There was an HN discussion a few months back on a Rust program that overused
the unsafe features, to the point it may as well have been written in C. Sure
enough, it turned out to be full of nasty bugs.

~~~
nindalf
> to the point it may as well have been written in C

Mildly disagree. Even if half the code base is unsafe, that's better than a
code base where everything is unsafe. Now I only have to audit half the code
base for crazy shit, which is about half the effort. A stronger type system
means that even in unsafe land, we can still encode some invariants better.

I disagree with this notion that "if you're going to have bugs anyway, what's
the point of Rust". Our goal isn't to eliminate every bug in the world, it's
to have fewer bugs today than we did yesterday. Rust, even Rust with several
unsafes thrown in, helps us achieve that goal.

~~~
est31
In principle I agree, but note that such projects are not created in a vacuum.
Someone who goes out of their way to put that much unsafe into the codebase is
more likely to commit mistakes that lead to ub than someone who just writes C
stuff.

~~~
nindalf
> Someone who goes out of their way to put that much unsafe into the codebase
> is more likely to commit mistakes that lead to ub than someone who just
> writes C stuff.

[citation needed]. And it would be hard to find a citation because most Rust
codebases don't have much unsafe. The repo you're thinking of was an anomaly
and has since improved a lot.

~~~
pizza234
> I disagree with this notion that "if you're going to have bugs anyway,
> what's the point of Rust" [...] [citation needed]

Well, this can be related to an actual real-world concept, that is
"programming in a certain language with the syntax/runtime of another".

In my experience, all the times I've seen this happening, the project was just
terribly written.

I program in Rust, and if I happened to put an excessive¹ amount of unsafe
code in Rust, it means that simply, I'm not programming in Rust. In my
opinion, in real world this phenomenon happens for beginners, lazy
programmers, or bad programmers, _especially_ for Rust, because it has a steep
learning curve, and it requires an effort, when designing a project, that
other languages don't require.

So there is a point, although theoretical, that a good programmer in an unsafe
language, can produce a more stable project than a bad programmer in a safe
language.

With that in mind, I still wish as others to see unsafe languages disappear
:-)

¹="excessive" is of course subjective.

------
demarq
This was bound to happen at some point

~~~
abdusco
Is there a Rust version of Atwood's Law?

\---

FTI [0]:

> In 2007, Jeff Atwood made the quote that was popularly referred to as
> Atwood’s Law:[5] >> “Any application that can be written in JavaScript, will
> eventually be written in JavaScript.”

[0]:
[https://www.wikiwand.com/en/Jeff_Atwood](https://www.wikiwand.com/en/Jeff_Atwood)

~~~
Kinrany
Atwood's Law 2.0 should probably be about WASM

~~~
nindalf
And there is a language that's pretty good at compiling to wasm.

------
ncmncm
As I have understood it, the major coding flaws in Git involve failure to
handle OS and file system errors responsibly. (The SQLite people are very
persuasive on the topic.) Rust does not seem to bring anything new to this
particular table.

Any improvement in this area would need to inhere in library-level facilities
constructed for the purpose. What are they?

~~~
foota
Rusts good support for option and result types might help here.

~~~
roca
Yes! Rust's error handling story is excellent.

You can still swallow errors if you want to but you have to manually write
unwrap() so it's much more visible.

~~~
ztjio
Not to be overly pedantic but calling .unwrap() is about as far from
swallowing an error as you can get. That's gonna panic right away if it's an
error case.

~~~
roca
Sorry, yes, you're quite right.

