I think it's one of those cases where using metaphors doesn't help clarify the thought, and instead obscure it. Rust shares a lot with OCaml, and so with F#. F# is "the" functional programming language of the .NET world, but it's also because it's the only one, and it's a second class citizen.
I will also add that Rust is not trying to be C (and neither trying to "replace C"). It's here to offer an alternative, that in some cases makes more sense than sticking with C. C code means a lot of thing. For example, some people code in C89 because they find some kind of purity in it. You're never going to get that from Rust. For some people, it means fast and secure code, like with Python's cryptography. That's a place where Rust can be used. For some other people, it's C because that's the only thing that's allowed by some authority. Again, Rust isn't going to fit here until/if it's allowed. I think in general, trying to reason in terms of use case leads to better comprehension than trying to think in languages.
But outside of that, the move was basically the same. They found another language that's very similar, but that has a way bigger ecosystem.
> Rust shares a lot with OCaml, and so with F#. F# is "the" functional programming language of the .NET world, but it's also because it's the only one, and it's a second class citizen.
No, F# has a lot more OO than OCaml, and there’s a significant difference in features (ex active patterns in F#, functors OCaml). I liked what I used of F#, but for any serious program it’s more Multi-paradigm than functional, since you’ll end up doing a lot of OO.
In my experience that isn't quite true. You usually OO for IO/interop if a C# library is being used, then its module code for the most part all the way down (e.g. ASP NET Core define a class for the controller, then have it interop to F# FP code for the most parts). With some newer F# frameworks you don't even have to do that these days.
Having some experience with large scale F# codebases its rare you define a class compared to records, unions and functions. 100's of functions, 50-100 small types, 1-2 classes approx is usually the ratio I've seen for a typical microservice (YMMV).
I will also add that Rust is not trying to be C (and neither trying to "replace C"). It's here to offer an alternative, that in some cases makes more sense than sticking with C. C code means a lot of thing. For example, some people code in C89 because they find some kind of purity in it. You're never going to get that from Rust. For some people, it means fast and secure code, like with Python's cryptography. That's a place where Rust can be used. For some other people, it's C because that's the only thing that's allowed by some authority. Again, Rust isn't going to fit here until/if it's allowed. I think in general, trying to reason in terms of use case leads to better comprehension than trying to think in languages.
But outside of that, the move was basically the same. They found another language that's very similar, but that has a way bigger ecosystem.