Is there any specific reason why Go was chosen to write
Rust provides memory safety without garbage collection, concurrency without data races, and zero runtime overhead (see “Fearless Concurrency with Rust”, “Abstraction without overhead”, and “The Rust Programming Language” book).
Rust provides C-like performance, which is much better than Go (goolge “rust go benchmarks” for references). The
rdedup data deduplication engine is written in Rust.
Is there any specific reason why Go was chosen to write
This is not an answer, but a curious question; With Rust, can you cross-compile out of the box, e.g. like you just set GOOS and GOARCH in Go when building, to produce binaries for other OSs and architectures? That’s one thing I like about Go, a lot. Curious if you can do that with Rust too.
Before I answer your question, I’d like to repeat something else: For this project, the language it is written in is not so important. It is a tool to get the job done. While it’s true that Go’s current popularity helps attracting contributors and we’ve got a nice logo which is derived from the Gopher logo, the language is secondary.
For a backup program in general, and restic in particular, the repository/storage format is the most important thing. That’s why we started with a textual reference description as soon as it became clear that the basic features would work the way we imagined them to work (deduplication, content-addressable storage etc.)
So, back to your question:
Yes: At the time the project was started in January/February 2014, I only had a tiny bit of experience with Go, and I liked the language. I think I had briefly read the available documentation for Rust, but since it was very well pre-1.0 back then and had a reputation of not being stable (in terms of the language itself, not so much the compiler), I did not consider this an option. So, restic basically started with me trying to implement something new (a backup program) in a language I wasn’t very familiar with, just to get a feeling for it.
In retrospect, Go is a great choice for restic. The most important factors, at least from my point of view, are the easy readability, cross-compilation without hassles, and the recent popularity which brings many new contributors. The community is very welcoming and positive. Also, the reduced feature set is a plus in my opinion, e.g. for restic I can’t remember any situation where I wrote very ugly code and thought “well, with generics that would’ve been so much better”.
That does by no means imply that Rust would’ve been a worse choice, I think Rust is a very fine language with a thriving community. I can very well imagine restic having been written in Rust, that it became Go was rather accidental.
I hope this answers your question!
Personally, I’d love to get a bit more experience in Rust. I think it’s very valuable for being a good engineer to get to know several different programming languages and concepts. Before writing restic in Go, I’ve written a significant amount of code in Ruby, Python, and of course C (and less code in a couple of other languages like Perl and Shell). So I don’t have any experience with C++, I’ve tried to avoid that until today
If you have an interest in seeing Restic implemented in Rust, I would very much like to see the development of alternative clients which strive to be compatible with the on-disk repository/storage format.
The more active implementations, along with the requirement of interoperability, will only strengthen the specifications. When there’s one implementation, it’s just documentation. When there are two or more, it becomes a contract.
I personally have no favorite between Go and Rust. I’m slightly more familiar with Go at the moment, which makes the Go implementation a little bit more accessible to me (in terms of reading the source). It looks like a few design choices were influenced by the Go ecosystem (single binary distribution, choice of crypto based on availability in Go’s standard library, etc.). It would be interesting to see which design choices Rust’s ecosystem would influence.
While that would be an interesting experiment, it will also require a lot of coordination so that this potential alternative implementation stays compatible. In my opinion, we don’t have the resources to do that at the moment, I’d like to focus on improving restic as it is.
I think it would be pretty pointless to create other restic clients/clones instead of living with Go (which so far has served very well, and probably continues to do so) and spending that development time on improving the current software. It would be quite a waste to create redundant work unless there’s a specific problem that cannot be solved with the current language.
So maybe you can reconsider Rust when you start working on the next repository format v2
Joking aside, personally every time I have compared Rust with Go I have found Rust superior (this could be just personal preference though). Yes Rust is “younger”, version 1.0 was released in May 2015, in January/February 2014 it was still rough.
Somewhat tangential to this, I wonder how often people mistake restic for a Rust-based project because of the name. (I have seen more than one occasion where it was typoed to “rustic”.)
Personally I’m glad that restic has a distinctive name, rather than “Go-backup” or some similarly generic name.
That’s probably just overeager auto correction: “rustic” is an English word, whereas “restic” isn’t.
No, that’s not going to happen . Quoting Joel in Things You Should Never Do, Part I
They did it by making the single worst strategic mistake that any software company can make: ￼They decided to rewrite the code from scratch.
The article is awesome btw, lots of great insight. And it’s only 18 years old
rust is arguably faster than
go in many areas; but the speed comes at a higher cost when it comes to complexity and ease of writing. I’m no expert in
rust, but I know there is a much higher learning curve in
rust and there is a higher frequensy of “how do I even begin solving this” than with