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

171–180 of 200 posts

Re: Gitoxide: Pure Rust Implementation of Git

#171

Post by kazinator »

garmaine wrote: post #153
amelius wrote: post #144

Earlier quoted context omitted.

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…

Static linking means that if a security flaw is found in a dependent component, you're responsible for shipping a whole new application binary to the end users; they can't just pick up some new shared libs from upstream of you.

Re: Gitoxide: Pure Rust Implementation of Git

#172

Post by kazinator »

steveklabnik wrote: post #145
amelius wrote: post #144

Earlier quoted context omitted.

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

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.

Re: Gitoxide: Pure Rust Implementation of Git

#173

Post by littlestymaar »

ByronBates wrote: post #135
littlestymaar wrote: post #120

Earlier quoted context omitted.

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

Thanks! That's really interesting to see that only 2 of your list (around adding and pulling) were on my radar as git usability issue, and not even in my top five!

The third one is a bit unclear to me:

> looking at the commit history and copying individual commit hashes

What do you mean exactly by that?

Re: Gitoxide: Pure Rust Implementation of Git

#174

Post by steveklabnik »

kazinator wrote: post #170
bluejekyll wrote: post #146

Earlier quoted context omitted.

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.

The problem is that this requires the Rust run-time to be a ball of mud that provides everything for everyone. Where is the Rust compiler for a Motorola 68K? How about PIC24? And if there is ever a Rust compiler for PIC24, what will happen to all that run-time support? How much of it will work? How will you detect what of it works and what doesn't, in order to work around for it in your program?

Rust has barely more of a runtime than C. And if you're not using the standard library, it has the same amount.

Someone was working on a 68k port. I am not sure what its status is today.

PIC24 should be totally possible; we have AVR support in nightly now, which is also a 16 bit platform.

Re: Gitoxide: Pure Rust Implementation of Git

#175

Post by kazinator »

steveklabnik wrote: post #174
kazinator wrote: post #170

Earlier quoted context omitted.

The problem is that this requires the Rust run-time to be a ball of mud that provides everything for everyone. Where is the Rust compiler for a Motorola 68K? How about PIC24? And if there is ever a Rust compiler for PIC24, what will happen to all that run-time support? How much of it will work? How will you detect what of it works and what doesn't, in order to work around for it in your program?

Rust has barely more of a runtime than C. And if you're not using the standard library, it has the same amount. Someone was working on a 68k port. I am not sure what its status is today. PIC24 should be totally possible; we have AVR support in nightly now, which is also a 16 bit platform.

Yet, it was claimed in the grandparent, that "Once you start depending on platform features, in my experience, the portability of Rust is superior" (because of no #ifdef crud and library versions and whatnot).

Maybe what it really means is that "once you start depending on platform features, the portability of Rust to a handful of mainstream platforms which have all those features in slightly varying flavors is cleaner due to some layering".

You don't have annoyances like, oh, foo_t requires on this platform, but on that other one it was already exposed in .

Re: Gitoxide: Pure Rust Implementation of Git

#176

Post by bluejekyll »

kazinator wrote: post #175
steveklabnik wrote: post #174

Earlier quoted context omitted.

Rust has barely more of a runtime than C. And if you're not using the standard library, it has the same amount. Someone was working on a 68k port. I am not sure what its status is today. PIC24 should be totally possible; we have AVR support in nightly now, which is also a 16 bit platform.

Yet, it was claimed in the grandparent, that "Once you start depending on platform features, in my experience, the portability of Rust is superior" (because of no #ifdef crud and library versions and whatnot). Maybe what it really means is that "once you start depending on platform features, the portability of Rust to a handful of mainstream platforms which have all those features in slightly varying flavors is clean…

I thought that was implied by the statement I made about C without dependencies being more portable.

In any case. You’re not wrong. We can caveat everything about Rust as “for the platforms it supports”, and in this context it is more enjoyable to work with across those platforms. And for all of my development needs, it targets everything I work with.

C is more portable as a language, but that's never been up for debate.

Re: Gitoxide: Pure Rust Implementation of Git

#177

Post by kazinator »

bluejekyll wrote: post #176
kazinator wrote: post #175

Earlier quoted context omitted.

Yet, it was claimed in the grandparent, that "Once you start depending on platform features, in my experience, the portability of Rust is superior" (because of no #ifdef crud and library versions and whatnot). Maybe what it really means is that "once you start depending on platform features, the portability of Rust to a handful of mainstream platforms which have all those features in slightly varying flavors is clean…

I thought that was implied by the statement I made about C without dependencies being more portable. In any case. You’re not wrong. We can caveat everything about Rust as “for the platforms it supports”, and in this context it is more enjoyable to work with across those platforms. And for all of my development needs, it targets everything I work with. C is more portable as a language, but that's never been up for deb…

For suitable values of someone, Visual Basic embedded in Excel targets everything someone works with and they are happy.

In C there are also portability libraries. So for instance, suppose you want to do asynchronous I/O with sockets on a few contemporary platforms. You could do all the hard work and make it work with kevent on BSD, epoll_wait there, or I/O completion ports on Windows, with some select and poll based fallback cases.

Or you could just use, whatsitcalled, ... libuv and follow its API. Libuv has the grotty multiple implementations of the same thing in three or four ways, and ifdefs and whatever, so you don't have to.

Then you're into problems like: do you build libuv yourself and ship that? Or do you rely on the upstream one available in some of your target platforms, and which version will that be, and will that cause issues. It's going to be dynamically linked, so users can run with a different version than what you tested with as they update their systems.

But that's just due to having more choices.

If libuv weren't widely adopted, then that would be easier: there is no platform version of libuv. You want it, you build it yourself. You choose the version, pin to that, and you control if/when you update.

All that complexity is from more independent parties being at the table. It's not just you, Developer versus some Mother Ship (language that provides everything, including platform stuff).

Re: Gitoxide: Pure Rust Implementation of Git

#178

Post by bluejekyll »

kazinator wrote: post #177
bluejekyll wrote: post #176

Earlier quoted context omitted.

I thought that was implied by the statement I made about C without dependencies being more portable. In any case. You’re not wrong. We can caveat everything about Rust as “for the platforms it supports”, and in this context it is more enjoyable to work with across those platforms. And for all of my development needs, it targets everything I work with. C is more portable as a language, but that's never been up for deb…

For suitable values of someone , Visual Basic embedded in Excel targets everything someone works with and they are happy. In C there are also portability libraries. So for instance, suppose you want to do asynchronous I/O with sockets on a few contemporary platforms. You could do all the hard work and make it work with kevent on BSD, epoll_wait there, or I/O completion ports on Windows, with some select and poll base…

What is your point here?

We all know that C is portable and has many libraries that support that. The statement is that Rust is in the opinion of many of us that have experience with porting both languages to multiple platforms, that Rust is easier.

mio is the portable library many use in Rust for IO across multiple platforms, it's used by Tokio and other async frameworks to support async-io.

And, yes, if something doesn't exist you must build the support for it. This is true for anything? It feels like you're trying to change the goal posts on the discussion, to be one of library support now. But luckily in Rust, we have bindgen that makes it relatively painless to support C libraries when you want the "easy" path to getting libraries that are implemented there, but not yet in Rust.

Re: Gitoxide: Pure Rust Implementation of Git

#179

Post by bluejekyll »

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 might have missed your attention to this thread, but I'll ask and hopefully you'll be able to check later. I have to deal with a monolithic codebase that is of excessive size (10's of millions of lines of code) and has a very large number of developers committing against it.

I haven't looked at the internals of Git much, but performance becomes an issue with it in this context (we currently use a different vcs), and switching seems impractical at the moment. Issues from local performance (30 seconds or so for git status, git checkout, etc) and clone/fetch speeds.

I'm curious, given your experience on porting, have you noticed areas where we might be able to make improvements that might be easier based on Rust's safety improvements? Such as more threading or other areas that could improve Git for use with very large code bases?

(I plan to review the project as this would be an exciting area to work in to help with productivity in this space)

Re: Gitoxide: Pure Rust Implementation of Git

#180

Post by steveklabnik »

kazinator wrote: post #175
steveklabnik wrote: post #174

Earlier quoted context omitted.

Rust has barely more of a runtime than C. And if you're not using the standard library, it has the same amount. Someone was working on a 68k port. I am not sure what its status is today. PIC24 should be totally possible; we have AVR support in nightly now, which is also a 16 bit platform.

Yet, it was claimed in the grandparent, that "Once you start depending on platform features, in my experience, the portability of Rust is superior" (because of no #ifdef crud and library versions and whatnot). Maybe what it really means is that "once you start depending on platform features, the portability of Rust to a handful of mainstream platforms which have all those features in slightly varying flavors is clean…

I mean, rust does have the equivalent of #ifdef. There are platform-specific things.

It's just that, with the benefit of hindsight, we designed support in three major layers:

* core, which only relies on there being like, a symbol for memcpy

* alloc, which gives you a heap

* std, which gives you operating system-dependent features

Based on this hierarchy, a lot of libraries that are OS dependent may use only core, or core + alloc. And way more crates do this than you might think, and it's pretty easy to move a crate to them if they truly don't need all that libstd has to offer.

Post reply on HN