Haxe: The ultimate cross-platform language

1

Hi Campers! I’m here to introduce Haxe to people who have never heard of it. I just heard about it a week ago was very impressed; I want to get the word out, see what people think! :slight_smile:

What is it?

Haxe is an open source, strictly typed programming language that is made to be cross-platform, but Haxe has a different approach to being cross-platform than other languages. Haxe is able to run natively on the target platform by compiling to that target’s native language. Haxe can compile to an impressive number of different languages: Java, Python, C#, C++, Javascript, PHP, and Lua. Haxe can also run on two virtual machines ( runtimes ), Neko and HashLink, both made by the Haxe Foundation. It’s almost freaky that you have a language that is actually meant to be compiled to all these different languages. You can pretty much target almost any platform you could ever want to.

What can you use it for?

Haxe’s use cases cover a large spectrum of software development. You can use it to build CLI’s, Mobile Apps, and websites as well. A particularly interesting idea is using Haxe to write both the server-side backend and the web frontend of a web application. The backend code can get compiled to PHP, Neko, or Node, and the frontend code can get compiled to Javascript to run in the Browser.

It seems, however, that the most common use case for Haxe is the development cross-platform games. There are a number of libraries and frameworks for building cross-platform games that are built on Haxe. There is also WIP game engine called Armory 3D that I think will be pretty amazing when it’s done.

What is the language itself like?

I haven’t spent very much time at all using the language yet ( I just found out about it a week ago :wink: ), but I have read a bit of the manual and, so far, I like it a lot. Haxe is an object oriented language that is strictly typed; it should be easy to learn if you have any experience in another object oriented language like Java, C#, or C++. Its syntax has borrowed a lot from Javascript. What I like about it is that it give you the extra safety of a statically typed language, but it also tries to be as flexible and non-intrusive to your programming as possible.

For example, you are not, in many cases, required to specify the type of a variable if the type can be inferred by the compiler. Haxe also has the Dynamic type that allows you to work around static type checking if you don’t know what type a variable will be until runtime. It is nice and clean to read and write and it keeps you safe while not limiting your flexibility.

What state is it in?

As far as I can tell, it seems that the Haxe community is still relatively small, but I think that the potential of Haxe is very high. The language itself seems to be stable and the Haxe Foundation does provide paid support plans, which will hopefully help fund the Haxe project. I would love to see the Haxelib library grow and to see more projects developed in the language. That’s part of the reason I am posting this topic, I’m hoping that more people will find out about it and start to use it. :smile:

Anyway, if you think this is cool, tell other people about it! Get the word out. The Haxe community could really use the help. If you’re interested in making games, check out Armory 3D as well. Its not done yet, but I think that it could be awesome. :tada:

2 Likes
2

Not sure I get the point.

If you want to build web client apps, you will use JavaScript. If you want the server language to be the same as client, you can just use Node. You are using the same language on both stacks natively and without compilation from another language.

If you want to do low-level programming, you will be using C and C++ anyway, so why would you want to use a high-level language?

You can build desktop and mobile apps with JavaScript.

So, maybe I’m missing the point, but it seems to be a “Jack of all trades, master of none”. Why not just learn JavaScript? If you need to use another language, you should probably just learn the language itself anyway.

3 Likes
3

Yes, I see your point about Javascript. I myself have wondered if it is actually useful for web applications because of that. I myself have been planning on using Node’s Express for backend and Quasar for frontend for my own apps. Quasar also does desktop applications as well so that covers that too. I did think that it was interesting, but at this point Javascript is most likely still a better option because it has a huge community and many libraries around it. It does seem like Haxe might have value in this regard if you liked it more than TypeScript, though.

I do think that Haxe is useful for native apps that need high performance. I would definitely rather write a nice clean high level language and let Haxe handle all of the platform independence for me than write low-level C or C++ ( that could just be because I am not a low-level programmer, but I imagine that it would still be nicer to avoid C and C++ if you could ). That could be why Haxe is primarily used for games. It seems to be the application that most effectively uses its capabilities.

4

I could see this being useful if you’ve got a company targeting many platforms, but wanting to keep developers mobile or if they have really small teams. Being able to write in one language and target many platforms would be really cool, but I’d be interested to see how that pans out practically. Whether you’re deploying to Node, Unity, or an embedded device, you’ll still need someone who understands the target platform.

It’s not something I’m going to get into, but I hope the language’s community grows.

1 Like
5

I’m not yet sure if there are things that make it more or less useful than other languages that you would use to do the same tasks. For example, what would be the reason to use Haxe instead of Python or Java in situations that you would normally use one of those. Haxe would have a disadvantage because the community is much smaller.

Maybe the biggest thing that I like about it is that it is just as high performance as C or C++ but is a language that is easier to learn. You might be able to say that about C# too, though. There may or may not be much advantage over other language options, but I am curious about it and I like the way that it is designed. I’m interested to see what other people think about it for sure.

6

Hi,
I use Haxe for many years to build large scale web applications. Haxe is much more powerful than Javascript.
You can compare it to Typescript https://blog.onthewings.net/2015/08/05/typescript-vs-haxe/ but still have many benefits.
For exemple you can do isomophism with javascript front-end and php/java/or c# back-end.
You can also have a look on Haxe React https://github.com/haxe-react to see how a popular javascript framework is used.

1 Like
7

Cool! My gut reaction to Haxe was that it had great potential, but I couldn’t necessarily provide any founding for it. I’m glad to hear that someone is using it and that it is effective. :smiley:

8

Haxe is a pretty cool language with a powerful static type system that allows you to design stuff in a hybrid oo/functional way, e.g. it has sum types (including GADT) with pattern-matching, or abstract types (like newtype). And then it compiles to multiple targets, which might be useful in a lot of areas (gamedev is one of them, so Haxe is used more there). It also has a very powerful and fairly straightforward and maintainable code generation features, which is a bit advanced but REALLY useful. And it’s a proper compiler with optimization passes, e.g. inlining or dead code elimination. So the tech is really promising indeed. On the negative side it currently lacks in tooling and amount of quality libs, like many non-mainstream languages, I hope that will improve.

2 Likes
9

Forgive my ignorance, but I always thought of “high performance” and "high level language** as being mutually exclusive. The whole reason that low level languages persist is because they generate code that is so much more efficient in memory and CPU usage. You will never get a high level language that will do that as well as a low level language. You trade speed and memory for ease of programming. The fact that low level languages are not as dominant has more to do with the explosion of processing power and cheap memory than the improvement of high level languages. If we were still running things on a Commodore 64, then no high level language would ever come close to beating a low level one. It’s just that computers are so fast and memory is so plentiful that it just doesn’t matter for 99% of applications. And when something really fast and efficient is needed, just that code can be written in C.

And to boot, it’s cross platform? How does it optimize for every platform? It reminds me of the barbershop sign I saw that said, “We specialize in all styles!”. Uhhh, I don’t think they know what “specialize” means. If you specialize/optimize in/for one thing, then by definition, you are sacrificing for the others.

I don’t know, Haxe may be great. I haven’t tried it. But if something is high level and cross-platform, then I have to think that a sacrifice in speed and memory is being made. Sometimes that sacrifice is worth it. But you can’t have the best of both worlds. Maybe Haxe is better at those things compared to other high level languages - I don’t know, I’d have to see some metrics. But there’s no way it’s going to beat something like C in terms of high performance.

2 Likes
10

I don’t actually know much about low level programming so I didn’t know that. I figured, because Haxe compiles to C++, it would get the same speed as C++, unless of course the compiler just generates inefficient C++ code. I also thought that as long as it has a good garbage collector, that it should be able to handle memory management for me without being worse than me doing it myself.

I have only ever used high level languages, so I am likely more ignorant than you are. I am not qualified to answer these kinds of questions about Haxe or about languages in general. The statement I made was made out of my assumption that compiling to C++ was sufficient to have good performance. I’ll probably open up a Topic on the Haxe forums to ask about this.

11

Well, I’m not an expert, but I wouldn’t consider C++ to be a low level language like C is. Depending on to whom you speak, it might be high level or middle level.

The fact that a languages compiles into a low level language does not mean that it is as effecient as that low level language. The lowest possible languages is machine code and all languages compile into that eventually. The point is that there will be inefficiencies introduced by the higher level aspects of the language that even the best compiler/transpiler won’t be able to root out.

Again, I’m not say that that’s good or bad. It’s a trade off. The higher level the language, the easier it is to build complex code, but you give up something in speed and memory efficiency. Maybe it doesn’t matter - maybe you have plenty of memory and the task is so quick that speed isn’t a factor. Or maybe you need to do an instantaneous fast Fourier transform on a huge wave form every time the user moves the mouse so that should be written in C or even assembly. It just depends on what you need.

12

I understand. It makes sense that the compiler can’t ever be just as good as writing the code yourself. You have made me curious, though, how big a difference does it make. I opened up a topic on the Haxe forums asking about the performance differences between C, C++, and Haxe.

13

Compiling to C++ doesn’t make it fast: you can write slow code in any language. And for web apps, a decade or so of engine optimization means JS code can be as fast/faster for specific things (web, not mobile, apps); applications don’t just get automatically faster because they’re using a low level language. C++ is low level, but in the sense that it needs to be compiled to native to actually get fast code: Haxe basically works as a macro system that targets various languages. Haxe targets those languages so that Haxe applications can be deployed (in theory) on any platform; it’s not really about speed, it’s about portability, one language to target multiple platforms (that being said it’s an alternative to wrapping JS apps in a web view for mobile apps which tends to produce very slow apps).

I don’t know Haxe, but I do know the language it’s written in (OCaml), and naturally it works the same way. You can get OCaml to compile to most things; it compiles to high-quality JS just fine, for example (via Bucklescript). But standard OCaml (like Haxe), compiles to bytecode or native. Bytecode is portable, when compiled you get the code + a garbage collector + the C interface functions to make it work. It’s also relatively slow. Native means it compiles to Assembly, that’s fast as there isn’t any intermediate VM/GC/etc. Compiling Haxe to bytecode means the the resultant code also has to include an interpreter which will make it slow; compiling Haxe to native should produce assembly afaics; compiling Haxe to {insert target} just compiles it to that target, whether that resultant code is fast or not will depend on how well the cross compiler is written.

1 Like
14

@DanCouper I would like add some comments to your view on how Haxe works. Though the haxe compiler is written in OCaml it doesn’t mean that you get OCaml code compiled to either native or bytecoode when working with Haxe.

In regards to the C++ target the Haxe compiler transpiles your haxe code to C++ code, and that code is then processed by your C++ compiler afterwards. The C# and Java targets work in similar ways I believe - ie. the Haxe compiler outputs source code that is then used as input for the relevant compilers.

So the OCaml is something that the Haxe compiler developers is concerned with - not the developers that is coding in Haxe. So the performace of OCaml should not influence the performance of your Haxe written application, but on only the perfomance of the Haxe Compiler itself - which by the way is lightning fast.

The performance of your Haxe -> C++ app depends on how good Haxe is to generate optimized C++ code, but regarding that, I’m sure some of the experienced Haxe -> C++ users can chip in with more qualified comments than I can.

Hope it clarifies it a little.

15

Ah no, you misunderstand: of course you don’t get OCaml code, that’s not what I said, it just happens to work in exactly the same way as say a PPX transform because it is the same. OCaml is useful for writing compilers/parsers etc, and Haxe being written in OCaml and being able to do what it does is not an accident, but Haxe itself isn’t OCaml, and then the compiler (well, the whole language) is just a toolkit, which happens to be implemented in OCaml, that compiles Haxe to whatever language. The compiler does compile to bytecode for specific platforms (flash for example), I thought it compiled to assembly as well in some circumstances but it does not

16

Yeah, I just reread your post I can see what you meant originally :smile:

17

The Javascript output is well optimised by the compiler.

decoding_time.png703×443 14.3 KB

More info on this bench here : http://www.infognition.com/blog/2014/comparing_flash_haxe_dart_asmjs_and_cpp.html

18

I got some helpful responses from people who use Haxe on my Haxe performance forum topic. It looks like you can often get away without having to write C/C++. You can if you have to, but lots of the time you can just write more efficient Haxe code, especially if you profile your code to figure out where it is slow.

19

Yes, there are times when speed is unimportant. And as computers get faster, it becomes less important. But there will always be specific tasks that will require maximized speed or data efficiency. For those tasks, low level languages will always rule - you can’t have your cake and eat it too - you can’t have maximum efficiency and maximum ease of use and generalization.

Again, no one is saying there is anything wrong with Haxe, just that it is not a magical catholicon that is the best tool in all situations. Yes, I’m sure there are fanatical supporters - there are for every language.

2 Likes
20

This is a beautiful word