Mmm, I had one when I first started messing with it but not seeing it on my website, think my bucklescript testing area overwrote it. I could remake it. The main issue is that Elm does not have a lot of optimization passes that the ocaml compiler has so it was just not doing a lot of simple folding and inlining and such.
Cool, well yarn uses NPM so that is already set.
As do I, but they do not represent certain callback style things. I think the current style of ports, whether in or out but not both is quite wrong, if ports were just an exposed elm Task (as many many people are pushing for) then it would handle all the cases with ease.
So by great tooling support it is indeed significantly better. Better libraries, better tools, larger and well tested ecosystem, etc...
They all have different purposes indeed. The BEAM/Elixir/Erlang/lfe/etc is fantastic for robustness across many servers and vast scaling. It, however, sucks for, say, parsing, or text munging, even something like Python blows away the BEAM in most text processing. Use the right language for the right task. ^.^
Haskell I'd call anything but simple, it has so many extensions and work-arounds due to limitations in its type system, in addition to taking as long or longer than C++ to compile for anything of significant size, HKT or typeclass usage, and etc, that it makes it hard to be productive in it.
Scratch, eh, it would be hard to get a lot of the work I do to get done in it, ditto with processing, and for Haskell the turn-around times would be fairly huge enough that my productivity would be shot.
Oh absolutely not, I whole-heartedly agree. I try to learn near about every language that I come across, even if they are slow compiling. However when I am trying to get Real Work done, stuff I get paid for, I want languages that bring my productivity to the max, that includes having a great runtime, is small enough for deployment, is fast enough to never need to worry about causing issues, will not be questioned by the bosses, has a great type system that catches 90% of the bugs that I'd make otherwise (looking at elixir lacking this..), etc... OCaml is thus to me a much better front-end language thanks to the tool support it now has (Bucklescript is a much better backend plugin for me than JSOO is) and my productivity has seen a corresponding boost as well. Combined with that I can write OCaml programs that run on the server via a BEAM Port I can write some of the same code on both sides with ease, without installing extra runtimes on the server (no node).
So yes, I entirely agree that
externals in OCaml is a huge difference when I am getting paid to "Get Stuff Done Now".