1. I feel like I shouldn't feel ashamed when saying this, but here: mutation, imperative code & side-effect are kinda nice, and very much needed for a straightforward interop with e.g. existing JS/Obj-C/Java (hint hint) code. For example, notice how BS externals are erased & inlined. Most of our ffi doesn't have a conversion cost. An excellent ffi can be a deal maker, considering that if you're serious about migrating your codebase to a new language, you'd be using more ffi than idiomatic code for a while. Early on, I've had folks accidentally modify the output JS artifacts on messenger.com because they thought I wrote the JS code myself; they were generated by BS.
2. Also, speaking of native compilation: we're not reference counting but _some_ predictability when working with UI code is needed. The GC has to be fast and collect things within 16ms (and now, 8ms since iPad Pro is often 120fps). The ocaml gc achieves that.
Those aren't my findings: those are the findings of the creator of React, who also created Reason.
3. Finally, and to corroborate with what we wrote on that page: if you go ask your "normal JS colleagues", you'll realize most folks don't _actually_ know the semantics of JS. They like JS because it _looks_ familiar. Is TypeScript "just JavaScript"? Does it matter if JS folks can pick it up and be equally productive quickly? OCaml/BS semantics map over to JS well enough that we can just change the syntax into something familiar, and you'd likey end up writing the code you'd usually write in JS, albeit backed by a type system that needs to make no excuse in terms of quality.
Hope that helps? Tell me if that makes sense.
(Tail recursion has been a problem for a single person so far afaik; you do have imperative loops)