Live data from Hacker News

Gitoxide: Pure Rust Implementation of Git

github.com

141–150 of 200 posts

Re: Gitoxide: Pure Rust Implementation of Git

#141

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…

Since some existing tooling - various scripts, GUIs, etc - use the git CLI as an API, it would be pretty cool if a subset of this implementation's commands matched the originals exactly, even if some convenience commands are added on top of that. That would allow it to be slotted-in in many more places

Re: Gitoxide: Pure Rust Implementation of Git

#142
post #121
post #90

Earlier quoted context omitted.

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

I never implied you can't do stuff for fun. Projects done for fun are not "marketed" as "a replacement for X"

I don't see this being marketed as a replacement for Git anywhere.

Re: Gitoxide: Pure Rust Implementation of Git

#143
post #137

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

Hi Byron. What in your opinion would be a good place for someone to start contributing to this?

Right now, the project is clearly missing contribution guidelines, but now that it's a bit more public these will be added soon, possibly along with some tickets that are ready for pickup. For now I am very focussed on implementation. That said, I have created a quick issue for you with a small tasks and high value: https://github.com/Byron/gitoxide/issues/7 Thanks a lot for your consideration <3

Re: Gitoxide: Pure Rust Implementation of Git

#144

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

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

Re: Gitoxide: Pure Rust Implementation of Git

#145

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

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

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

Re: Gitoxide: Pure Rust Implementation of Git

#146

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

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

I find in Rust I have far fewer platform specific switches with #[cfg(Unix)] and the like vs. the number of #ifdef macros in C.

If you’re talking about code portability of pure C, no dependencies, then I agree. Once you start depending on platform features, in my experience, the portability of Rust is superior.

Re: Gitoxide: Pure Rust Implementation of Git

#147

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

The idea that Rust is more portable than C is laughable. C is the most portable language of all time, and Rust has a long way to go to compete. Git already runs on more platforms than Rust can target.

Re: Gitoxide: Pure Rust Implementation of Git

#148

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

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

This is beside the point I was trying to make. The point is that Pure Rust > Rust + Non-Rust dependencies in the sense that it's easier to compile, cross compile, install, or deploy.

If it's pure rust, then I don't have to worry about dynamic or even static linking. I just compile the code for the target and I'm done. Cross compiling becomes simple. Installing becomes simple.

I'm repeating myself a bit here but just to clarify: there's no question that pure C is awesome for portability. And like with Rust it becomes less fun once dynamic linking gets involved.

Re: Gitoxide: Pure Rust Implementation of Git

#149

Earlier quoted context omitted.

> You need something with traction No language has traction, until it does. It would be fair to point out though that Ada has had decades to catch on and replace C, but it hasn't done so, except in certain narrow areas of highly critical embedded software development in aviation and military applications. My understanding is that it's not easy to work with for 'general purpose' work (command-line applications on GNU/…

Well they are trying to reach FOSS community. Recently they started survey asking community "Hello here, we (AdaCore) have some plan for the future of GNAT Community that we want to share and have your opinion on: https://forms.gle/Q34myTCQUXvrva5n7 " There is Ravenports very good port manager written in ada for FreeBSD so ada can be used for CLI apps and has good gtk binding too

A good sign, see also relevant discussion at [0]. I like the idea of a FORTH target that someone suggested.

Are the higher assurance-levels of SPARK going to remain unavailable to FOSS developers, as they apparently are now? [1]

[0] https://groups.google.com/forum/#!topic/comp.lang.ada/M3yS4S...

[1] https://www.adacore.com/sparkpro

Re: Gitoxide: Pure Rust Implementation of Git

#150

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

The idea that Rust is more portable than C is laughable . C is the most portable language of all time, and Rust has a long way to go to compete. Git already runs on more platforms than Rust can target.

It's true that the C language is available on more platforms, including more exotic platforms, than Rust, and that will probably remain true for quite a while. But in another sense, Rust tends to be more portable in practice.

Take a random, non-trivial C program or library and try to compile it for something that's not a Unix (edit: or cross-compile it). How hard is it to do? Now, do the same with a random Rust crate. It's probably a lot easier.

I think there are two key differences. First, Rust has a standard build system (Cargo) that is dominant, while there are many competing build systems for C. Second, the Rust standard library was designed much more recently, and covers far more of the functionality in today's platforms than the C standard library does. (For example, contrast Rust's OsStr and Path types with the pain of supporting Unicode filenames on both Unix and Windows in C.)

Post reply on HN