Earlier quoted context omitted.
Trees are easy in Rust. It's graphs that are harder.
Git “trees” are graphs though, since you have merge commits.
More to the point, they are DAGs. Git objects cannot form a loop, thus they are acyclic.
Git implemented in Rust
111–120 of 122 posts
Re: Git implemented in Rust
#112I love to see people reimplementing existing tools on their own, because I find that to be a great way to learn more about those tools. I started on a Git implementation in Rust as well, though I haven't worked on it in a while: https://github.com/avik-das/gitters
Are you basing it off anything in particular? Like outside of just going through gits own source code?
I haven't even looked at the git source code. My implementation was based mostly on the official docs. The docs include a section on the internals: https://git-scm.com/book/en/v1/Git-Internals
Re: Git implemented in Rust
#113Rust seems like a good language for git given its performance and memory-safety, no?
Just how big is your repo that, other than cloning, git operations induce user-noticable performance problems?
Re: Git implemented in Rust
#114Re: Git implemented in Rust
#115Earlier quoted context omitted.
> Implementing git in rust for fun and education! Also, not having a license file isn't a messy situation, that means “this project is protected under Berne Convention copyright“: the author is the only one holding every rights on the code and every use that is not explicitly allowed is a copyright infringement (unless it's fair use).
That sounds nice and all but it's wrong in two major ways. First: GitHub has a Terms of Service which was somewhat-recently amended to make this license grant explicit: https://help.github.com/en/articles/github-terms-of-service#... "Any User-Generated Content you post publicly, including issues, comments, and contributions to other Users' repositories, may be viewed by others. By setting your repositories to be view…
Aside: "you agree to.." is not automatically enforceable in this kind of ToS.
Re: Git implemented in Rust
#116Earlier quoted context omitted.
Fair Use doesn't exist in many jurisdictions.
It isn't called that way and doesn't offer the same amount of protection everywhere, but the Berne convention itself includes copyright exceptions [1] that I included in the broad “fair use” phrase. [1] https://en.wikisource.org/wiki/Convention_for_the_Protection...
Not the op, but it seems your linked bit of the BC justsays that countries are allowed to legislate exceptions. The only hardcoded exception is the short citation one.
Re: Git implemented in Rust
#117Re: Git implemented in Rust
#118Earlier quoted context omitted.
I was speaking more to stability. Rust is designed to be an incredibly safe language without sacrificing any performance; that seems like a good match for a version-control system.
Most GC'd languages are also memory safe.
FYI, Rust's safety goes beyond that. Its ownership model keeps you safe from data races, unlike, to my knowledge, GC languages.
Re: Git implemented in Rust
#119Earlier quoted context omitted.
Most GC'd languages are also memory safe.
FYI, Rust's safety goes beyond that. Its ownership model keeps you safe from data races, unlike, to my knowledge, GC languages.
IIRC Rust's safety is provided by affine types; all languages with affine or linear types can provide the same guarantees Clean and Mercury both come to mind of the top of my head (IIRC Clean had "Concurrent" in its name at one point), and I think there are both Haskell and F# variants with either affine or linear types.
In addition there are many other solutions to safe parallelism and/or concurrency, some of which don't require a type system at all; Erlang is famous for safe concurrency and is untyped.
Lastly, there's good old fashioned multiprocessing which can be safe just by not sharing memory.
There is no one feature that is new in Rust, but it has a relatively unique set of features in the non-GC language world; ATS is the only one coming to mind, though I'm sure there are some other niche ones.
I love this combination in rust because latency sensitive operations in GCd languages are notoriously hard to achieve. Lisp was able to be an operating system because nobody needed to run quake at 100fps on a lisp machine. With GC you can pick latency or throughput but can't reliably get both without coding around the GC.
This does mean for me that when considering things that rust is particularly good at, latency sensitive applications stand out; this is not to say it's bad at non-latency sensitive applications, just that one has a lot more choices when latency is a non-issue.
Re: Git implemented in Rust
#120Earlier quoted context omitted.
Git “trees” are graphs though, since you have merge commits.
More to the point, they are DAGs. Git objects cannot form a loop, thus they are acyclic.
That's absolutely correct. And your emphasis on this is on point, since DAG are relatively easy to implement in Rust: You just need to use ref-counting (instead of plain `Box` for a Tree) whereas general purpose graphs are harder to implement (and can lead to run-time bugs if node deletions aren't managed properly).