On Tuesday, 24 January 2017 02:05:19 UTC+7, Robin Heggelund Hansen wrote: > > I don't understand this. Elm currently has better code output than Babel > and Typescript. Choosing Elm over those gives me faster applications > (though, I've never needed more speed) as well as smaller bundles. An > application written with React+Immutable+Moment, will have much more code > than an equivalent Elm application, it will also be much slower unless you > have steel discipline and are willing to write more code. Elm's compiler is > also faster than both Babel and Typescript, and compiler speed will get > *much* faster in the next release. In my experience, Elm is already better > than Javascript in every conceivable way, and that's before taking static > typing into account. True, I don't write games, but if I did I probably > wouldn't do it in an immutable language due to garbage collector concerns. > Depending on the game, I wouldn't even write it in a javascript environment > due to the lack of threads. >
I'll agree that Elm produces better code than Babel (which is what Fable uses as a back end), but Typescript can be as close to JavaScript as you want it to be (not that I want to write in TypeScript as it is too non-functional and too much like JavaScript with typing). Choosing Elm gives code that is somewhat faster than Babel generated code, but not TypeScript (if one is willing to work at it) but definitely is much easier to develop. I agree that I don't want to touch React/Immutable/Moment. Again as you say, Elm's current compiler is also faster than Babel (maybe TypeScript; as I say I really don't want to go there for large projects), but as per OvermindDL1's comments, it seems that for large projects it takes a long time to link together the pieces, but that is being worked on. I'm not so much into writing games, and as you say the JavaScript environment isn't multi-threaded so there are limitations there: I am into heavy duty math computations (for which not being multi-threaded is also a limitation); however, I expect in the next year or two that the entire client code environment will make some radical shifts with wasm so these things are possible, and hopefully Elm will have evolved to the point where writing a wasm back end will be fairly easy. I regard all the development we are doing now as prototyping for the near future. That said, what we produce is useful immediately. I have faith that Even's work in "asset management" will lead to faster compile times before I need them, so that isn't a problem. But the fact remains that Elm's code output is several times slower than that of BuckleScript which does have an impact for many uses, just not for you uses where you find its speed good enough. As to games and heavy duty math, sure there are better programming environments for that but it is quite amazing what one can do even now with the fast browser engines available to us currently: although limited by being single threaded, BuckleScripts's JS output can come close to about only two times slower than highly optimized C++ code when both are written single-threaded. > Why would you want arrays instead of tagged-objects as the primary > data-structure? Just because Bucklescript does it doesn't make it faster. > Try benchmarking it yourself. I did. Depending on the browser, accessing > and/or changing an array isn't necessarily faster than accessing/altering a > javascript object. > The reason is that BuckleScript proves that Arrays are faster than "string" tagged objects and I have tried benchmarking it myself. In fact, I have gone further and manually substituted the use of Arrays rather than the string tagged objects in the generated Elm code to show that is the reason. The problem isn't so much the use of Array's versus objects/records, but the string tags, which as the Elm JS output doesn't preserve type information except by these tags, are continuously requiring string processing to determine the type of object at run time. Elimination of these strings by using the type information the compiler already has would greatly speed things even if objects are used, with the further advantage of Arrays being that their indices are numeric for slightly less processing (depending on the browser engine used). This becomes readily seen the more functional the code, with the use of tuples (tagged objects), lots of records (tagged objects), lists (nested tagged objects) and so on, and these passed as (essentially untyped) arguments across functions. > Finally, many people today are using Elm in production. There isn't a > general consensus amongst Elm's users that the language is too slow, > outputs too much code or is slow to compile (a cold compile of my app takes > ~9seconds. That is NOTHING compared to an equivalent typescript application > I'm working on, and isn't noticed in practice because of incremental > compiles). The problem with Elm (if you indeed could call it a problem) is > the lack of features. Many people would like better asset management, which > is why Evan is working on it. Personally, I would like some sort of > reflection support, as well as nested record syntax. Actually, I would > gladly take release of the local-storage module before any of those, and > re-connect notifications in elm-websockets. > Yes, Elm is fast enough for many purposes. Tree shaking programs such as the Google Compiler reduce code size. Compile time is currently adequate for many uses, although slow compared to something like OCaml/BuckScript that has been expressly optimized for compile speed. Some of your wish list is likely more library related than core Elm; and I have no objections to some extensions of even core Elm as long as they don't impact the ease of use/learning etc. of the core language. However, we appreciate that almost everyone has some pet features from another programming environment that they want to see brought to Elm, and that Evan must carefully weigh the merits of each against his overall Elm goals. The short of it is, the problems you're mentioning in this thread aren't > problems for the vast majority of Elm developers. Had it been, they > would've been addressed. Personally, I'm glad Evan isn't focused on the > things you've proposed. There are other things I want that I'm glad is > having a higher priority. > Different strokes... I am not really promoting the use of OCaml/BuckleScript which has its own warts (currently) although Hongbo has done an incredible job with it: I dislike Ocaml except as it closely resembles Elm/Haskell/F#. My point is that for those of us that need speed - at least a few that have chimed in on this thread - if it isn't addressed with the Elm compiler then Elm might migrate to a front end to OCaml which would schism development efforts and possibly hurt the language. My other point is that the sooner it is done the easier it will be. And it doesn't affect those that find current Elm speed adequate - all that is needed is enough contributors and co-ordination between the different developments. -- 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.
