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 <gordonbg...@gmail.com> 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
> elm-discuss+unsubscr...@googlegroups.com.
> 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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
