Depends on the application, really. And I wouldn't call it "advocacy" so much as being resigned to accepting a less odious bad option. In that case, typically Go or Python, unless we need that last bit of performance and can't get it with a pre-built library: then I'd argue for C, C++, and Rust (in that order).

Not the OP, I rather use managed languages with AOT/JIT toolchains.

C++ and Rust I leave for scenarios where choice is imposed on me due to platform SDKs, or having any kind of automatic memory management isn't an option.

Rust's memory semantics are definitely a kind of 'automatic memory management' though. I mean, that's the whole premise - to have the kind of guarantees about memory safety that until Rust where only available in GC'ed languages running on some runtime.

There is nothing automatic about compiler errors in lifetimes.

As for until Rust, Cyclone and ATS did it first.

Not sure if Cyclone and ATS don't predate it, but Rust's memory management is a bit like 1/3rd of Linear Lisp (specifically, the compil time garbage optimizer)

To be more precise, Rust uses affine types as basis for the borrow checker.

https://en.m.wikipedia.org/wiki/Substructural_type_system

Its biggest achievement is making them more well known to mainstream devs without CS background.