My point was that the calls for Elm optimization could largely be mitigated through a combination of fast enough for most purposes (arguably already there) coupled with a reasonable escape hatch to the host environment (as of now JavaScript and not really there) for the cases when it isn't. I'm suggesting that rather than investing in fancy compiler changes, some changes in the runtime architecture to allow performance intensive central loops to be written in other ways would be cheaper, simpler, and would arguably address some of the other issues that have floated up recently.
Elm has a weird ambivalence about native code. On the one hand, Evan has pushed back pretty hard in the past out of fear of getting tied to crappy JavaScript libraries and has pushed for doing everything in Elm. This is reflected in the relatively small amount of native code based work in the standard Elm package repository. On the other hand, when pushed on how one is supposed to do something that is currently difficult in Elm — e.g., some MDL conventions — others in the community have pushed for using native code rather than trying to write it in Elm. My recommendation would be a middle path that says we believe most things are better in Elm but here are its limitations and here is how you can cleanly and easily reach outside of Elm when those limitations prove to be a problem. While the currently documented mechanisms may be clean, they aren't easy for many cases. Ports are extremely awkward for cases that require both a request and a response to that request. Effects managers are undocumented and discouraged. And native modules themselves are barely even admitted to let alone documented as a thing. Improve that situation and any concerns over both performance and interfacing to the broader world are substantially mitigated and Elm can better focus on its core mission. Fail to improve that situation and every effort to grow the market for Elm will also grow the pressure for it to do everything well. Mark > On Dec 27, 2016, at 10:49 PM, Peter Damoc <[email protected]> wrote: > >> On Wed, Dec 28, 2016 at 6:40 AM, GordonBGood <[email protected]> wrote: >> But we stray from the subject of "Elm as fast as JavaScript"... > > In my memory, Evan said that Elm can potentially be faster than JS. This > means some future where Elm is wide enough spread and wasm wide enough > adopted to have the resources and the context for an efficient compiler that > bypasses JS. This is years away so... what are we discussing here? > > Personally, I believe in the mantra of "Make It Work, Make It Right, Make It > Fast". > > Elm's speed is not a show stopper for the vast majority of Elm developers. > Sure, it might prevent some potential users from taking Elm seriously for > certain tasks but... what is better? catering for the needs of a very small > set of potential users or catering for the needs of the vast majority of > actual Elm users? > >> 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. > > Or you can look at it from the other way: for certain types of applications > you can already use a practical, simple language (Elm). :) > > > -- > There is NO FATE, we are the creators. > blog: http://damoc.ro/ > -- > 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. -- 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.
