I've written Rust professionally for the past 6 years, and pretty much exclusively for stuff where memory safety is the least of my concerns (even speed!). I've made gRPC APIs, agents running on machines to setup configuration and such. The usual suspects for this work would usually be Python or Go.
You've pretty much summed up why I'm standing behind Rust for non-memory-critical applications: tooling, error messages, and the type system. For business logic, you cannot beat all that, as a lot of business errors can be avoided using those (all praise the Rust enums!). Also, you've summarized my feeling about the functional world embraced by rust: it provides quite a bit, without requiring a Haskell PhD to write it. Seriously, iterators and the associated trait are a godsend (even though having to always write .iter()....collect() is sometimes clunky).
As for the GC. I've yet to come to situations where the lack of GC was the real hindrance. It has more to do with futures adding not easy to grasp lifetime bounds to data, but one quickly learns to embrace it by moving data when needed. Combined with channels and Arc, there are many escape hatches making in my opinion the GC a non-issue.
IMHO, making GC-less languages acceptable again is a good thing, because it keeps diversity in the ecosystem and gives options. It also shows that doing without GC does not relegates written code to manual memory management like C/C++. In fact, Swift does the same and is pretty good at being a GC-less language. Both Rust and Swift are languages where memory management is opinionated by embedding it in the language, and thus ergonomic. Frankly, I rarely think about "oh hey, I wished I had a GC".
You've pretty much summed up why I'm standing behind Rust for non-memory-critical applications: tooling, error messages, and the type system. For business logic, you cannot beat all that, as a lot of business errors can be avoided using those (all praise the Rust enums!). Also, you've summarized my feeling about the functional world embraced by rust: it provides quite a bit, without requiring a Haskell PhD to write it. Seriously, iterators and the associated trait are a godsend (even though having to always write .iter()....collect() is sometimes clunky).
As for the GC. I've yet to come to situations where the lack of GC was the real hindrance. It has more to do with futures adding not easy to grasp lifetime bounds to data, but one quickly learns to embrace it by moving data when needed. Combined with channels and Arc, there are many escape hatches making in my opinion the GC a non-issue.
IMHO, making GC-less languages acceptable again is a good thing, because it keeps diversity in the ecosystem and gives options. It also shows that doing without GC does not relegates written code to manual memory management like C/C++. In fact, Swift does the same and is pretty good at being a GC-less language. Both Rust and Swift are languages where memory management is opinionated by embedding it in the language, and thus ergonomic. Frankly, I rarely think about "oh hey, I wished I had a GC".