Live data from Hacker News

Gitoxide: Pure Rust Implementation of Git

github.com

91–100 of 200 posts

Re: Gitoxide: Pure Rust Implementation of Git

#91
post #62

Earlier quoted context omitted.

Are you a C programmer threatened by the emergence of a C competitor? I have nothing to gain by "promoting" Rust as I'm not a Rust dev. You have commented a lot in these threads to complain about Rust. If I'm right remember that both your self worth and your employability are ultimately not tied to C. Programmers switching programming languages are not life long miners that have to turn overnight into lawyers. You st…

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

OT: "Steep learning curve". Can someone give me an intuition that explains the meaning? My understanding is that it means "requires a lot of effort to learn to some degree", but when I see the words "learning curve", I imagine a graph with time on the x-axis and knowlege on the y-axis, and when that curve is steep, that means you acquire a lot of knowledge in a short time. Which is kind of the opposite...

Can someone give me an intuition that doesn't clash with the intended meaning like that?

Re: Gitoxide: Pure Rust Implementation of Git

#92
post #15

Earlier quoted context omitted.

I really don't understand the hate towards every language that is not Rust. Rust provide you tools to avoid many security issues. But that does not mean everything that hasn't been written in Rust is broken by default. You still have "unsafe" in Rust, so is it broken by default and design and we should throw away the language ? Obviously not!

As others have said, the issue is with C style memory issues. Rust not only gives you safety and correctness, but gives you often speed as a bonus over C. There is a real benefit towards rewriting everything written in C in a language/tool system like Rust. There is still a place for other languages, especially ones that use a garbage collector. Rust would make that garbage collector a lot safer.

There is no conclusive proof that Rust is faster than C. There are many Medium articles using badly written tests, which don't accurately show either of the languages.

Rewriting all software written in C-family languages would be a disaster. This is the exact thing that people make fun of the Rust Evangelism Strike Force for saying. C is here to stay, and Rust is as well. Many new applications will be written in Rust (not a lot because nobody cares about Rust outside the dweebs on HN), and many will be written in C. Calm down.

Re: Gitoxide: Pure Rust Implementation of Git

#93
post #61

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…

A git repo is often received from untrusted source in internet and there were associated bugs in git.

Re: Gitoxide: Pure Rust Implementation of Git

#94
post #42

This 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

Re: Gitoxide: Pure Rust Implementation of Git

#96
post #94
post #42

This 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

Atwood's Law 2.0 should probably be about WASM

Re: Gitoxide: Pure Rust Implementation of Git

#97

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.

As this is part of the every-day workflow, I will think long and hard on how to make it as painless and user-friendly as possible. Having a more user-friendly experience on the command-line is one of the project goals, and it will also be me benefiting from it so the motivation will be high to achieve it. By then, that thinking process will hopefully be public enough to allow more people to chime in and get a better…

I'm totally looking forward to that then! :)

Re: Gitoxide: Pure Rust Implementation of Git

#98
post #74

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…

Go has much bigger backing that Rust. And most of that server software comes directly from Google or their ecosystem: Kubernetes, Kubernetes appendages, "Cloud Native" stuff. And Swift is only relevant because it's the only modern, officially sanctioned, systems software programming language on 2 platforms: Mac OS and iOS (especially iOS). I know of 0 people who use or have a desire to use it outside of MacOS or iOS.…

> Time will tell

Agree time will tell at present Rust is like other niche systems programming language competing with others like Nim and Zig bit more popular due to Firefox being popular. Nowhere close to Go or Swift, may be in 5 years might have something substantial by Amazon and Microsoft available in open source.

> Go has much bigger backing

Go is popular because it’s easy, simple, performant with opinionated design and similar to Python controlled heavily by its creator. It gets the job done and it’s syntax can fit in brain, without fighting the language itself.

It has very good standard library.

It is adopted more outside of Google than inside.

Simplicity is easier said than done and Go language did it quite well. It’s like Apple devices and OS beautiful and simple, which works but some just hate it.

Rust doesn’t aim to be simple and easy, as it makes people in Rust community feel superior to other programmers by virtue of showing it as complex and difficult.

You can see example of this in this thread any comments critical of Rust pointing its shortcomings is downvoted because it’s difficult to digest how the best and safe language for systems programming can have any shortcomings.

I don’t mind working in Rust (indeed tried some simple examples and didn’t find any feature special what I can’t do in other languages including safety). I also learned Haskell (which is more complex than Rust) and Lisp (like it more because of its simplicity).

Re: Gitoxide: Pure Rust Implementation of Git

#99

Earlier quoted context omitted.

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…

Git alias is bittersweet to me, much the same as various GUIs on top of VCS, like magit in Emacs etc. They give you a simplified interface to a subset of the functionality. But when you need to escape out of that, suddenly you need to use the full complex solution, and without the constant training of using the 'real deal'. I see git aliases in the same category. Gitoxide sounds a lot more complete.

Furthermore, git aliases work on your machine. Then you ssh to a server and suddenly `git please-do-my-command-without-many-weird-options` don't work. Yes you can sync them, but not super-easily. Whereas a complete tool you can just distribute onto the machines you work on. Not entirely different, but not the same either.

Re: Gitoxide: Pure Rust Implementation of Git

#100

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…

OT: "Steep learning curve". Can someone give me an intuition that explains the meaning? My understanding is that it means "requires a lot of effort to learn to some degree", but when I see the words "learning curve", I imagine a graph with time on the x-axis and knowlege on the y-axis, and when that curve is steep, that means you acquire a lot of knowledge in a short time. Which is kind of the opposite... Can someone…

Have the y-axis represent effort required to advance, and x-axis level of mastery achieved.

F.ex “effort“ could be quantified as topics in a book to cover before being ready for the next chapter, and “mastery” as simply number of chapters read.

Post reply on HN