Not a comment about try.haxe, but Haxe in general:
There's this Window Manager called Awesome, which is scripted with Lua/LuaJIT. It features an extensive library of objects for use in user scripts.
There's a lot to like about Lua, but it's designed as an embedded scripting language and it gets harder to use the more code you have. Extremely dynamic nature coupled with lack of good tooling makes it really hard to explore the codebases above a certain level of complexity.
Enter Haxe, which has Lua as one of its targets. It gives you static typing (with local type inference), good LSP support for navigating the codebase, some nice libraries and utilities (Tinkerbell) that Lua lacks, macros, exceptions, modules, basically everything you'd need to work with a large codebase. Everything Lua does is still accessible, so for example coroutines and tail call elimination are still working, but you get a lot of tools on top of that.
I think LuaJIT + Haxe is a very powerful combination, which gives you great performance, rapid prototyping, and tools for programming in the large at the same time. The experience of writing a few kloc of Lua scripts for Awesome was not the most pleasant, but when I added Haxe to the mix, it became a real pleasure to work with. It's worth considering if you find yourself in a similar situation (a lot of things are scripted with Lua, after all.)
I have evaluated several "typed Lua" solutions[1]. Haxe might be a bit too heavy-weight depending on what you try to do. There're Teal and TypeScriptToLua which might be a better fit.
I recently did a fairly large undertaking with TypescriptToLua.
(Porting the Lua API + types of a major music DAW to TS types to make it possible to write type-checked scripts in JS/TS).
The experience was mostly smooth, barring a few bumps of non-standard TS stuff. (It's also very actively developed)
BUT, the community is amazing. They have a Discord server where the core devs are active and very helpful, they quickly and politely helped me fix the small issues I ran into.
I never knew Haxe was capable of this, so I can't give a fair assessment, but now I am interested in trying it as well!
At the time I started working on my scripts - sometime in 2019 - I think neither Teal, nor TSToLua existed. Not 100% sure about that, but I remember searching for type systems for Lua and coming back empty handed back then :(
I'll take a closer look at both, they seem interesting.
Wow, I feel like somehow the universe directed me to this comment. I've been using Awesome for almost a year now, but with mostly default settings because writing Lua is such a chore. I'm gonna look into this right now, and appreciate any more information you're willing to share about your setup.
My config is on Github[0] and it's an absolute mess: at first I used plain Lua, then tried MoonScript (which was a huge let down, unfortunately), then switched to Haxe. In all 3 cases this config was my first time using the languages in question, so the code is... less than ideal, let's leave it at that :)
If you want to set up something similar, you can start with haxeshigh/Makefile[1] and haxeshigh/bin/build (it's a shell script). In the haxeshigh/src/ there are implementations of three widgets: battery, brightness, and taglist[2]. The last one is the most complex as it uses coroutines to animate (slide in/out) the widget on screen. The rest of src/ are wrappers/type definitions for objects from Awesome, plus some macros/helpers for working with Lua tables (which are both arrays and hash tables at the same time, Haxe doesn't like this).
I found some bugs in the Lua part of the Haxe compiler (genlua.ml), but it was a long time ago, so they are probably fixed already. I don't remember the details, but the fix was trivial... I'll try to look for the issue and see if it's already fixed later.
I ported my https://rpgplayground.com from ActionScript3 to Haxe several years ago. (It's an RPG Maker for the web).
Very happy with it! The main benefit for me is that once I want to go to other platforms, even game consoles, I can do that without much hassle.
I used to be an avid Python developer, and thought that language was really undervalued. Now I have the same feeling about Haxe.
When people ask me what language I use for RPG Playground, and I say Haxe, they have no idea what I'm talking about. I always mention that Dead Cells is also built in Haxe, and the it's "ah I know that one".
i think typescript has stolen the thunder for web development, but in an alternative universe where typescript didn't exist, i say haxe would be the better altnernative over javascript for web frontend, and possibly, backend as well.
If you’re curious about successful projects built with Haxe, Google “Friday Night Funkin”! It’s a delightful Flash game revival that combines elements of DDR and PaRappa the Rapper.
It's interesting how DC goes from average performance on Switch to smooth 60 fps. I always wondered if it was related to Haxe and if it had home made Haxe optimization (Haxe dev is one of the original DC devs).
Switch is a constrained console and Haxe is dynamically typed. DC is a real world product with a long life (many updates and DLC). Any information about limitation/workaround it had to do would be very interesting to hear.
Haxe is not dynamically typed, it can compile to dynamically typed platforms, but it can also compile to statically typed platforms while remaining statically typed.
For switch it uses Hashlink/C code generation so it's native C that is compiled on the console.
haxe is one of those languages that I envision myself to be really productive in but never have the chance to make it happen and end up choosing typescript
The multiple targets is certainly a big appeal, but the biggest for me is it's just a nice language to work in, so I often prefer it over whatever domain's native language I'm working with
Same story for say, writing blender plugins; personally I find prefer if I can use a strictly type functional language and then compile to python, rather than write in python
You seem to caution against using vue and react when targeting the web. Is the haxe-react project you linked to in that post what you normally use for building front-end apps, or how are you approaching that if not?
Yeah, kLabz's haxe-react is the one I've used in the past because kLabz seems to be active keeping it updated and I've been very happy with it (although I think the readme doesn't do it justice)
My work at the moment is WebGL-heavy and DOM-light, so I haven't needed DOM frameworks much, however the next time I do I'm curious to try haxe 'coconut'[0] which is a react-like ui library written for haxe
I think when building a web app that involves assembling components from libraries and frameworks, TypeScript is a strong choice because there's so much material out there to work with, all designed for TS. Whereas if you're building something for the web with few dependencies and primarily in-house code, haxe starts looking more attractive
I'd love to see haxe get to a point where it can frictionlessly integrate with TS codebases so it can become an attractive choice for any frontend work but it's not there yet. Lots happening in this direction however; maybe in a few versions time.
Kotlin/Native is a special snowflake that by being built on an incompatible memory model with the JVM, now has been forced back into the dev board as the amount of issues kept pilling up.
You cannot just pick a random Java library, even if pure logic code, one of the Kotlin FFI selling points and use it with Kotlin/Native, if it wasn't originally written with Kotlin/Native memory model in mind.
I work with Kotlin at my day job but am also active in the Haxe open source community. I really like both languages, and I don't think that Kotlin is objectively better than Haxe.
In practice, there are things about Haxe I miss in Kotlin, but also things about Kotlin I miss in Haxe. Just to name a few examples:
- I'm missing Haxe's pattern matching and macros in Kotlin
- I'm missing Kotlin's level of IDE support and robust null safety (with ?: and ?. operators) in Haxe
(Haxe does have experimental opt-in null safety, but it doesn't seem production-ready yet)
Yep, try-haxe itself is generated JS+PHP code from shared Haxe codebase.
There is also some bytecode targets: JVM, HashLink JIT (fast in compilation Clang target alternative), neko (older Haxe VM), swf.
It seems a bit disconcerting that the hello world JS example has code for an array iterator in the output, despite never using arrays. Any idea why that is?
There's this Window Manager called Awesome, which is scripted with Lua/LuaJIT. It features an extensive library of objects for use in user scripts.
There's a lot to like about Lua, but it's designed as an embedded scripting language and it gets harder to use the more code you have. Extremely dynamic nature coupled with lack of good tooling makes it really hard to explore the codebases above a certain level of complexity.
Enter Haxe, which has Lua as one of its targets. It gives you static typing (with local type inference), good LSP support for navigating the codebase, some nice libraries and utilities (Tinkerbell) that Lua lacks, macros, exceptions, modules, basically everything you'd need to work with a large codebase. Everything Lua does is still accessible, so for example coroutines and tail call elimination are still working, but you get a lot of tools on top of that.
I think LuaJIT + Haxe is a very powerful combination, which gives you great performance, rapid prototyping, and tools for programming in the large at the same time. The experience of writing a few kloc of Lua scripts for Awesome was not the most pleasant, but when I added Haxe to the mix, it became a real pleasure to work with. It's worth considering if you find yourself in a similar situation (a lot of things are scripted with Lua, after all.)