In my experience it has elements of both, but stuff like managing lifetimes means that (IMO) it's more trouble than it's worth when you're creating a web backend. Any more established garbage collected language is absolutely fine. Unless it needs to, say, run in a very resource constrained environment, in which case it's a pretty interesting possibility.
It's certainly a less mature ecosystem, but once you get over the hump of understanding lifetimes, there's nothing preventing you from using lots of owned values and clone in a way that makes it really easy to ignore annoying lifetime problems. And, the benefit being if you ever need to get more performance out of a hot part of your code, you can always optimize to get that zero copy goodness.
There is however a downside to the „clone everything“ approach: The performance might get worse than what it would be in an optimized GCed language that doesn’t require cloning (eg C#/Java).
At least I would only reach out for Rust at the moment for performance critical code, and then don’t leave easy optimizations on the table due to lifetimes.
Lifetime issues are not really relevant in a classic web backend context, since you generally just pull data out of a DB and return it to a web request, or the other way around. You generally don't have to share you data structures.
I do agree though that the tooling is very immature compared to other ecosystems, and Rust is generally quite boilerplate heavy and slower to develop.
It can still be a good choice if you need really high performance/low resource consumption - or you are going for high correctness and robust error handling.
But for most web backends Rust won't make much sense.
(I say this as someone who even writes web frontends with Rust via wasm, where it is even less optimal - mainly due to the high compile times)
Do you have any examples of the sort of front end work your doing with Rust? I've been toying with an idea using Rust but I haven't started really working on it.
Rust's lifetimes make it about the only language that gets shared-memory concurrency right. And I don't like the trend of pushing for message passing just because historically it was hard to do shared memory. The only thing I've found more convenient than that was software transactional memory in Haskell (monads and do notation working with it barely different than regular mutable memory), maybe by the next 10 years or so we'll get that in a mainstream language.
Not any language have such smart compiler, perfect errors handling system, "cargo" crates system. Not in every language refactoring is so nice that you can do it absolutely without fear.
