Try the new try.haxe(community.haxe.org) |
Try the new try.haxe(community.haxe.org) |
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.)
(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!
-----
If you want to check out what I did:
https://forum.cockos.com/showthread.php?t=247666
https://github.com/GavinRay97/reaper-with-typescript-starter
I'll take a closer look at both, they seem interesting.
Thank you!!
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.
[0] https://github.com/piotrklibert/awesome-config
[1] https://github.com/piotrklibert/awesome-config/blob/master/h...
[2] https://github.com/piotrklibert/awesome-config/blob/master/h...
Non-mainstream languages are underappreciated, especially on the frontend where they all can tap into the ecosystem of JS packages.
Even if you're not ready to put it in production from day one, give it a shot! Going off the beaten path can be very interesting and enlightening.
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".
Expect big things for Haxe!
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.
It’s open source and has been blowing up lately.
It takes about a minute to load.
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.
Aside, DC is a very interesting game.
https://ninja-muffin24.itch.io/funkin
(Or so Google suggests)
EDIT: The game seems to be super-loud by default and apparently I can't play any music games other than Guitar Hero. YMMV.
For example, when I do web frontend work I often use it over TypeScript - I broke down why earlier https://news.ycombinator.com/item?id=26084187
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
Kotlin has JVM, Native and JS targets. And as a language it is much better than Haxe, I would be careful about such statements.
And it can also compile down to various bytecodes (like JVM), not just to other languages.
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.
For switch it uses Hashlink/C code generation so it's native C that is compiled on the console.
(I have no opinion on the argument, never having used either language. I just found the rhetoric funny.)
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.
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)
