One big advantage to developing in Rust that I have found over other languages is that you _must_ handle error-type conditions; for example, if something returns an Option or a Result you need to check that it was successful in order to extract the value.
This means that you don't accidentally forget a null check (or a catch block) and, in my experience leads to software that is a lot more robust.
Even if all it is doing is pulling from a database and munging it into JSON.
I've found that that's not really true for me, tbh. In theory, it absolutely makes sense that something like Ocaml would be more productive - you can completely sidestep most of the memory management stuff and just get on with writing working programs.
In practice, every time I've tried out Ocaml, I've bounced off _hard_. The standard library is very limited and filled with cruft (stdlib regexes being a notable example), so users very quickly need to start understanding the alternatives. There's little in the way of good intermediate documentation, so once you've figured out how recursion works, it's often quite hard to figure out more practical questions, like when it makes sense to switch to refs and imperative code for a problem. There's also not a lot of "practical" libraries - I wanted to write a small web service recently to organise house chores, and I figured I'd need a decent datetime library (with support for juggling timezones), some way of interacting with sqlite, and a basic web server. The web server situation was okay, but the only SQL library I could find was 80% ungoogleable sigils with minimal documentation, and I couldn't find a single datetime library that has a concept of instances that could be interpreted in different time zones.
In contrast, Rust has a clean (albeit minimal) standard library, with a lot of good pointers to well-maintained third-party libraries; it has plenty of documentation ranging from the beginner guide to the Rustonomicon; and there's a lot of stuff happening in the ecosystem that you can already start relying on. Like, if you're coming from Java or Python you might have to lower your expectations somewhat, but you can still have expectations of _something_, which is not my experience with Ocaml.
I think I need to try out F# more - my impression is that there's at least an existing C# ecosystem there which helps with a lot of the practical issues - but so far I've been really disappointed by my experiences in ML-land. There's so much I want to like - I'm really excited about the new effects work that's happening, for example - but the ecosystem as a whole just doesn't seem that usable for practical things unless you already know what you're doing, or unless you're prepared to build all the stuff you need from scratch à la Jane Street.
So actually, in practice, I find myself much more productive in Rust, despite coming from a Python/Java/JS background. The memory management stuff turns out to be pretty easy to pick up, and having a strong ecosystem means that I've generally got the tools I need at my fingertips.
That is the place Rust is for me, regarding the use cases I still care to reach out to C++, outside of compiled languages with automatic memory management.
If I do them in Rust, I would need to build from scratch and I rather not, as that isn't my focus.
Besides F#, there are also Haskell, Scala, Kotlin.
Java and C# are also getting there, even if a bit slowly, and compromised by backwards compatibility.
What are you wanting to build from scratch? I've not really had that experience in Rust so much, maybe that's just a case of working in different domains though.
Starting with Fsharp that has a gazillion libraries (usually pretty good quality ones) and it has much more advanced features from the ML tree than Rust (like |> for example).
Rust's error handling might be great for people who are used to exception based error handling but it is a joke compare to railway oriented programming in Fsharp or any ML lang that supports |>.
This means that you don't accidentally forget a null check (or a catch block) and, in my experience leads to software that is a lot more robust.
Even if all it is doing is pulling from a database and munging it into JSON.