Hi Gordon, thanks for your summary.
Just want to add that BuckleScript compiler is only developed for one
year, now I almost work full time on it (thanks to my employer), so you
would expect more performance boost coming soon.
Personally, I don't mind any syntax, I am a huge fan of common lisp so
you can tell. But I understand syntax does matter to quite a lot of people,
so you may be interested in checking out ReasonML by Facebook(a more
familiar syntax for OCaml). OCaml is a very modular compiler which has 7
IRs, ReasoML compiles to IR 0, while BuckleScript takes it from IR 4, so
the combination of ReasonML and BuckleScript is seamless.
Thanks -- Hongbo
On Wed, Jan 11, 2017 at 10:37 AM, GordonBGood <[email protected]> wrote:
>
> On Thursday, 5 January 2017 21:46:26 UTC+7, Bob Zhang wrote:
>>
>> Indeed, in OCaml native backend, `for loop` still dominates the
>> performance critical code since most optimizations does not work across
>> function boundaries.
>> There is still a long way for optimizing compiler to catch up with
>> carefully tuned code, but BuckleScript does not get in your way, you can
>> still write low level code with type safe guarantee in it when performance
>> matters
>>
>
> To anyone that might try to get something useful out of this thread, after
> a week of trying BuckleScript, PureScript, and Fable (I couldn't get GHCJS
> to install on my machine), I have the following observations:
>
> 1. As Hongbo asserts, BuckleScript is the fastest of the ones I tried,
> both as to run speed and compilation speed. It also doesn't get (much) in
> the way of writing imperative code for the very fastest output, nor does it
> (much) obstruct the forced generation of pretty much any JavaScript special
> functions one might want to call from BuckleScript or Elm. My main
> objections to it is that it gets very wordy and obscure when one has to
> force it to generate uncurried calls to special JavaScript functions, and I
> have grown to hate OCaml syntax even more than I ever did as feeling very
> archaic compared to more modern feeling functional languages as F#,
> Haskell, and Elm: not a white space language, no operator overloading
> other than through modules/"Functors" which have a run-time cost - quite
> usable but that doesn't mean I like it.
> 2. Fable is a great concept using F# (one of my favourite languages)
> as the front end and outputting JavaScript through using Babel; however, it
> isn't (at least yet) mature enough to consider: it is slow to compile
> (likely due to adding passes in compiling to F# AST, then converting to
> Babel AST, then finally compiling to JavaScript) and in many cases to run,
> this last much due to poor emulations of F# libraries but also generally
> poor code generation. It doesn't have tail call optimizations at all
> although there is a plug-in that looks that it would do the job and as for
> BuckleScript/OCaml, one can use imperative code if one must. One can
> output (emit) any JavaScript one might desire for calling from Elm or
> Fable, and such code can have type signatures attached for (some) type
> safety. Other than speed, my main problem with it is difficulty in
> controlling when functions are curried or not, which is a problem for
> temporary functions used functional style. This pretty much invalidates
> writing functional code when one has to drop to imperative code frequently
> in order to get performance. If only one could decorate functions to show
> whether they are to be called non-curried as one can in BuckleScript
> ("[@bs]").
> 3. PureScript in a very powerful language comparable to Haskell, but
> being Haskell-like, there is no provision for writing imperative code at
> all, meaning that one would need to write Javascript in order to accomplish
> this. That pretty much precludes PureScript's use for me, as the things I
> need it for involve speed and its more work writing JavaScript modules in
> some other language and then calling them from PureScript (which is quite
> easy) that I may as well do it more simply from Elm. There also that
> PureScript depends on many library functions do be able to have its
> Haskell-like complexity, so anything done in the language idiom is going to
> be quite bulky; also, calling those features have a run-time cost so are
> slow.
> 4. Although I could not try it, I suspect that GHCJS will also depend
> on many library calls in order to emulate what GHC/Haskell can do. I did
> not investigate whether one can emit JavaScript directly from the language
> and how easy it is to call JavaScript from the language, nor do I knkow how
> compilation speed compares.
>
> BuckleScript can do basic transformation of tail calls inside (some)
> functions into loops, but not in all cases; however, within about a year
> that capability won't be vary important as all mainline browsers and nodejs
> will do this themselves once the ECMAScript specification is formalized
> (currently in flux) Other optimizations such as not making unnecessary
> function calls (which lack of in Elm started this thread) or creating too
> many objects will become the more important optimizations.
>
> My general conclusion is that while one could use BuckleScript for the
> purpose of generating the fast JavaScript that Elm currently cannot, one
> has to be pretty committed to its use and is going to have to some
> imperative code in a language where writing imperative code what it was
> designed to do. For some uses, one could do the same in Fable but it
> generally is very slow at anything functional (I measured up to about six
> times slower than BuckleScript due to overuse of JavaScript objects. I am
> starting to think that one may as well write in TypeScript in order to
> avoid having to know JavaScript too well (using TypeScript classes and
> interfaces is an option but not compulsory and have a slight run time
> cost), which was my first thought. However, I do admit that BuckleScript
> can do the job if one is willing to live with OCaml syntax and typing.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Elm Discuss" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/elm-discuss/Um7WIBTq9xU/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> [email protected].
> For more options, visit https://groups.google.com/d/optout.
>
--
Regards
-- Hongbo Zhang
--
You received this message because you are subscribed to the Google Groups "Elm
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
