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

131–140 of 200 posts

Re: Gitoxide: Pure Rust Implementation of Git

#131

Post by dragonsh »

steveklabnik wrote: post #105
dragonsh wrote: post #102

Earlier quoted context omitted.

> 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 Your assertion is not true in C/C++ community, but “Rust is good and C or any other systems programming language is bad” is common assertion in Rust community. Most C/C++ programmers will not mind writing handcrafted assembly. Seen plenty of such examples in game…

Rust's inline assembly used to be the exact same as clang's. We recently merged a slightly different version, in the hopes of stabilizing that feature. It ends up pretty similar. (I've been writing a bunch of inline assembly lately, and in fact, ported some C inline asm to Rust. It's not exactly identical, and I did in fact introduce a small bug when doing so...)

It’s good Rust adopted C style handcrafted assembly, earlier didn’t expect it given emphasis on safety at any cost as handcrafted assembly is a dual-edged sword it can help with performance and direct access to hardware, but can also introduce bugs.

Porting code will have some stumbling blocks, but given enough time and some resources those mountains can be crossed and may uncover new trail and then leave the ropes for other climbers.

Personally I am from the camp who likes the simplicity of lisp. That’s one of the reason in spite of learning some Haskell to learn about FP, didn’t continue long although I like Haskell’s brevity as in “Brevity is the soul of wit”. Haskell really makes it easy to refactor the code, but given large surface area makes it hard to learn and develop. Rust felt the same way although recently saw it becoming more approachable and easy.

I was pondering recently if built a modern lisp machines, how good it will be. A hardware directly controlled from lisp instead of C.

Re: Gitoxide: Pure Rust Implementation of Git

#132

Post by bronson »

dragonsh wrote: post #102
jevgeni wrote: post #82

Earlier quoted context omitted.

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

> 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 Your assertion is not true in C/C++ community, but “Rust is good and C or any other systems programming language is bad” is common assertion in Rust community. Most C/C++ programmers will not mind writing handcrafted assembly. Seen plenty of such examples in game…

It would have taken you less time to google ‘rust inline assembly’ than to write this comment.

Re: Gitoxide: Pure Rust Implementation of Git

#133

Post by steveklabnik »

dragonsh wrote: post #131
steveklabnik wrote: post #105

Earlier quoted context omitted.

Rust's inline assembly used to be the exact same as clang's. We recently merged a slightly different version, in the hopes of stabilizing that feature. It ends up pretty similar. (I've been writing a bunch of inline assembly lately, and in fact, ported some C inline asm to Rust. It's not exactly identical, and I did in fact introduce a small bug when doing so...)

It’s good Rust adopted C style handcrafted assembly, earlier didn’t expect it given emphasis on safety at any cost as handcrafted assembly is a dual-edged sword it can help with performance and direct access to hardware, but can also introduce bugs. Porting code will have some stumbling blocks, but given enough time and some resources those mountains can be crossed and may uncover new trail and then leave the ropes f…

> safety at any cost

This is not Rust's position on safety. Rust's position is that you should be able to isolate unsafe parts of your program. And we try to give you tools to make them as small as possible. But unsafe stuff was deliberately included in Rust, on purpose, as a tool to be used.

I also wonder what a modern lisp machine might look like. Oh well, I don't suspect that will ever happen.

Re: Gitoxide: Pure Rust Implementation of Git

#134

Post by viraptor »

pankajdoharey wrote: post #122
kanobo wrote: post #6

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/

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.

I noticed you haven't linked any of them.

Re: Gitoxide: Pure Rust Implementation of Git

#135

Post by ByronBates »

littlestymaar wrote: post #120
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.

I'd be interested to know what, according to you, are the worst part of git commands (I'm currently trying to figure out a better CLI on top of libgit2).

Let me reply with the most tedious parts, as I wouldn't want to make the impression of labelling git as 'bad' - I have been fascinated by it for more than 10 years now and it's time to scratch my itch for good.

Please note that everything I name can certainly be fixed by some tool that already exists, and that's great. It's just that I would like to have 'this one tool' that gets most things right and be happy with it alone.

That said, here is my list:

* adding individual files to the staging area/index

* looking at the commit history and copying individual commit hashes

* pulling while assuring no merge commit is created, or: simplified trunk-based development

* resumable clones

* seeing what's going on during all remote operations - here in China GitHub is incredibly slow most of the time and connections can be flaky

Re: Gitoxide: Pure Rust Implementation of Git

#136

Post by NationalPark »

non-entity wrote: post #112
atoav wrote: post #3

Earlier quoted context omitted.

Because it is a interesting excercise to reimplement something great in a new interesting language you wanna test drive? Why are people writing new programming languages? After all we already have some. Sometimes you do it for fun and frivolity, sometimes because you think you can do better, sometimes because you are addressing real tangible issues with the old way of doing things and often a combination of the three…

Honestly I used to find the "rust evgangelism strike force" obnoxious and naive, but man, after reading this thread and seeing all these brand new accounts that seemingly have nothing to do but complain because someone used Rust in a neat project, I'm honestly starting to think their attitude is 10x more obnoxious.

As we used to say, "haters gonna hate". It used to annoy me but now I mostly ignore it. If other people don't see the value in technical novelty that isn't directly in service of making money or having enormous impact otherwise, that's their loss - I'd rather spend my time hacking on something cool than defending the practice to someone who starts the conversation on the defensive.

Re: Gitoxide: Pure Rust Implementation of Git

#138

Post by gpanders »

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.

Note that git itself is beginning to address this exact problem by introducing new, more intuitive commands such as "restore" and "switch".

Re: Gitoxide: Pure Rust Implementation of Git

#139

Post by 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!

Post reply on HN