Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

On Friday, 27 January 2017 20:22:23 UTC+7, Bob Zhang wrote: > > Hi Gordon, your facts can be changed every post. > And you spent a month in tweaking your elm expert's code to match the perf > of newbie's BuckleScript code, I am still not sure you reach there. > I suggested we take the

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

On Tuesday, 24 January 2017 18:47:49 UTC+7, Robin Heggelund Hansen wrote: > > 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

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

On Friday, 27 January 2017 09:13:12 UTC+7, Bob Zhang wrote: > > As I said, you already get convinced elm is better for you, then happy > coding in elm. I am not interested in a biased judgement. Hongbo, I'm making no judgement at all other than for the facts I see and the analysis I make based

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

As I said, you already get convinced elm is better for you, then happy coding in elm. I am not interested in a biased judgement. On Thu, Jan 26, 2017 at 7:29 PM GordonBGood wrote: > On Thursday, 26 January 2017 21:13:33 UTC+7, Bob Zhang wrote: > > Hi Gordon, > I think it

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

On Thursday, 26 January 2017 21:13:33 UTC+7, Bob Zhang wrote: > > Hi Gordon, > I think it is inappropriate to discuss BuckleScript performances on this > mailing list (people may feel unhappy about this), if you are interested, > we can discuss on BuckleScript github issues(I will create a

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

Hi Gordon, I think it is inappropriate to discuss BuckleScript performances on this mailing list (people may feel unhappy about this), if you are interested, we can discuss on BuckleScript github issues(I will create a mailing list too). A minor comment: > As Elm does not have mutable linear

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

Hmm, compare uglify with google closure is really misleading .. ( I am not a fan of google or even remotely close, but as a compiler engineer , we should respect basic facts) On Thu, Jan 26, 2017 at 7:37 AM Robin Heggelund Hansen wrote: > I was mostly talking about size. I

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

I was mostly talking about size. I know Closure very well, and I'm well aware of what code must look like in order to get the most out of advanced opts. The way Elm is compiled makes it easy for uglify to get the same results in mangling and dead-code elimination, but of course it won't do

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

Uglify essentially removes functions that are not added to objects (how you export functions from "namespaces"). Since Elm adds all functions to a single local-scope, and then only exports ports and the main function, it's very easy for uglify to see what functions are unused, and can therefore

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

I use browserify for some code via brunch, rollup for others, I run both of those through uglify + closure when building a 'prod' release. browserify and rollup and both blazing fast in compile time with very large bases of code, but rollup prunes based on functions called (meaning it can

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

On Wednesday, 25 January 2017 22:25:39 UTC+7, OvermindDL1 wrote: > > Sent too soon. > > Also, uglify is a minimizer, it does a *lot* more than tree shaking. > > > On Wednesday, January 25, 2017 at 8:25:10 AM UTC-7, OvermindDL1 wrote: >> >> Tree Shaking as implemented by Brunch and Webpack

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

On Wednesday, 25 January 2017 19:25:40 UTC+7, Bob Zhang wrote: > > elm is a reasonably fast language, I think it might run even faster than > purescript, enjoy your work! Yes, Elm is reasonably fast for some programs such as the functional primes generator but is inconsistent and not very fast

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

Sent too soon. Also, uglify is a minimizer, it does a *lot* more than tree shaking. On Wednesday, January 25, 2017 at 8:25:10 AM UTC-7, OvermindDL1 wrote: > > Tree Shaking as implemented by Brunch and Webpack default setups at least > only prune based on if a module is accessed or not (which

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

I am not interested in campaign, it's not fun. But I cannot help replying when I see some inexact arguments... elm is a reasonably fast language, I think it might run even faster than purescript, enjoy your work! On Wed, Jan 25, 2017 at 4:55 AM Robin Heggelund Hansen wrote:

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

> Actually tree shaking will do absolutely nothing for Elm code as Elm > compiles everything into a single module that all highly indirectly > references itself. It would help with bucklescript as it outputs modules, > but bucklescript already tree-shakes as part of its compiler

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

I would suggest we stop further discussions since it is quite lengthy and doesn't make too much sense. No matter how much better job BuckleScript did, the 'Evan knows' means it will be solved magically soon, this is a little unfair to my work. I understand there are lots of factors when choosing

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

I have been working on compilers professionally for more than 8 years, I did not read your ocaml code, so I am not sure it's performant ocaml code. But anyway, I think you already convinced yourself elm suits your need better :-) On Tue, Jan 24, 2017 at 11:44 PM GordonBGood

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

Thanks for your update. To be fair, BuckleScript is a one year project, I will keep focused on improving performance and build speed, I assure that you can expect even more amazing perf. Btw, we have some of the best front end developers to actively working on UI frameworks using BuckleScript

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

On Tuesday, 24 January 2017 18:47:49 UTC+7, Robin Heggelund Hansen wrote: > > 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

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

On Tuesday, 24 January 2017 23:00:21 UTC+7, OvermindDL1 wrote: > > On Monday, January 23, 2017 at 6:27:47 PM UTC-7, GordonBGood wrote: > >> Yes, Elm is fast enough for many purposes. Tree shaking programs such as >> the Google Compiler reduce code size. Compile time is currently adequate >>

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

On Monday, January 23, 2017 at 6:27:47 PM UTC-7, GordonBGood wrote: > > 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 >

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

Hi Gordon, the browser based compiler is a bit old , the current npm release is 1.4.1 . We will update the browser based compiler(compiler compiled to js) next week, please report issues according to the npm releases, thanks! On Mon, Jan 23, 2017 at 11:40 PM GordonBGood

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

On Tuesday, 24 January 2017 09:37:32 UTC+7, Richard Feldman wrote: > > 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

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

Hi Hongbo, I just quickly checked with the try BuckleScript website with the following code: let test = [| 0; 1; 2; 3; 4; 5 |];; let _ = test.(-1) <- -1; Js.log test.(-1) to get the answer -1, which indicates that it is indexing outside the bounds of the array to set a new value. I

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

Sorry, typo... I mean data representation is not the only reason that BuckleScript runs fast On Mon, Jan 23, 2017 at 9:41 PM Bob Zhang wrote: > I agree, we did a lot of work to engineer performance, data representation > is part of the reason that BuckleScript running

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

I agree, we did a lot of work to engineer performance, data representation is part of the reason that BuckleScript running fast, it's definitely the only one On Mon, Jan 23, 2017 at 9:37 PM Richard Feldman wrote: > The reason is that BuckleScript proves that Arrays

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

> > 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

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

We do bounds check, but we also provide unsafe version which does not do bound check for performance reasons. If you find the safe function which does not, you are welcome to file an issue On Mon, Jan 23, 2017 at 8:41 PM GordonBGood wrote: > On Tuesday, 24 January 2017

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

On Tuesday, 24 January 2017 01:26:49 UTC+7, OvermindDL1 wrote: > > Bucklescript de-curries as much as possible, however you can also force it > in the type system explicitly by adding the annotation type of `[@bs]` to a > function (type) definition, that enforces uncurrying at the type level and

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

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 >

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

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

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

On Monday, January 23, 2017 at 10:52:12 AM UTC-7, GordonBGood wrote: > > I think everyone hangs around this and other Elm discussion forums because > we love the Elm concept of a simple functional language that promises to > eliminate the need to deal with JavaScript; but unfortunately, due to

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

I both like what you have to say about why writing OCaml code is so much more efficient than writing Elm code (and working with Elm in the last week agree completely with you) but also despair that it is true as to all of the warts in the Elm compiler I think everyone hangs around this and

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

On Wednesday, January 18, 2017 at 9:53:31 AM UTC-7, Rupert Smith wrote: > > In my view, this also provides very good justification for not allowing > native code into packages.elm-lang.org. Porting Elm to another platform > in this way is manageable. > Entirely yeah, native code even in core

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

On Tuesday, January 17, 2017 at 4:27:36 PM UTC, OvermindDL1 wrote: > > On Tuesday, January 17, 2017 at 4:25:08 AM UTC-7, Rupert Smith wrote: > >> An alternative might be to re-write the Native modules in the Elm core in >> OCaml. There isn't a huge amount of it. >> > > Precisely this, I've

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

On Saturday, January 14, 2017 at 3:13:40 PM UTC-7, GordonBGood wrote: > > I saw that over on elm-dev, but haven't tried it because compilation speed > isn't a problem for the Elm code I have written so far. The only reason I > brought it up is OvermindDL1's comment >

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

On Tuesday, January 17, 2017 at 5:23:33 AM UTC, GordonBGood wrote: > > On Monday, 16 January 2017 21:09:43 UTC+7, Rupert Smith wrote: >> >> On Saturday, January 14, 2017 at 1:51:39 AM UTC, GordonBGood wrote: >>> >>> All that this would take would be to write an Elm parser into the first

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

On Saturday, January 14, 2017 at 1:51:39 AM UTC, GordonBGood wrote: > > All that this would take would be to write an Elm parser into the first >> stage of the OCaml pipeline? You'd also need to compile the Native modules, >> is there already some way to feed them into the Ocaml pipeline? >> > >

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

This will be a fundamental change to the architecture of the elm compiler, it is cool to see elm is also moving in this direction in the next several months! On Mon, Jan 16, 2017 at 1:09 AM GordonBGood wrote: > Richard and Hongbo, I'm relieved to know that others are aware

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

Richard and Hongbo, I'm relieved to know that others are aware of the long compilation times = linking times for big projects and that it will likely get fixed in the next several months. I'm not going to worry about it in that case, and Hongbo's information on how little time it can take as

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

> > you need recompile that module and regenerate a monolithic js file, the > larger project it gets , the worse compilation time you get in elm mode. If > you have experience in C++, you know the bottle neck used to be linking, it > is quite common for a c++ project to spend 20minutes in

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

Sorry, I didn't mean es6 module, I meant map one ocaml (or elm) module to one runnable js module(amdjs, commonjs, or es6) so you get separate compilation. This is just my observation , please take it with a grain of salt: in general, it takes 20ms-80ms for BuckleScript to compile a single file,

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

Hi Gordon, In case you are interested, this is a link I made to show the excellent compile time performance of BuckleScript (https://twitter.com/bobzhang1988/status/810508070350680066 ) It takes around 0.58s to do a clean build: 55

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

After working with the elm compiler just a bit from the outside, I think there might be build time improvements to be had by improving the build info dropped in elm-stuff. I think reducing the number of graph.dat and .elmi files read during the build process might help. On Sat, Jan 14, 2017 at

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

On Sunday, 15 January 2017 11:56:18 UTC+7, Bob Zhang wrote: > > I would be very surprised if parsing is the bottle neck > In most cases, type checking and register allocations (could be quadratic) > takes much more time. OCaml's type checking algorithms is very clever, > almost linear in most

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

On Sunday, 15 January 2017 11:14:55 UTC+7, Richard Feldman wrote: > > I'm wondering why the Elm compiler is so slow at parsing if that is where the slow-down is >>> >>> Evan recently rewrote the parser to be much faster. >>> >>> You can try a preview binary >>>

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

I would be very surprised if parsing is the bottle neck. In most cases, type checking and register allocations (could be quadratic) takes much more time. OCaml's type checking algorithms is very clever, almost linear in most practical use cases. On Sat, Jan 14, 2017 at 11:14 PM Richard Feldman <

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

> > I'm wondering why the Elm compiler is so slow at parsing if that is where >>> the slow-down is >>> >> >> Evan recently rewrote the parser to be much faster. >> >> You can try a preview binary >>

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

On Saturday, 14 January 2017 12:40:53 UTC+7, Richard Feldman wrote: > > Keep in mind that code is the easy part > ; the major thing standing > between Elm and a different compilation target than JavaScript is 1-2 years > of design work to figure out

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

Keep in mind that code is the easy part ; the major thing standing between Elm and a different compilation target than JavaScript is 1-2 years of design work to figure out a quality user experience. > I'm wondering why the Elm compiler is so slow

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

On Saturday, 14 January 2017 00:38:03 UTC+7, OvermindDL1 wrote: > > But yes, translating Elm to OCaml/Bucklescript would not at all be a hard > task. :-) > An Elm front-end to OCaml sounds interesting and I especially like the sound of "faster compilation speed" (about 400 times faster???).

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

On Friday, 13 January 2017 22:40:07 UTC+7, Rupert Smith wrote: > > On Friday, January 13, 2017 at 3:18:48 PM UTC, OvermindDL1 wrote: >> >> That is actually why I think Elm should compile to a a different >> back-end, like ocaml/bucklescript or so. The syntax is uniform enough that >> making an

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

On Friday, January 13, 2017 at 10:10:28 AM UTC-7, Joey Eremondi wrote: > > Even a direct Elm to OCaml translation wouldn't be too hard. Elm is not > the same as OCaml, but my understanding is that most of its features are > included in Elm (row polymorphism, strict evaluation, >

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

Even a direct Elm to OCaml translation wouldn't be too hard. Elm is not the same as OCaml, but my understanding is that most of its features are included in Elm (row polymorphism, strict evaluation, first-class-functions). OCaml has lots of features Elm doesn't want (like mutable references) but

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

On Friday, January 13, 2017 at 8:40:07 AM UTC-7, Rupert Smith wrote: > > All that this would take would be to write an Elm parser into the first > stage of the OCaml pipeline? You'd also need to compile the Native modules, > is there already some way to feed them into the Ocaml pipeline? >

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

That is actually why I think Elm should compile to a a different back-end, like ocaml/bucklescript or so. The syntax is uniform enough that making an elm->ocaml/bucklescript transpiler would be just a matter of re-using most of the existing parser in OCaml, which is already beyond blazing fast

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

On Thursday, 12 January 2017 22:42:05 UTC+7, OvermindDL1 wrote: > > On Wednesday, January 11, 2017 at 10:43:11 PM UTC-7, GordonBGood wrote: >> >> On your advice, I've reread the ReasonML documents as I got mislead by >> looking at ReasonML/Rebel and that is at too early a stage for me to >>

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

We do have around 12 passes to optimize js code, will have more advanced optimizations coming in 1.5 Note the optimization is written carefully so it will not slow down compile time. To squeeze the compiler performance, some performant critical code was changed to c in recent release On Thu, Jan

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

On Wednesday, January 11, 2017 at 10:43:11 PM UTC-7, GordonBGood wrote: > > On your advice, I've reread the ReasonML documents as I got mislead by > looking at ReasonML/Rebel and that is at too early a stage for me to > consider (also support for BuckleScript is currently broken). I liked the

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

On Wednesday, 11 January 2017 23:20:24 UTC+7, Bob Zhang wrote: > > 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

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

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

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

On Wednesday, 4 January 2017 21:05:58 UTC+7, Bob Zhang wrote: > > Hi Gordon, > As you can see, BuckleScript already did a very good good job here, of > course, there are still places for improvement. To write extremely high > performance code, you should avoid creating a closure in a tight

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

Hi Gordon, As you can see, BuckleScript already did a very good good job here, of course, there are still places for improvement. To write extremely high performance code, you should avoid creating a closure in a tight loop, here you can lift the `nxtc` into the toplevel, in the future, we will

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

Hi Bob/Hongbo, I've run into my first speed problem with BuckleScript: When it decides it needs to form a closure of captured free binding(s), it creates a "function returning a function" with the outer function's arguments being the current state of the "pure" captured bindings, and the

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

On Tuesday, 3 January 2017 01:14:57 UTC+7, Bob Zhang wrote: > > Hi Gordon, >Thanks for your lengthy reply. >I didn't try to convince you that OCaml is better than Haskell, they > are different styles : ). It just feel a little weird that "when you want > performance, you should switch

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

On Sunday, 1 January 2017 22:27:40 UTC+7, Bob Zhang wrote: > > Note that a high quality optimizing compiler like BuckleScript outperforms > native JS significantly > Elm. > (See the benchmark here: > http://bloomberg.github.io/bucklescript/slides/preview/bb-reveal-example-presentation.html#/5/1

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

Lawrence, please keep it civil. > > -- 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

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

On Wednesday, 28 December 2016 21:23:19 UTC+7, Peter Damoc wrote: > > > > On Wed, Dec 28, 2016 at 3:10 PM, GordonBGood > wrote: > >> >> So you are saying we can already do the following: >> >> type Msg = ProgProgress Progress | ProgCancelled | ProgDone Answer | Tick >> >>

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

On Sun, Jan 1, 2017 at 1:41 PM, GordonBGood 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

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

I think that the author and supporters may not have tested the latest version 2.1 on Windows and the problem my be due to differences between using *nx pthreads and pwinthread for multi-processing/multi-threading. Would really like to try it, but will wait until they sort this. Have logged

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

I also tried it with ghc-8 and it didn't seem like it was going to work, although I could have just not got the right steps. Decided to hold off. Haskell changes relatively quickly compared to other languages. On Sat, Dec 31, 2016 at 4:14 AM, GordonBGood wrote: > On

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

> > On Saturday, 31 December 2016 03:25:53 UTC+7, art yerkes wrote: >> >> The promise of never needing to really get dirty and debug live Elm code >> is real, and it's true that nothing else quite lives up to that. >> > > Amen to that: the advantage of being simple and placing restrictions on >

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

I can comment a bit on purescript and fable (and ghcjs) from a n00b perspective in all three. - Purescript's type system is not as well polished as haskell and has IMO a steeper learning curve. - Purescript's package ecosystem is very immature. - Purescript's js interop is very easy and doesn't

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

On Wed, Dec 28, 2016 at 6:25 PM, GordonBGood wrote: > > > Related to speed, it seems to me that the working Fable (F#) code linked > from your link above is more responsive than the working Elm code from > another link on that page, both for the same sample application; am

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

On Thursday, 29 December 2016 06:22:22 UTC+7, Martin DeMello wrote: > > On Wed, Dec 28, 2016 at 3:16 PM, GordonBGood > wrote: > >> Even if this method works, the interim method means I have to produce >>> JavaScript code which I understood that the purpose of Elm was to

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

Thinking about this further, yes, one can wrap the logic to talk to a pair of ports in a way that makes them work like commands that actually include responses. Doing so, however, requires the following departures from standard Elm practice: 1. Communicate up from update functions using lists

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

> > Task.succeed () |> Task.andThen \_ -> do hard stuff > Sorry, that should be Task.map not Task.andThen. -- 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

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

Regarding the pain of wiring up a subscription port, have you seen Task.perform ? It allows you to do async work using no ports other than The Elm Architecture itself. As for doing pure but computationally intensive work

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

On Wed, Dec 28, 2016 at 3:10 PM, GordonBGood wrote: > > So you are saying we can already do the following: > > type Msg = ProgProgress Progress | ProgCancelled | ProgDone Answer | Tick > > port startLRP : () -> Cmd msg > > port cancelLRP : () -> Cmd msg > > subscriptions

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

On Wednesday, 28 December 2016 16:44:45 UTC+7, Peter Damoc wrote: > > > > On Wed, Dec 28, 2016 at 10:29 AM, GordonBGood > wrote: > >> It looks like the implementation of this StackOverflow answer >> (ignore the question and

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

On Wednesday, 28 December 2016 15:33:25 UTC+7, Peter Damoc wrote: > > > > On Wed, Dec 28, 2016 at 9:06 AM, Mark Hamburg > wrote: > >> Just to make it clear, I'm not particularly calling for an easier way to >> create "subscriptions". I'm calling for a way to do one of the

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

Just to make it clear, I'm not particularly calling for an easier way to create "subscriptions". I'm calling for a way to do one of the following — either is fine, each have their pluses and minuses: 1. Expose a synchronous, externally defined function that takes JSON (or really anything a

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

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

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

On Wed, Dec 28, 2016 at 6:40 AM, GordonBGood 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

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

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

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

Tight calculation loops and performance matters a lot in some cases such as complex form validation. I've spoken with at least one company suffering these bottlenecks with Elm, but it was resolvable by just changing how the data is modelled. For performance in production, if you're not running a