I sit in that area (SRE/DevOps/Tools) as well, and I strongly believe that Rust is a better foundational language because of the type system strength and guarantees. Particularly useful is the `enum` type and type matching. I want, simply put, to be able to write code that is "bulletproof" after I've brought it to deployment, and Rust gives me some awesome tools for that.
(I've also come to understand that Go is an extremely sharp tool for Google's problems - the style of coding, the concurrency, the expectations of the developers (look at the Google style guides to see the culture of development there, there's a harmony with Go). Your harmony with Go reflects your harmony with Google's problems).
It's much more hacker-friendly than Gnome/Unity IMO. Its footprint is huge and there's enormous power in it that I don't use. XFCE is similar but doesn't have the polish that KDE does, especially around multimonitor support.
I would encourage the KDE team to focus on driving towards the hacker use case and letting that power drive the end user experience. :)
I think that Cricket Test matches (take place over 5 days) also seem to stress team capability fairly well. But I'm not a cricket expert (I would need to be introduced by someone knowledgable), so I may be quite wrong!
I'm working on my first non-trivial system with Rust right now, and I'm finding that the learning curve related to the borrow checker and lifetimes is rough. I'd liken it to macros in Common Lisp, but not quite as a cliff as monads.
In other words, I would like to ask that a substantial amount of your time in documentation at some point be pointed at the lifetime & memory system, as it is, IMO, the really unusual and hard part of Rust (As well as the whole freaking point of it too! ;)).
This topic would be well served by something like "katas." A series of code samples that look (to the noob) like they should compile, but don't. The series of samples would be chosen to walk the learned through the surprises in pedagogical order.
Actually, that's my preference too. But for certain topics, even after you grasp the principles, there are certain things that are going to surprise you until you get more experience. You can identify these in advance and find they will surprise most learners. So the kata approach is supplementary, kind of like well chosen exercises in a good textbook.
Yes, as you mention, the lifetime system is the big issue for newbies in Rust, and also a large part of the point! Revamping those guides is high-up on the TODO list.
I also suspect that lifetimes are one of those features that people might say, "I learned Rust, and I don't code in it, but learning about lifetimes improved my code in $DAYJOB_LANGUAGE." Just like how I think Haskell improved my ability to program in a variety of other languages, but I don't really write Haskell anymore.