On Sunday, 1 January 2017 19:57:47 UTC+7, Peter Damoc wrote: > > On Sun, Jan 1, 2017 at 1:41 PM, GordonBGood <[email protected] > <javascript:>> wrote: > >> That leaves me impressed with the ease-of-use for Elm, with my biggest >> wish list all concerned with making Elm faster; but it is still early days >> for the language as long as it is still evolving. >> > > Elm is fast enough for most purposes and it will get faster (e.g. there is > a new implementation for Array in the works that I understood to be faster) > If you need a piece of code to be faster, you also have the option of > designing it as a driver for the runtime and just use the Native layer to > access it. > This is an advanced use of Elm and a last resort, you have this freedom if > this is what would push the project over the "fast enough for practical > purposes" >
I hit the post button accidentally so you only got a part of what I set out to say :) As I said earlier in the thread, current 0.18 Elm is not "fast enough for practical purposes" for applications as in games and math applications. For a simple instance, the community contributed math library implementation of "primesBelow" ( Sieve of Eratosthens) is horrendously slow due to the way it uses the current Array library such that it is about 30 times slower than doing it functionally where it would usually be about 25 times faster; I rewrote it to get speeds only about three times slower than functional approaches, but that still isn't so good. A Haskell type of implementation, while still appearing as immutable to Elm code, would get most of using arrays speed back. Another application would be things like doing extended precision math. Currently the available library is just a wrapper around a raw JavaScript implementations; however, with the library as I would propose it (and with Elm generating more efficient comparison code), one would be able to implement this and other similar types of libraries entirely in Elm without much of a cost in speed. There must be hundreds of similar applications in the math and games domains where currently writers would have no choice but to interface with raw JavaScript or at least generate JavaScript with another more efficient compiler as in GHCJS, etc. I think that the software development world is moving away from developing JavaScript code just as it moved away from writing assembly language long ago, which is why there is so much interest in all these transpilers, asm.js, wasm, etc. It seems to me that the reason Elm has garnered so much interest for such a young language is for that very reason as well as that it can (potentially) handle both the front end and back end without external code except that it isn't yet fast enough for these domains. If it were (quickly) improved, I think it might become the Python (as to popularity) of the web page and browser application world. -- 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.
