Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gitoxide: Pure Rust Implementation of Git

github.com

Post reply on HN
Print view View original

81–90 of 200 posts

Re: Gitoxide: Pure Rust Implementation of Git

#81

Post by Communitivity »

letmeinhere wrote: post #77
rich_sasha wrote: post #49

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.

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 commo…

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.

Re: Gitoxide: Pure Rust Implementation of Git

#82

Post by jevgeni »

dragonsh wrote: post #58
oblio wrote: post #35

Earlier quoted context omitted.

> 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.

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 synonym…

C/C++ market itself as replacement for assembly languages and proclaim as if all code written in assembly languages is garbage and only C/C++ can solve it, when majority of it's own useful libraries heavily rely on unsafe assembly code.

So "Pure C/C++" is also marketing when you look at the libraries used by this software are not Pure C/C++, but rely on unsafe assembly code underneath.

Python, PHP do not claim as assembly replacement, indeed Python is synonymous with CPython which is ultimately written in an assembly language.

Also, C/C++ relies on LLVM, which runs on assembly language to generate the target binary.

Re: Gitoxide: Pure Rust Implementation of Git

#83

Post by jevgeni »

hnarn wrote: post #76
dragonsh wrote: post #72

Earlier quoted context omitted.

> 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…

> Rust is anything but easy and simple like Go language. Rust sure isn't "simple" for anyone, but if you are a C/C++ developer, I'd definitely expect someone who's been writing C code for more than a few years to be able to pick up basic Rust in a few weeks. Instead of being threatened by other languages and rationalizing why it's not worth picking up, why not spend a few weeks on it so you can have an informed opini…

I think lifetimes are tripping dragonsh up.

Also, C++ is a waaay more quirky and complex language. Can't see why C++'s complexity is fine, but Rust's (lower) complexity isn't.

Re: Gitoxide: Pure Rust Implementation of Git

#84

Post by gpm »

rsa25519 wrote: post #48
rhn_mk1 wrote: post #18

Earlier quoted context omitted.

The hate is not towards every language that is Rust, it's against C, at least in this thread. I haven't seen anyone arguing against Python or Java in a Rust thread. Memory-managed languages are already at the memory safety levels comparable to Rust's borrow checker.

> it's against C More specifically, I hope, C++. I like to think of asm, C, and Rust as a trio. C isn't "better" than asm; it just doesn't make sense to use asm when C does the job. And it doesn't make sense to use C when Rust does the job. C++ is where, in almost all scenarios, I draw the line and say, this would be probably be better if new code is written in Rust.

It's generally against both C and C++, because the reason applies to both of them. That reason being that using these languages expose users and the world to huge negative externalities in the form of security vulnerabilities, or alternatively (but resulting in the same conclusion) that the speaker just likes writing correct code.

> And it doesn't make sense to use C when Rust does the job.

There are few jobs left where C can do it and Rust can't, those jobs are generally "well there exists a C compiler for this architecture and not a rust/llvm backend". Rust is generally just as capable as C is at writing low level code. If you're willing to put up with translating macros by hand (or using wrapper functions), it's even capable of integrating with existing C code bases.

Lots of people still prefer C over Rust in various situations where you could use Rust, so I don't think it's a generally accepted fact that "it doesn't make sense to use C when Rust does the job".

Re: Gitoxide: Pure Rust Implementation of Git

#85

Post by jevgeni »

dragonsh wrote: post #60
atoav wrote: post #34

Earlier quoted context omitted.

> Reimplementation relying on unsafe ‘C/C++’ code (as most of the core infrastructure is written in them) is done more for marketing especially among language aficionados. Let's read the page we are talking about to check your judgment: " Project Goals: a pure-rust implementation of git including transport, object database, references, cli and tui " and " Non-Goals: replicate git command functionality perfectly " Doe…

It rely on other crates, have they been verified not to use C/C++ (i.e. all are written from scratch without interacting with C/C++)? This software is as good as the crates it depends on to do those work. If those crates are not maintained this software will not work either. Also I am expecting down-vote of this comments as well given the way Rust community works. :-)

There's valid criticism of Rust and then there's what you are doing, which feels distinctly like flat-earthism of computer science. You pick arbitrary goal posts (like, pretending that "unsafe" isn't a keyword in "real rust") and try use that to discredit a language that a lot of people have found super useful and superior in their work.

Re: Gitoxide: Pure Rust Implementation of Git

#86

Post by ByronBates »

capitol_ wrote: post #78
ByronBates wrote: post #63

I am the author, and will be here for a few hours in case there are any questions. (proof: https://keybase.io/byronbates )

I'm currently using https://github.com/rust-lang/git2-rs to interact with git in my software. Are you aiming to have a stable api that could act as a pure-rust replacement for that at some point in the future?

Absolutely! My plan is to proclaim a version 1.0 once the basic workflow of clone-commit-push can be performed, which should be enough for many to start using it. From that point on, the API should remain stable, following semantic versioning as usual.

It is my hope that the quality and stability will be high enough to convince people [in the Rust ecosystem] to move away from libgit2 and instead contribute to the maintenance and development of gitoxide, rewarding everyone with better performance and improved usability.

Re: Gitoxide: Pure Rust Implementation of Git

#87

Post by [deleted] »

est31 wrote: post #41
MaxBarraclough wrote: post #37

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.

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.

[deleted]

Re: Gitoxide: Pure Rust Implementation of Git

#88

Post by phoe-krk »

hmartins wrote: post #65
phoe-krk wrote: post #56

Earlier quoted context omitted.

They're compilers, not interpreters - or at least SBCL, CCL, ABCL, ECL, Clasp, CLISP, ABCL, and LispWorks are. I'm not aware of any other alive contemporary Common Lisp implementations. Lisp is a memory-safe language with automatic memory management, which removes all of the aforementioned classes of attacks that are available in C. In addition, the Lisp compilers are written in Lisp itself, not in C, which further d…

CCL: Totals grouped by language (dominant language first): lisp: 336793 (84.60%) asm: 30410 (7.64%) ansic: 29862 (7.50%) sh: 718 (0.18%) objc: 299 (0.08%) java: 7 (0.00%) > Lisp is a memory-safe language with automatic memory management, which removes all of the aforementioned classes of attacks that are available in C. Yeah, right.

> Yeah, right.

In Lisp, the programmer never frees memory themselves, so use-after-free and double-free are not triggerable by the user. Bound checks for all array types are in effect, so overflows are impossible. Strong typing and a lack of casting prevent type confusion.

Do you have any arguments other than the unsubstantial "yeah, right"?

Re: Gitoxide: Pure Rust Implementation of Git

#89

Post by phoe-krk »

hmartins wrote: post #64
phoe-krk wrote: post #57

Earlier quoted context omitted.

Sure. Do you have any arguments why it isn't broken and go against the arguments linked in the related HN discussion? Is CPython in some way immune to overflows, use-after-free, double freeing, and so on? How much of CPython is actually implemented in C, and how much in itself and/or in Python?

Why should we care about arguments in a random HN discussion? We should care about arguments from people who have done substantial work. Totals grouped by language (dominant language first): python: 578880 (54.33%) ansic: 475310 (44.61%) sh: 4073 (0.38%) cpp: 3847 (0.36%) asm: 1486 (0.14%) objc: 761 (0.07%) lisp: 502 (0.05%) pascal: 353 (0.03%) xml: 308 (0.03%) csh: 21 (0.00%) Most of pure Python is in the stdlib.

> We should care about arguments from people who have done substantial work.

OK, we can drop the HN comments. Since Stefan Hajnoczi is a substantial QEMU contributor, how would you respond to the arguments linked in http://blog.vmsplice.net/2020/08/why-qemu-should-move-from-c...?

Re: Gitoxide: Pure Rust Implementation of Git

#90

Post by Kaze404 »

linkdd wrote: post #61
anshdgTHa wrote: post #33

Earlier quoted context omitted.

Since the top subthread comment has been predictably flagged by the clique: Rewriting is easier than doing original work. If you manage to get people to use "your" new Rust project, you get a huge payoff for comparatively little work with lots of plagiarizing.

I just think there is more crucial project to rewrite than git, vim, etc... At this point, it's just falling for the hype. The same thing happenned with go, es6, etc... "X is better than Y because it is written in Z" is not a valid argument. A kernel in Rust? Yes please. A browser in rust? Can't wait. A fork of openssl in rust? Yes yes yes. A cli tool? Why? Is it really necessary? And yes it is a genuine question, no…

I don't think every project has to be a crucial endeavor or a new thing. Let people do things for fun.

> A fork of openssl in rust? Yes yes yes.

https://github.com/ctz/rustls

Post reply on HN