[Speculation] What Does NodeJS Have on Haxe?

1

Hi everybody! I’ve been getting into Haxe lately by doing some development in Armory3D. I’m trying to get modding worked into the engine. :grinning: It’s been fun, surprisingly easy, and I’m really liking Haxe. It has an amazing type system and it’s other features like macros are great. Anyway, I just had a random thought the other day when I was looking into HashLink: “What does NodeJS have on Haxe and HashLink?”.

Everybody knows that NodeJS is ridiculously popular, but it is actually really simple in concept. NodeJS is just the V8 Javascript engine, with a standard library that includes bindings to the host system, and on top of it a very nice package manager. To add to its value, because it is Javascript, node programs can potentially run in a web browser with little-to-no changes.

Haxe already can run in the browser by compiling to Javascript, and HashLink supposedly can outperform V8 in initial benchmarks. I’m not for sure, but it also looks like HashLink is easier to embed than V8. Additionally, HashLink already has bindings to system calls. The biggest thing that Haxe is missing is a package manager that could compare with NPM. It should be possible somehow to get HashLink/Haxe setup so you could write native modules, like you can with Node, which would be cool too.

Everybody who uses Haxe says that it is way more powerful than Javascript and I agree. The biggest downfall to Haxe is that it doesn’t have the vast community and package manager that NodeJS has, but if we could solve that it seems like it would just be a really cool and useful tool.

This is all just speculation, but I thought it was a cool thought. Maybe it was mostly pointless, but I figured I’d throw it out there to see if anybody else had any thought at all about it. :slight_smile:

1 Like
2

Haxe has a package manager in haxelib, so to say Haxe doesn’t have one is a bit of a disservice. That being said, I currently use the NodeJS target for Kha for what you say - system calls - for testing purposes before compiling to either C++ or some other target later when building a release version. At least, that way, you are working with a target that compiles quickly. However, I would never ship a NodeJS version of software unless it was a web application, because of several things:

  1. The NodeJS and NPM culture has a massive amount of libraries that are less than ten lines of code, and because of the way NPM works, if the library is suddenly taken off NPM any project that has dependencies to it no longer works. It also forces you to work online, which is never a good thing. Of course, that’s why we use Haxe, to get rid of that burden and stupid methodology.
  2. Among serious video games programmers, managing memory is an absolute must. A lot of people who advocate for garbage collection say that it is just as good if not more efficient than managing your own memory, but that’s not the point. Laying out the memory in a certain way is crucial for certain systems, especially consoles where Quality Assurance requirements are strict. Outside of 3D games with AAA graphics or lots of triangles, meshes and textures being drawn on the screen every frame, using a garbage-collected Haxe target may be okay so long as it meets those requirements. But until you have a Haxe target that isn’t garbage collected so that you can manage your own memory, good luck getting a decent-looking video game efficient on video games consoles.
  3. As to the point above, HashLink would indeed be a decent competitor to NodeJS except… it’s garbage collected. Obviously, if you don’t care about memory and you just want to care more about getting stuff drawn on the screen, then I would say it’s fine. But once you start getting serious about performance and optimisations, there is only so much you can do before you have to switch to pure C, C++ or eventually JAI (currently being developed by Jonathon Blow).

For me personally, the only thing keeping me on Haxe currently is just how freaking simple it’s standard library and Kha is. Very simple, easy to learn and grasp, and has a wide range of targets I can play around with. Obviously, after everything I’ve said, it is ultimately about the simplicity of APIs. Because Haxe’s culture started off like that, all other APIs that have come out of haxelib by third party authors have followed suit, which, in my opinion, makes Haxe a great culture for decent, well maintained, simple and high quality APIs. There are very rare exceptions.

I know I’m derailing slightly, but my point is that although NodeJS is an option for the JavaScript target (all you have to do is include the hxnodejs library and make sure Node is installed on your machine), having an alternative to C++ and JavaScript in HashLink is great, but only if you don’t care about memory (for things I’ve stated above). For business critical solutions, this may not be an option, and I feel Haxe needs a fleshed out dedicated target where a garbage collector is optional, otherwise Haxe will have a difficult time convincing major companies to adopt it. For the Web, Haxe is a perfect substitute for both JavaScript and PHP.

EDIT: Another thing to note I should add, which I have noticed after reading further into HashLink is that Northgard takes 18.2 seconds to compile. That probably includes shaders but that is a long time to wait. When constantly testing and making improvements/bug fixes, compilation time starts to add up. JavaScript is still the winner with regards to compilation time.

1 Like
3

I’m not sure that js jit will cope with Northgard much faster. And 6 seconds with the compilation server for not a small game seems pretty good.

4

Yeah, I didn’t word that very well. I do know about haxelib and I wasn’t trying to bash on it, but it could still use some work. Lix actually looks like it will be what I’m thinking of. Something that handles different versions of haxe and packages a little bit better.

Also, the context that I was thinking of for Haxe instead of NodeJS was more for web related stuff. The kind of stuff node is most used for, not as much for games. ( I mentioned Armory at the top of the post, but that was just because that was what I’m using Haxe for at the time. ) So I think you get what I mean in that respect. :slight_smile:

5

Is Javascript not garbage collected?

6

@RobDangerous has said that Kha’s Krom target will run on consoles eventually. It is based on Kore ( written in plain C and C++ and should be memory managed ) and Krom is just the scripting on top of it so everything is fine. I think that is what the Kha HashLink target does. HashLink is the scripting layer on top of Kore. It seems to me that that would be perfectly suitable for full blown 3D games and graphics. The whole point of Kha is so that you can use a standardized and abstracted interface to platform specific and high performance backends.

Do you really need memory management for game logic if you already have an optimized graphics API?

7

Games in Unity3d are mostly written in C#. And guess what: C# is also garbage collected. Unity3D might be the most used game engine today, and games programmed on top of this engine can look very good.

Probably EA will not use something else than C++ to produce e.g. “Battlefield”, but saying you can not produce complex, good looking games without programming in a “not garbage collected language” is just not quite right.

8

Did you know that e.g. Java and Python are also “garbage collected languages”. Would you say there are not used for “business critical solutions”, and therefore no “major companies” are adopting them?

9

I’ve worked for a company called Smurfit Kappa and one of the companies they supply to, P&G Gillette, uses a forecasting system developed in Java for the Web, in other words, a Java applet. It’s bloody slow, and that’s my experience. Just for scrolling, I have to wait about 5-10 seconds just for the screen to update on MODERN hardware. Technically, it is a virtual machine running on a web server, so obviously it’s going to be slow, but you shouldn’t have to put up with that in this day and age, and people should not be developing applications in technology that should have been replaced decades ago.

I can’t say much on the side of Python, because I have no experience with it.

Also, when I say business critical solutions, I’m talking about software in a world where customer’s are impatient. When you’re a big company with a backlog of requests/queries that need to be dealt with, the slower the software the slower customer queries will be handled. Now, as I’ve said, if you don’t care about performance all that much you can probably get away with a garbage collected language as long as you code sanely. That is, even if some of the memory management is taken from you, you can still create memory layout that performs best in your given circumstances.

However - and there is always a caveat when it comes to software - garbage collection for high performance software is simply no good. There is a reason why AAA games are developed in C++ and almost always will (unless Jonathon Blow’s language can convince them otherwise), because in video games with high performance graphics where you have to move memory as fast as possible into RAM, the GPU, the CPU etc. a garbage collector will get in the way of that process.

Also, Unity3D’s engine is developed mostly in C++, which obviously is not - overwhelmingly - going to be garbage collected. You can make good looking games in Unity3D but certainly not on the scale of a AAA game, although it is possible if you put in a decent effort, use your own assets and shaders, and replace the standard launcher most Unity3D games come with. Yes, games are developed in C# using Unity3D, and also guess what: most of them are trashware. There are very few Unity3D games that have stood out that I know of, but feel free to name some.

One other thing to note about garbage collector’s: some will track everything you declare, using “smart” pointers to follow them around until they are “no longer in use” so to speak and make them “dormant”. I mean, a garbage collector that has to use up more memory and more CPU in order that your memory is “managed” properly. And yet people are still convinced they will make your applications more efficient.

This is WAAAAAAY too off-topic and apologies for derailing this far, but some things just have to be said.

But, to repeat my point again: if you don’t care about memory - perhaps you’re still learning or you need a tool that will get things done fast for you - then by all means use a garbage-collected language. Doesn’t mean you should use it for serious software that you intend professionals to use.

I’m going to stop ranting now. Hope you enjoyed :slight_smile:

Edit: Unless you are calling Managed code in C#, most of your C# is actually not garbage collected. Source And since most of the C# code in Unity3D are calls to the Unity3D engine developed in C++, most of the code you write in C# is unmanaged and therefore the Garbage Collector is hardly ever invoked unless you touch the CLR and the .NET APIs. The C# language, minus the CLR and .NET API calls, is not garbage collected. I suspect if you used purely the Mono Runtime and its API (which I don’t think uses .NET/CLR code for systems outside of Windows) you wouldn’t touch the garbage collector at all.

You can also mark your code unsafe meaning you can start using pointers and managing memory yourself. C# is a rather nice language if you can put up with all the warnings the C# compiler throws at you for managing your own memory.

10

I think the difference between NodeJS and Haxe is simple, users, they have more, which brings more users.
And to get the initial users NodeJS had the advantage that there already was a lot of javacript users.

Also it’s simple to explain NodeJS, run js outside of the browser, mostly on servers, with an easy api for system access.

While Haxe being a general purpose language it’s harder to show its advantages.
And it has (had?) a reputation of being only for games, which didn’t help when trying to sell haxe for web development.

Did we read the same link?
" In CLR all the code that is written is managed and it will be garbage collected. C# gets compiled into CIL and runs on top of CLR so all your C# code will be garbage collected." (emphasis mine)
" Conclusion C# and languages on top of CLR are garbage collected. They use generational garbage collection with 3 generations and an advanced tracing mark and sweep algorithm to figure out which objects are still alive."

But yes in unity most of the heavy calls ends up to the c++ code, which is why it’s better to do IsTag("mytag") than Tag() == "mytag".

And in the end GCs are called when you request memory, which in game you avoid as much as possible in the main loop.

And even AAA games don’t use c++ for gameplay, it’s just too impractical, lua is used a lot for this and also some visual tools for AI.

After that incident it has been severely limited, you can only unpublish a version up to 72h after it went online.

The big issue with that is that you need someone to do it, you could try :wink:
Also code made for other target would massively leak memory since they wouldn’t use the delete/free function of that target.

11

There’s so much misinformation in this thread I don’t even know where to begin so I’ll just leave all of you with: Profile your code and ignore all hearsay.

14 Likes
12

Well, to put it simply: Haxe is for indie games, NodeJS is for servers. The latter is a vastly larger marked, with vastly larger players.

Of course you can use Haxe for other things than indie games (for example to build NodeJS applications), but that’s not evident to the outsider, for a whole array of reasons.

13

This isnt related to Haxe so much as to Luke:

I work with one of my main clients on a government medical system that has a through put of millions upon millions of messages per hour (100s of millions) and TB’s upon TB’s of (medical) data per month. Its pretty “critical”, in fact, there are certain SLAs (service licence agreements) that require things run in a certain way at a certain speed. Ie, a PDS (patient demographic system) query can take no longer than 300ms 98% of the time; or an EPS (electronic presription system) message cant take more than 1s more than 98% of the time, or ERS (refferals) cant take more than 2 seconds (these are the bigs ones, 100s and 100s of MBs at a time)

This system is lightning fast, based (and heavily modified) on Karaf with a Cassandra backend. Its Java, its memory managed. Could there be hiccups? Sure. As Rob said, you profile and fix. In fact, we used to kick into C++ because we thought it was a shortcut - it wasnt. GC now-a-days (and agruably before) is highly effecient. (note: I cant talk about games at all)

Luke, you would have us believe that you could write a Karaf type system in C++ and it wouldnt be so full of memory bugs it wouldnt be unusable. I disbelieve that. I couldnt - I highly doubt you could.

You would have us believe that you had a bad meal in a restaurant one day, and decided that saucepans were the issue, and they dont make sense. It was the chef.

Again, nothing to do with haxe, but i like managing memory, but not to the point where i compromise the system with my (quite clear) lack of understanding about how it actually works.

Ian

EDIT: its 99.7% of the time, thats the SLA

8 Likes
14

Just a small comment wrt Haxe/HashLink for game dev: two latest very successful games have been developed using Haxe + HashLink + Heaps.io : Northgard and Dead Cells, the later also runs on Nintendo Switch, PS4 and XBox using native HashLink compilation.

Whole recompilation for Northgard takes 18.2 seconds, but as stated on https://hashlink.haxe.org/ it compiles in less than 3 seconds after that when you’re making changes - thanks to compilation server.

6 Likes
15

Talking about Battlefield 1, they used React+Mobx+Javascript and a custom renderer to make their UI :slightly_smiling_face:.

2 Likes