"Two big conclusions" is a good way to put it.
I would phrase it like this:
• Go is a useful, safe subset of C (with a rather expanded libc.) Go lets you do fewer things than C (e.g. hard real-time things; processor-optimized things) but for most people, they don't need those things, and delving into them was what seeded the bugs into their C/C++ projects in the first place, completely unnecessarily.
• Rust is a formalization/codification of idiomatic C++. It's not a subset; it's a rethink, like Plan 9 is a rethink of Unix. You can do everything in Rust that you can do in C++, and the compiler will catch (nearly) all the bugs you would have left in the equivalent C++ project.
In other words, Go says "you don't need this"; Rust says "if you're so sure you need this, let's ensure you do it right."
For any given piece of code, either Go's assertion or Rust's assertion could be "correct." You either need the things only Rust lets you do, or you don't.
For a large codebase, though, I expect the answer is actually nearly always going to end up somewhere between. Big apps or libraries always have that one part that does heavy lifting and has to go fast, but go fast correctly; and 99% that doesn't.
Thus, I envision the future of many "systems software" codebases to look like this:
1. (1% of LOC) an "engine" library, written in Rust, which compiles to a C-ABI shared object;
2. (3% of LOC) an "engine wrapper" library, written in Go, which imports the "engine" object using Go's C FFI and then exposes a safe Go API to it—and also, the tests for the engine library, written in Go because it's easier;
3. (96% of LOC) the app itself, written in Go, which calls into the "engine wrapper."