Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dev log #4 - trajectory - feedback #20

Open
ruby0x1 opened this issue Apr 20, 2017 · 12 comments
Open

dev log #4 - trajectory - feedback #20

ruby0x1 opened this issue Apr 20, 2017 · 12 comments
Labels

Comments

@ruby0x1
Copy link
Member

ruby0x1 commented Apr 20, 2017

Post your feedback and questions on luxe dev log # 4 - trajectory here

@DjPale
Copy link

DjPale commented Apr 21, 2017

As usual a very interesting read! What is still a bit unclear to me is Haxe's role in this - will luxe move away from this entirely or partly?

@tanis2000
Copy link

It looks like Haxe might fit in as a scripting language at this point. But then the question is: would it make any sense to carry Haxe around when there are other more lightweight scripting languages available?

@anissen
Copy link

anissen commented Apr 21, 2017

Reading this post I'm also concerned about whether Haxe is ditched entirely in favour of C/C++. In my opinion, Haxe is one of the key advantages of Luxe and I would be very disappointed to see it go.

@mikicho
Copy link

mikicho commented Apr 21, 2017

Im not webgames guy, but I must to tip my hat on your long road that luxe (and snow and other framworks) did!

@ghost
Copy link

ghost commented Apr 22, 2017

I did not see this coming I have to say, but it kind of makes sense, especially with the web techs maturing. Really really want to know what's the plan for the scripting language though ;)

@igorhart
Copy link

igorhart commented May 4, 2017

For me as a JS developer, Haxe is the greatest feature of luxe. I am willing to learn C++ if there is no other choice, though.

@ruby0x1
Copy link
Member Author

ruby0x1 commented May 4, 2017

Keep in mind the difference between the core and the user code. You won't have to use c++. Also remember native targets still run on c++ now anyway, the only difference is the amount of layers and how much of the user has to run into or setup.

The post was referring to the core specifically, the benefits were mentioned in the dev logs as well that users having to deal with c++ is not a great thing - the goal was to remove that need (which we have). There's nothing to worry about, there.

I'll add more details soon but definitely I would not make the user code c++ 💨

@igorhart
Copy link

igorhart commented May 4, 2017

Glad to hear that, looking forward to the next dev update 👍

@tanis2000
Copy link

I'm waiting to see which scripting language you're going for :)

@ghost
Copy link

ghost commented May 4, 2017

Same here ;)

@matulkum
Copy link

matulkum commented May 30, 2017

If really a new language is considered, I think "Kotlin" might be an awesome choice:
It compiles to readable js code already, they are working on native target (trough LLVM), the language syntax is really nice, great IDE support and it is even backed by Google now. Looks like a great option.

@ruby0x1
Copy link
Member Author

ruby0x1 commented May 30, 2017

@matulkum thanks for the comment, though the post goes over the choices for the engine core. Kotlin is indeed interesting but not right for the use case mentioned :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

7 participants