Really surprised to hear you say this, actually - in my mind Rust is the can of worms that allows almost anything and everything in terms of language features and will likely end up as bloated (if not more) than C++ in the next 20 years.
What makes you argue that Rust is the "Go" of systems programming?
For me personally, the problem with C++ isn't that it has too many features, but that they interact poorly and require complicated rules to makes them work together. To list a few pairs: destructors and exceptions, templates and inheritance, templates and headers, encapsulation and headers, namespaces and operator overloading.
At least at the moment, Rust's many features are mostly orthogonal and work well in combination. But in some sense, that makes the learning curve even harder, because you can't focus on an "accepted subset" as you would in an existing C++ codebase.
I wouldn't use this analogy as an everyday tool, but in reply to the comment above, if we really have to give the "Go" role to either Zig or Rust, I'd choose Rust for the main reason that, while you can certainly come up with a lot of abstruse abstractions, the language ultimately wants to keep you away from certain tools that would otherwise be considered core to a systems programming language. I'm of course referring to the restrictions that ensure safety at the expense of being able to implement some kinds of algorithms (in a "safe" way).
Go in may ways has the same approach: stop developers from doing potentially damaging things (according to Go's definition of what's "potentially damaging"), which I guess is one of the reasons why the creators decided to remove pointer arithmetic and add a garbage collector.
Zig wants to keep the language small, but the programmer is expected to have access to all kinds of advanced tools, in a way that I don't see neither Go nor Rust consider acceptable.
In Zig you can use `undefined` to avoid initializing memory, do all kinds of pointer arithmetic, and while you can't overload operators, you can use comptime to concoct all kinds of static/dynamic dispatch schemes, the only limit is just that they can't masquerade as basic operations.
Of course you can do all these things in Rust unsafe, and same in Go with cgo, but the point is not what you can or can not do, it's what the language guides you towards, and the only potentially damaging thing that Zig tries to prevent you from doing, is making code hard to understand for readers.
50 years of C and a few less of Objective-C and C++, have proven that C.A.Hoare was right regarding language defaults in computer security, in the approach taken by ALGOL based systems programming languages, starting with ESPOL/NEWP.
If I want unsafe languages, C and C++ already fulfil the purpose with 50 years of ecosystem.
Being safer than UNIX for certain kinds of customers, is one of the selling points of Unysis ClearPath MCP, thanks to NEWP.
I mean mostly in the sense that it takes mathematically modelling programming and the machine being programmed very seriously and it allows you to build tall towers of abstraction on top. Compare this to C++ for example where many of the mechanisms for building abstractions are accidental or C where abstractions are not really possible.
Actually I think that in the long term most languages with automatic memory management will just adopt some form of affine types for high performance code sections, and that will be it.
We will keep the productivity of the existing eco-systems and tooling, with an additional tool for the 1% of use cases that it actually matters.
If even that. I think in a lot of cases, it doesn't really matter, and most already allow linking to a library, which works well enough for Python at least, and should be fine for most application development purposes.
Languages like Rust and Zig are just on a different level, for cases where performance or hardware restrictions are the number one concern.
