> Given that C++ is in fact used pretty much everywhere, I'm not sure what you mean by that.
1. It isn't a given, from what I've read, that their product would need a language that could be realistically used everywhere. A lot of applications can get away with technology that is more "limited" in that sense. And being "limited" can be a plus.
2. Even if a language is used everywhere doesn't mean that it is/was an appropriate choice in all those cases. Look at people implementing stuff in Python, then reimplementing it in some static language later, giving a performance boost and less bugs, and almost/just as productive (though having the experience of doing it for the second time probably helps). Turns out that they didn't really need the dynamicity of Python after all. In C++'s case, maybe someone started developing an app and found out that they didn't really need the performance that a no-cost abstraction language is able to give, and so wouldn't need to pay the cost of dealing with the complexity of C++.
> And I think Rust is applicable because it hits all of the big features the author is touting as good in OCaml, such as first-class functions, immutable values, strong static type checking and type inference, ADTs and pattern matching.
And you also have the added features of smart pointers, managing pointers, heap/stack allocation, explicit use of views vs allocated memory (string allocated on heap vs string slice, for example), etc. These are all features, or burdens, depending on your application area. But why would they be features, in this context?
> It also has benefits that OCaml doesn't, such as full memory safety,
Doesn't OCaml have full memory safety?
> no required garbage collector,
Why is a garbage collector problematic, in this context?
> , and good C FFI (I'm no OCaml programmer but glancing at the beginning of the Real World OCaml's chapter on FFI, it appears OCaml uses dlsym() to look up functions at runtime, whereas Rust can outright link to them like any C program would). I'm sure there are others too, but I'm not familiar enough with OCaml to list them. I'm also not sure what the performance of OCaml is like (a glance at the Computer Language Benchmarks Game suggests it's often slower than C++), but Rust aims to have C++-equivalent performance.
It boils down to fine-grained control over performance, I guess. But, again, I don't see how that is a plus in this context. It can also be a burden, hence all the languages that deliberately do not let you have explicit control over memory - it makes for less stuff in the language, hence less complex language overall, or perhaps more room for other stuff that might be relevant to the application of the language.
I don't get the apparent attitude of "it has all the features of OCaml, plus all this other stuff". More stuff is not necessarily good, and can be a burden if you don't really need it.
I have no idea. Note here that "full memory safety" in Rust includes data shared between multiple threads, and includes protection against data races. Garbage collectors help avoid referencing free'd data, but if OCaml lets you share mutable data between two threads, then I doubt it's fully memory-safe (at the very least that suggests you can get data races).
> Why is a garbage collector problematic, in this context?
What, in the context of server-side software? I don't know if it necessarily is, but it's definitely problematic in other contexts. And I do know that there have been issues with other languages causing unpredictable performance on servers because of garbage collection, e.g. ending up with a big GC pause after some N requests. I hope OCaml doesn't have that problem, but I don't know.
> It boils down to fine-grained control over performance, I guess. But, again, I don't see how that is a plus in this context.
I'm not sure what specifically you're referring to in that second sentence. Just the general ability to have better control over performance? Having that ability typically is a plus even in the context of server-side software because it means you don't need to change languages just to write the performance-critical aspects of your software. Of course, using the same language is only a good idea if the language is also a good choice for the parts of the software that aren't performance-criticial. My claim is that Rust is indeed suitable for the rest of the program too.
1. It isn't a given, from what I've read, that their product would need a language that could be realistically used everywhere. A lot of applications can get away with technology that is more "limited" in that sense. And being "limited" can be a plus.
2. Even if a language is used everywhere doesn't mean that it is/was an appropriate choice in all those cases. Look at people implementing stuff in Python, then reimplementing it in some static language later, giving a performance boost and less bugs, and almost/just as productive (though having the experience of doing it for the second time probably helps). Turns out that they didn't really need the dynamicity of Python after all. In C++'s case, maybe someone started developing an app and found out that they didn't really need the performance that a no-cost abstraction language is able to give, and so wouldn't need to pay the cost of dealing with the complexity of C++.
> And I think Rust is applicable because it hits all of the big features the author is touting as good in OCaml, such as first-class functions, immutable values, strong static type checking and type inference, ADTs and pattern matching.
And you also have the added features of smart pointers, managing pointers, heap/stack allocation, explicit use of views vs allocated memory (string allocated on heap vs string slice, for example), etc. These are all features, or burdens, depending on your application area. But why would they be features, in this context?
> It also has benefits that OCaml doesn't, such as full memory safety,
Doesn't OCaml have full memory safety?
> no required garbage collector,
Why is a garbage collector problematic, in this context?
> , and good C FFI (I'm no OCaml programmer but glancing at the beginning of the Real World OCaml's chapter on FFI, it appears OCaml uses dlsym() to look up functions at runtime, whereas Rust can outright link to them like any C program would). I'm sure there are others too, but I'm not familiar enough with OCaml to list them. I'm also not sure what the performance of OCaml is like (a glance at the Computer Language Benchmarks Game suggests it's often slower than C++), but Rust aims to have C++-equivalent performance.
It boils down to fine-grained control over performance, I guess. But, again, I don't see how that is a plus in this context. It can also be a burden, hence all the languages that deliberately do not let you have explicit control over memory - it makes for less stuff in the language, hence less complex language overall, or perhaps more room for other stuff that might be relevant to the application of the language.
I don't get the apparent attitude of "it has all the features of OCaml, plus all this other stuff". More stuff is not necessarily good, and can be a burden if you don't really need it.