Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Rust seems like a good language for git given its performance and memory-safety, no?


Actually any high performance GC'd languages would be fine too because latency is a non-issue for long running git operations (you won't notice if your git clone pauses for 100ms, whereas you will notice if your UI does). Throughput of malloc() and GCd languages tends to be similar when latency isn't a concern.


GC is only part of the equation. I have always found this article informative: https://marc.info/?l=git&m=124111702609723&w=2

Performance for higher-level languages is usually great in-so-far as you're able to essentially write C code in that higher level language. When the language's limitations inhibit you from writing the C code you want to write, performance usually suffers. In java's case, lack of value types and stack allocation can be a major performance hindrance. Boxing is also a problem, although, as the mailing list post notes, this is easily overcome-able via manual specialization.


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.


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.


Just how big is your repo that, other than cloning, git operations induce user-noticable performance problems?


On the other hand, if you can make git faster and safer, why not?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: