I’d like to make reasonable choice of target for server side of my haxe project. It’s multiplayer pokerroom-like game. Client targeted to use native mobile and HTML. Server planned as easily scalable with stateless services, binary protocol and db support (mysql or mongo) at linux docker container.
I have tested nodejs approach and it shows sappiness of my choice for the local one threaded solution.
Is there any drawbacks or probably usage of neko or hashlink will give some performance boost and flexibility? Your other thoughts are highly appreciated.
It depends.
Personally, I would try – GitHub - kevinresol/hxuv: libuv bindings for Haxe
Edit: synthetic benchmarks are pointless
1 Like
a bit self-promotion here, but you can try Colyseus as a server and the Haxe client: https://github.com/colyseus/colyseus-hx 
Uhm, those benchmarks don’t actually seem to prove anything about hxcpp being the fastest. In Justo’s benchmark from 2016 js, hlc and hxcpp have overall similar results and in Dmitry’s benchmark from yesterday hxcpp is slower than js in everything but the startup test and slower than hlc in everything but the Mandelbrot test.
I repeat myself but… Haxe->JS tends to have the best performance for unoptimized Haxe code (fast garbage collection, fast anons,…), hxcpp tends to have the best performance for optimized Haxe code (pure math code is translated to mostly equivalent C++, can use 32 bit floats,…) - so what’s fastest depends very much on you. Not much personal experience with hlc yet but the situation seems to be similar to hxcpp now.
5 Likes
Oh, my post now seems to be out of context because a previous post was edited. Second paragraph is still relevant though.
Thanks for the answers. I have chosen nodejs as server side and already have implemented websocket based protocol. Everything looks consistent for the moment.
I recently chose openresty(nginx+luajit) to instead of golang as the web server although it’s not haxe. since the luajit is quite fast and quite easy to call c language module.
(I didn’t use haxe->lua because the compiled code lookes ugly)
That isn’t very constructive. Is there anything in particular that you think we could improve on?
4 Likes
Why would you care that much about the generated code? As long as it works well and is performant, why would aesthetics matter?
For me sometime I need to work with the generated codes directly (debugging when Haxe couldn’t give enough info, the generated codes are used by other projects in their native languages…). Sometime it’s not a choice made by me and sometime it’s not me who have to work on them.
I understand that, and I agree. The generated code should be readable and not cryptic, but I think all of Haxe’s targets have readable code, although I mainly use the JS target (FWIW, I rarely use source-maps).
@R32 said he thinks the code is ugly, which can mean lots of different things, including non-readable code (in his opinion) or lacking some kind of style, which was what I understood. @R32 Could you elaborate?
May help with both debugging and also use by other projects.
Towards the end of the discussion thread there is working code that I have been using now for over a week. Having comments as part of Haxe compile to target languages has saved me time debugging when working on about 10+ K lines of Haxe with 3+ K lines of comments in my “Hobby” project (and allowed an unexpected bonus to a primary goal).
@Melon
Welcome to Haxe Forum!
Readability
is a primary idea I use when typing in code and comments;
No matter what programming language I am using.
I think of source code as being like a database. Often databases are optimized for Read operations more than Write ops. I optimize my source code for Read operations by us Humans.
If I can save someone Reading the sources 10 seconds by doing 1 minute of typing then that is what I do. I call myself a Lazy software developer but in this case the Lazy part is for Future Ease of Reading.