The "oh no it's slow, and you can't reason about performance" FUD is mostly directed at Haskell's lazy evaluation, but people like to throw it vaguely in the direction of "FP" in general. Most of the performance problems you have in Haskell (as in this recent submission: https://news.ycombinator.com/item?id=21266201) are not problems you will have in OCaml.
Yes, OCaml has garbage collection. It's a very efficient GC, and it is only ever called when you try to allocate something and the system determines that it's time for cleanup (https://ocaml.org/learn/tutorials/garbage_collection.html, though this might change if/when Multicore OCaml ever happens?). So if you write an innermost function that does arithmetic on stuff but never allocates data structures, you will not have GC problems because you will not have GC during that time, period.
Also, there are cases where destructive mutation of things is more efficient than making pure copies. OCaml allows you to do that, you don't need to fiddle with monads to simulate state.
There really isn't that much black magic there. Just don't believe everything that is said about "FP".
My understanding is that OCaml is a decent imperative language when required and that's one reason why it can perform well.
My usual issue with the 'you can avoid the GC by not allocating' claims in any language, is how much of the language is still usable? Which features of the language allocate under the hood? Can I use lambdas? pattern matching? list compression or whatever nice collection is available in the language?
Note that I do agree that even in very high performance/low latency applications, there will be components (even a majority of them) that will be able to afford GC without issues; but then it is important to be able to isolate the critical pieces from GC pauses (for example, can I dedicate one core to one thread and guarantee that GC will never touch that thread?)
Not ones that capture anything from the environment. I'm not sure about ones that don't, but I imagine you can use them.
> pattern matching?
Yes.
> list compression
List comprehensions, you mean? They don't exist in OCaml, but if they did, they would have to allocate a result list. So no.
> for example, can I dedicate one core to one thread and guarantee that GC will never touch that thread?
I don't think so, maybe someone else can chime in. But more importantly, this is a one-in-a-million use case that is a far cry from "functional programming is always bloated and slow and unpredictable". GC is well-understood, advanced, and comfortably fast enough for most applications. And for other cases, if you really need that hot innermost part, write it in C and call that from OCaml if you're paranoid about it.
Something I've always wondered about Haskell. Given referential transparency, purity, etc shouldn't it be possible for the Haskell compiler to choose whether to evaluate something in an eager or lazy fashion depending on performance heuristics under the covers? You have to make sure you don't ever accidentally do that with an infinite list but it seems that there ought to be lots of scope for optimization and speeding up code written in a straightforward fashion. Possibly also turning lists into arrays secretly too if it can be proven to produce the same result.
The point of lazy evaluation is to evaluate something only when you really need it. Not to auto-adjust the system performance wise. You can force eager evaluation in places where you want it evaluated sooner.
Personally, I think consistency is more important here because it leads to better predictability. If you don't know whether the compiler assigns something to be evaluated lazily or eagerly that could lead to a lot of nasty debugging issues.
Yes, OCaml has garbage collection. It's a very efficient GC, and it is only ever called when you try to allocate something and the system determines that it's time for cleanup (https://ocaml.org/learn/tutorials/garbage_collection.html, though this might change if/when Multicore OCaml ever happens?). So if you write an innermost function that does arithmetic on stuff but never allocates data structures, you will not have GC problems because you will not have GC during that time, period.
Also, there are cases where destructive mutation of things is more efficient than making pure copies. OCaml allows you to do that, you don't need to fiddle with monads to simulate state.
There really isn't that much black magic there. Just don't believe everything that is said about "FP".