I am the author, and will be here for a few hours in case there are any questions. (proof: https://keybase.io/byronbates )
Do you think you'd end up creating C APIs, to make this competitive with libgit2?
Gitoxide: Pure Rust Implementation of Git
151–160 of 200 posts
Re: Gitoxide: Pure Rust Implementation of Git
#152If 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/
For the curious, this guide uses Ruby as the building language.
I've also seen a number of people following along in this book in other languages, including Rust. It really is a well written guide, even if you're not fluent in Ruby.
Re: Gitoxide: Pure Rust Implementation of Git
#153There 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.
Only if you have no dependencies and interact in no way with any platform-specified services.
Now certainly there are platform-specific things with Rust as well, but the defaults are structured in such a way that exposed APIs are more likely than not to be platform independent--you have to go out of your way to break compatibility, rather than it being the default.
And once you get your binary to compile, the static linking means there isn't runtime dependencies that might break either.
The net result is that given a piece of rust code, it is far more likely than its C equivalent to compile on a new platform. And once it does compile, it can be run in any context without concern for differences in the runtime environment. The Rust compiler may target fewer platforms, and therefore be "less portable" in that sense, but if it is a supported backend then it is going to be easier to get the code working.
Re: Gitoxide: Pure Rust Implementation of Git
#154Earlier quoted context omitted.
Why is it even downvoted? Such a downvote heavy community. Plaudits to all involved.
Because pure-rust, as in, not relying on bindings to external git libraries is independent from using "unsafe" in the code. For me the question is misguided. There are reasons to prefer a pure-rust code, even if the whole crate was unsafe.
He thought there would be more weight to having a completely "safe" implementation.
Again, plaudits to all involved.
Re: Gitoxide: Pure Rust Implementation of Git
#155Earlier quoted context omitted.
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…
I think this is a good point, but I think you're mostly talking about building rather than porting. It's way more likely you'll be able to port something from a popular architecture to an obscure one in C because the lingua franca is C, and shipping an architecture generally means shipping C compiler support for it.
I would guess this will slowly change as LLVM gets more backends, but that's pretty hand-wavy. The other option is we move more towards platform monoculture, which is probably more likely? Not sure.
Re: Gitoxide: Pure Rust Implementation of Git
#156There 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.
> Git already runs on more platforms than Rust can target.
cough cough Windows cough
Re: Gitoxide: Pure Rust Implementation of Git
#157I am the author, and will be here for a few hours in case there are any questions. (proof: https://keybase.io/byronbates )
Is native Windows support a goal?
Re: Gitoxide: Pure Rust Implementation of Git
#158This was bound to happen at some point
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
This goes nicely with the old concept that "A sufficiently competent FORTRAN programmer can write FORTRAN code in any language".
Re: Gitoxide: Pure Rust Implementation of Git
#159Earlier quoted context omitted.
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.
> Git already runs on more platforms than Rust can target. cough cough Windows cough
What do you mean? Both Git and Rust run very well on Windows.
Re: Gitoxide: Pure Rust Implementation of Git
#160Earlier quoted context omitted.
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…
I think this is a good point, but I think you're mostly talking about building rather than porting. It's way more likely you'll be able to port something from a popular architecture to an obscure one in C because the lingua franca is C, and shipping an architecture generally means shipping C compiler support for it. I would guess this will slowly change as LLVM gets more backends, but that's pretty hand-wavy. The oth…
(Another option is a gcc frontend for Rust, which the gcc folks have said that they're not opposed to)