Rust developers, on the other hand, are used to taking a lot of coffee breaks (or tea, cigarettes, sobbing, or whatever as the case may be — Rust developers have the spare time to nurse their demons).
-- @brson's tongue-in-the-cheek reference to Rust's compile times in https://pingcap.com/blog/rust-compilation-model-calamity/
Rust's predictable performance lands another strike for the team! 
Even with just basic optimization, Rust was able to outperform the hyper hand-tuned Go version. This is a huge testament to how easy it is to write efficient programs with Rust compared to the deep dive we had to do with Go.
[..] After a bit of profiling and performance optimizations, we were able to beat Go on every single performance metric . Latency, CPU, and memory were all better in the Rust version.
Discord Engineer Jesse Howarth, in the blog post
"Why Discord is switching from go to Rust" (emphasis in original)
This Discord Blog documents tangible productivity benefits, improved performance, as well as platform maturity for Rust, great things for our community to show in 2020!
Also, the more predictable behaviour allowed them to increase cache-sizes without suffering catastrophic GC-spikes, leading to a factor-5 to factor-200 improvement, depending on the metric (the graphs are a bit too low-res to get more accurate numbers).
go [or Rust] style package management tools are designed to build programs that work. Not programs that work on Debian if you have the right libs installed, or on Windows 7 or newer, or whatever, but “if you compile it on an OS, it works on that OS”.
It's a safe system programming language which just happens, unlike something like Ada, to have a critical mass of hipsters and webdevs behind it.
-- RAKtheUndead on why Rust is so popular @ https://www.reddit.com/r/MechanicalKeyboards/comments/f2o7vu/a_handwired_unsplitted_ergo_keyboard_with_a/fheeltk/
(You've gotta at least grin at reading that.)
That is encouraging. Back in the day C and Unix were said to be promoted and spread by "hippies" from Berkeley. Sounds like Rust in on the right track then.
Another thing we should remember when talking to other-language folks:
Some time later the tax man comes by. He asks to see my tally sticks from last year. Oops, now I have a problem! I need records, databases, immutable data structures, extra book keeping work. Incidental complexity.
What am I missing in my shepherds tale?
Your analogy is quite good, but I don't think it unambiguously supports mutable data structures.
The abacus will let you count faster, but is a bad medium for long-term storage. A stick with notches isn't exactly immutable, since you can cross over notches, so in a sense they're mutable but only additively. If you glue the beads of the abacus it becomes better than a stick with notches for bookkeeping but worse for counting.
You can evaluate data structures outside of computers perfectly fine like this. I would even say that this isn't figurative speech or metaphor: We're actually analysing the time and space complexity of real-world data structures. Once we get to von Neumann-style computers, the materials (RAM, CPU, etc.) just have a different cost profile which make some analogical comparisons break down a little.
A very strong property of immutable data is that you can refer to it from other data and know that it won't eventually become invalid. So immutable data can be used to annotate other immutable data (or other mutable data, for that sake, but then this recursive property is instantly lost). This is the bookkeeping part.
The radical idea of using functional or otherwise declarative programming for general purposes (rather than very domain-specific ones) comes from the observation that often the cost of immutable data structures is well within acceptable limits of our materials. And because computer programs often do a mixture between counting and bookkeeping, you get the benefits of persistency at more levels.
When the cost of immutability is too high, Haskell has come up with the ST monad, which is a type-safe way to mutate a value locally. When the cost of mutability is too high, Rust has come up with borrowed types. These notions may essentially express the same machine-level operations.
Whether you decide to complicate your program with "pure data" or "linear types", the justification is in both cases that more constraints will provide for more efficient compilation and execution strategies, at the cost of mental overhead to the programmer. So if you think e.g. linear types are worth pursuing, you're probably closer in mindset to a purely functional programmer than you think, sans the extremist attitude. 
So, Rc<RefCell<T>> is "Shut up, I don't care", while unsafe is "Shut up, I know what I'm doing"?
I wouldn't say that.
Sometimes it really is the right tool for the job, but it often gets abused by people used to having a GC where it's okay to hand out references like candy.
unsafe on the other hand can be thought of as the pragmatic escape hatch you sometimes need to use when doing things which are, well, unsafe... That doesn't roll off the tongue nearly as nicely as you put it though...
most of the quotes in this thread are very positive and sometimes funny, but looking at the original post from feburary 2015 above, we're supposed to also submit "insightful" stuff. so i guess the following one qualifies, even though it's kind of sad.
The number of crates which can be charitably described as a " barely functional list of the author's opinions wrapped around a project's c-api " is mind numbing. Picking a crate for a new problem domain is like walking through a mine-field. It feels like (when official options are not available) I need to dedicated ~3-4 weeks to just selecting and patching the dependencies I'm going to use for a project so I can be responsibly confident in them.
-- valarauca14 on reddit thread titled What do you miss about other languages when working in Rust?
on a more ironic note, there's also
& * 'a &'a Box || macro! mod crate extern crate #[...] String vs &str &self unwrap expect ? Rc Arc
by new community member @yjoking on this thread
"nau pli us : the first larval stage of many crustaceans, having an unsegmented body and a single eye."
At last, the proper term for a new Crustacean! (emphasis added)
I like "Nauplius"! 
Obligatory Wikipedia link (after digging through a handful of redirects): https://en.m.wikipedia.org/wiki/Crustacean_larva#Nauplius
Several larval stages were apparently originally mistaken for separate species, and even today we don't know the match-up between all larvae and all adults. (Much like how Rust-the-language is still figuring things out!)
Plural is apparently Latin-style: "nauplii".
I have no idea how to debug Rust, because in 2 years of Rust, I haven't had that type of low level bug.
papaf on hackernews, in response to Are there any anecdotal stories about how Rust programs have fewer errors?
Interesting question. One does not generally tell many anecdotal stories about bad things not happening
Yet they dislike Rust... 
Hey, I can feel them! I love debugging! That feeling of leading an investigation, slowly uncovering the truth of what happened, why it happened, and how to make it right. And now, there's this new language that comes in and robs us of that pleasure?! I mean, I can see where they're coming from