The author lists Ocaml as "non-IDE-friendly." This is not my experience. Ocaml is one of the most IDE friendly languages I have in my toolkit right now -- not just functional languages, but all of them. Ocaml + Emacs + Merlin is stable, accurate, very fast (responsive), and easy to set up and configure. Plus, named and named-optional parameters are supported in the language, and can be used to good effect for disambi…
Compare that to JavaScript where you can literally just install vscode and node and you’re up and running. Not to mention that you could pop open a console in any browser and execute code. I love OCaml as a language but we have to admit that the developer experience just sucks. For something to be simple, a 10 year old kid needs to be able to figure it out. That’s how languages get adopted.
(I feel obliged to give an example of what I think is a bad developer experience, and I would point at Haskell. There are far too many toolchain variations to choose from, all of which seem to be in active use -- cabal, cabal-v2, stack, cabal-v2+nix, stack+nix; ghcid, ghcide, etc. etc. Once your choices are made and your stack is configured, you'll be okay, except for the inordinately long build times. But in my experience, it can be a real nuisance to come back to a half-finished Haskell project -- say, on a new machine -- unless you've made a singular, personal commitment to a specific technology stack. Leave yourself copious notes, Makefiles, and shell.nixes to remember how to get the thing running! But this is a personal sob-story and a digression.)
My main argument -- which I think is being lost here -- is that Ocaml isn't IDE unfriendly, and especially not so unfriendly that an entirely new language is needed just so that FP and IDEs can happily coexist.
(Well, except for Windows. Ocaml + Windows is more unpleasant than it needs to be.)