LuxLang / lux

The Lux Programming Language
Mozilla Public License 2.0
1.69k stars 50 forks source link

Start Up Time #45

Closed leblowl closed 6 years ago

leblowl commented 6 years ago

I like the project, although I don't really understand most of the design decisions and what they would mean to me in real world applications (due to my own ignorance). I like the goal to target many platforms. I work with Clojure and it generally takes a long time to start for me. Is there any goal to minimize this start up time for Lux on JVM? Is this even possible? Thanks

LuxLang commented 6 years ago

Is there any goal to minimize this start up time for Lux on JVM?

It isn't an explicit goal that I'm pursuing, but it's something I am mindful of. One thing is that Clojure has a huge runtime infrastructure in the form of the clojure.jar dependency all Clojure programs include. It brings in several JVM classes, plus the entirety of the Clojure standard library, and the Clojure compiler itself.

In contrast, the JVM backend for Lux just generates 2 classes for you (a runtime class with various static methods for doing some basic operations, like working with tuples and variants), and an abstract class for representing functions, that actual functions you write end up extending.

Because of that, the amount of initialization a Lux program has to do compared to a Clojure program is very small. Also, all Lux programs are AOT compiled, while that is optional for Clojure, which means you may have to pay for namespace compilation during runtime in the case of Clojure.

I can't give you any numbers, since I haven't bench-marked anything, but that should simplify things a bit.

leblowl commented 6 years ago

Ok thanks, I will look into some of these points that you mention and do a little research. I might have some more questions about this in the future, but we can close this for now.

On May 26, 2018 09:43, "The Lux Programming Language" < notifications@github.com> wrote:

Is there any goal to minimize this start up time for Lux on JVM?

It isn't an explicit goal that I'm pursuing, but it's something I am mindful of. One thing is that Clojure has a huge runtime infrastructure in the form of the clojure.jar dependency all Clojure programs include. It brings in several JVM classes, plus the entirety of the Clojure standard library, and the Clojure compiler itself.

In contrast, the JVM backend for Lux just generates 2 classes for you (a runtime class with various static methods for doing some basic operations, like working with tuples and variants), and an abstract class for representing functions, that actual functions you write end up extending.

Because of that, the amount of initialization a Lux program has to do compared to a Clojure program is very small. Also, all Lux programs are AOT compiled, while that is optional for Clojure, which means you may have to pay for namespace compilation during runtime in the case of Clojure.

I can't give you any numbers, since I haven't bench-marked anything, but that should simplify things a bit.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/LuxLang/lux/issues/45#issuecomment-392269389, or mute the thread https://github.com/notifications/unsubscribe-auth/AD2siGeT4kEumyKmLVsl6cor4UZK4b5lks5t2XgcgaJpZM4UO9By .