Interesting list. I'm curious if the author has looked at Rust and how they think it stacks up. Rust is obviously still pre-1.0, and it doesn't have an identical feature list, but it seems to me to perhaps be a lot more practical for a lot of work than OCaml (largely because Rust can basically be used anywhere C++ can be, and it has good support for C FFI).
I think that, having used both of them, Rust is going to feel a lot lower level than OCaml. The single biggest thing is that it's pretty hard (slash near impossible) to write Rust code without thinking about memory allocation, which adds non-trivial mental overhead to the work. That isn't to put down Rust - I think they are the first language that actually has a static, type-checkable story about memory allocation, and that's phenomenal, _but_, the reason for this is to be able to write soft-realtime code (for example, browser engines, games, etc). Web code, at least in the early stages, probably usually has lower performance requirements, and most people would probably trade some performance (and I don't mean to say that OCaml is slow, anymore than Go is slow, etc) for not having to even think about that stuff.
Eh, I don't see that as a downside. And actually, I'm not sure that's even true. It's already apparent that a lot of people are using a lot of completely unnecessary allocation in Rust, precisely because they aren't thinking about what they're doing (and so are doing things like using heap-allocated String objects when they really just need &str slices, or using Box unnecessarily; this was one of the reason cited for moving away from the ~ sigil, as it was considered to "hide" allocation too much).
And speaking personally, I almost never have to consciously think about allocation, unless I'm doing really performance-sensitive work. The straightforward approach is usually correct.
Why do you think Rust is applicable, here? It isn't obvious to me that these people would benefit from a language that can be used anywhere that C++ can be.
Given that C++ is in fact used pretty much everywhere, I'm not sure what you mean by that.
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.
It also has benefits that OCaml doesn't, such as full memory safety, no required garbage collector, 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.
> 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
This is not a limitation of OCaml but a deliberate choice of the authors of Real World OCaml to use the ctypes library. The OCaml implementation also supports directly linking with C code. What you need:
* Your ordinary C code
* Some C stubs that do the conversion between regular C types and the C types the OCaml runtime uses. Usually they are quite trivial, just use the few macros that OCaml ships with.
* Some type signatures to tell the type system what types your C stubs expect as that can't be inferred.
Generally I think the system is pretty easy to understand and use. Overall it is pretty neat to have two alternatives on how to do FFI, so you can pick the type of FFI (dynamic/static) exactly as your project requires.
You have to write C stubs? I'm glad it's possible, but that's still quite unfortunate. On Rust's side, you usually have to write wrappers around your C FFI functions in order to do any type translation and to add any necessary safety, but those are at least written in Rust (and are not actually necessary to call C, just necessary to provide a safe idiomatically-correct Rust API; you could just vend the C FFI functions directly if you wanted to).
> 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.
