Why use a systems language for this task?
I think describing Rust as a "systems language" in this context is pigeonholing it, and limiting your options.
Rust can be used as a Python replacement despite not sharing some of its properties. It's a matter of choosing the tradeoffs the author is comfortable with: the familiarity with and availability of libraries, the ability to run unfinished code versus being informed about mistakes at compilation, etc.
There's nothing inherent about Rust that makes it unsuitable for high level projects.
> There's nothing inherent about Rust that makes it unsuitable for high level projects.
I don't agree. A garbage collector is very useful for high level projects. The problem with Rust is that you might run out of options once your project grows bigger. So in fact, choosing Rust is limiting your options. Garbage collected closures are very powerful, and missing in Rust. It's probably one of the reasons why Rust has no stable GUI yet.
Rust solves most (or even more) of the problems GC does already with the borrow checker, I'd argue that one does not want to spent time thinking about stutters/latency spikes due to micro pauses or stop-the-world events from a GC in a very complex code base — granted GC's got a lot better, but there are still issues out there.
At work, we may not be the big, huge enterprise project, but Proxmox Backup Server is not small either and packs a lot of features (REST API, content addressable storage layer, backup management, system (network, time, update) management, ...) together spanning from low to high level. So, I'd figure it has at least a medium complexity. The thought that a GC would help us never entered my mind, nor did any of our devs mention it — most of them explicitly expressed at some time that they are glad there's no GC.
Besides that, Rust makes refactoring a bliss, which is a major plus point in big, complex projects with multiple teams working on a (partially) shared code base.
> It's probably one of the reasons why Rust has no stable GUI yet.
I think that is rather a reason of why a rust GUI could be superior to use, even from another language (GC or not) — I mean, it allows memory management without GC (slightly better performance, faster memory reclaim and no micro-pauses or the like) but also avoids lots of memory (mis)management bug classes. But yes, you're right in that there's no good plain-rust GUI framework with a stability guarantee, druid may be pretty close and has some project showing that it can work OK and look good already, e.g.: