On Wednesday, 28 December 2016 00:48:17 UTC+7, Mark Hamburg wrote: > > This could, however, feed into the questions over Elm's interface to > JavaScript. The easier it is to escape to JavaScript, the easier it is to > say that Elm is fast enough for the vast majority of code that matters and > if that doesn't cover a tight loop in your code, you can write just that > part in JavaScript. > > I've spent a long time working in Lua which has a fairly fast > implementation as scripting languages go, but also had a very > straightforward and powerful escape hatch to C. The former meant that one > could expect to write most logic in Lua and not worry about performance. > The latter meant that if performance were a problem, it would be easy to > address when it came up. > > The net from this for Elm is that I would argue that compiler > optimizations can focus on easy wins provided that it is easy to move a > computation to JavaScript when that doesn't work. At this point, however, > that isn't possible because launching a computation through a command and > waiting for a result back on a subscription where that result must be > distinguished from all other results from other command driven requests is > a mess. At the very least, please give us task ports so that we can readily > fire off asynchronous computations with results — though for use as an > escape hatch when Elm is too slow, I can feel the pressure for a > synchronous native code extension mechanism. >
I think the main point to Elm is that one doesn't have to deal with the messiness of JavaScript, nor should one as Elm compiles to JavaScript which can run at close to machine code speed with a good JavaScript engine such as Chrome V8 if the Elm compiler generated efficient JavaScript; this is in contrast to languages such as (interpreted) Lua or Python which run 10's of times slower. I do agree that writing new subscriptions seems unnecessarily complex, involving writing Event Managers, which Even discourages as he thinks " Elm needs maybe 10 of them total". Due to this, it seems to me that one can't write subscriptions entirely in Elm with a much simpler mechanism to distinguish the source, which might be a useful capability and might satisfy your requirement as well, as then a subscription written in Elm could still call JavaScript through ports. I think the whole subscription issue stems from some "muddy" thinking about the relationship between Task's, Process's, and message passing, which needs to be ironed out before things can be made easier. And what will Elm do to compete with that elegant Promise/asynch/await model in (modern) JavaScript? But we stray from the subject of "Elm as fast as JavaScript"... My point is that I love the practicality of Elm with its simple yet functional syntax and would like never to be forced to use JavaScript or even Typescript again, but am forced to do so for certain types of applications due to these inefficiencies. -- 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.
