Have is a nice language, but it doesn't live up to it's promises.
It's really cool that it can compile itself to a bunch of different languages, but the API isn't consistent enough for complex applications to work with all of its backends.
Standard library is not that bad. It makes sense that there are inherently differences between, say, JS/Web runtime and native/C++ system platforms. Haxe does provide relevant cross platform API when available: file system access, threading etc...
it's good for apps that don't have _that_ much platform specific parts, but have lots of application logic. Such as games.
It's an OK language for backend server - esp. if you also have a frontend client in the same language (such as the game and the multiplayer server backend).
not natively, but because haxe compiles into C++, you can setup a wasm pipeline from that (presumably). Probably not something commonly done so there's no premade tooling for it.
It fits the niche of people who have legacy applications written in Flash, and want to rewrite them in a modern stack. There's a battle tested, free, cross-platform implementation of the Flash API called OpenFL. For people who were familiar with that stack, Haxe offers a natural path to migrate.
So, tl;dr its typical use cases are game development and making legacy Flash projects maintainable.
The C++, JS and Hashlink VM targets are generally well maintained. The situation with libraries is meh, mostly due to being a not-so-mainstream programming language that is almost 20 years old. So, there are a lot of libraries that weren't updated in a decade. Some of them may work on new Haxe versions, some won't. Some have been consistently maintained for very long, but are a one man show and the documentation is often subpar. Ceramic is one of such libraries, although the documentation for it is better than the usual for Haxe, IMO.
Overall I find the language itself amazing and pleasant to use. Kinda wish the C# target was still a thing with first-class support, so we could enjoy their hot reloading.
I have played with it a bit on side-projects. TL;DR: would not recommend it unless you're building a game or is in unique circumstances. Pick something with a faster feedback loop for development GUIs.
While HaxeUI is usable, you'll be on your own a lot:
* Documentation is scarce
* You'll likely run into bugs the moment you try to go beyond hello world examples
* No promises of regular releases or API stability whatsoever. You're expected to run versions directly from GitHub
* wxWidgets backend sometimes segfaults with the examples from its HaxeUI's website
* tooling is subpar for GUI apps in Haxe; forget having anything as good as any modern frontend framework with Vite. Hot-reload somewhat works on HashLink, but there's almost no documentation on how to use it.
It's maintained by a very nice dude, who does a good job considering the coverage of his libraries, the fact that he does that by himself, and the fact that the OpenFL-based backends work well. HaxeUI is used in production by a few people who work with the HaxeUI developer.
FeathersUI is another option, with much, much better documentation (probably one of the best for Haxe libraries), but smaller component coverage than HaxeUI. I ran into less bugs with it in general, and the dev seems more focused on consistent, well-tested releases. Also a really nice guy from my experience, just like the HaxeUI dev.
But overall, iteration times of GUI applications is just not good with Haxe. You'll suffer if you are used to modern frontend tooling. The accessibility story is nonexistent. And I'm not sure the performance would even be better than just opening a WebView. Definitely not on mobile.
I would only recommend using those two libraries in three circumstances:
* You are building a one-off GUI tool that has a simple interface. Think something like LunarIPS. In that case, you can get something usable pretty quickly which will look good if you don't care about following the native toolkit (don't go the hxWidgets path, it's guaranteed suffering).
* You are building some interface which will be used inside a game made with Haxe. Say, a login form inside your multiplayer game. In that case, it makes perfect sense to use one of those two libraries.
* Your application, for whatever reason (personal taste included), will have a more game-y UI, and it makes more sense to code it in a game engine than the DOM or Qt or whatever.
A fourth reason that is valid for anything is if you're in a Haxe shop, and want to maintain a single language for all projects. Those places do exist (like Shiro Games).
I think that if I __had__ to build a GUI program in Haxe these days, I'd build a prototype with vanilla JS or React first, iterate on it, and only start a HaxeUI/FeathersUI version later.
Yeah, the Common Clause license is pretty close to what I want, I'm just concerned with the SaaS offering in one of the examples in the license:
"Let’s apply the example to Commons Clause licensed software. Commons Clause-licensed Redis Graph is a graph database module for BSD-licensed Redis. Can you create applications with Redis Graph and distribute and/or sell them? Yes. Can you redistribute Redis Graph along with your application? Yes. Can you offer that application as SaaS and charge for it? Yes. Can you take Redis Graph itself, call it ElastiGraph and offer it as SaaS and charge for it. No."
It could be that the application developed with Redis Graph is totally different to Redis Graph so SaaS offering is allowed. I will check this further, thanks for your suggestion.
The Time's lawsuit does allege in part that 1. the training data was not licensed and therefore OpenAI has committed copyright violation, and 2. that the resultant model is a copy or derivative work of The Time's body of copyrighted articles.
That regurgitation is merely evidence of those two, and so putting a filter on the output explicitly does not resolve the case.
The question is whether legally you need a license to view copyright. Training doesn't copy anything, I think this is where people are confused. People assume this is how training works, because they have a false intuition about how LLMs must work.
LLM's are not data archives, I don't know how many times this has to be repeated.
> Defendants’ generative artificial intelligence (“GenAI”) tools rely on large-language models (“LLMs”) that were built by copying and using millions of The Times’s copyrighted news articles, in-depth investigations, opinion pieces, reviews, how-to guides, and more.
They need to be confused because they need the judge to be confused too.
NYT isn't suing because LLMs will print out NYT articles for free. They are suing because LLMs are poised to be better/more favorable news reporters than them. It's a long term survival case, not a copyright one (despite that being the weapon used in the fight)
I agree. That said, if AI puts journalism out of business, then AI will quickly run out of content to train on and report. I think this is a situation where technology has gotten way out ahead of the law.
So if they fix this problem, you’d then be OK with generative AI?
BTW, plenty of humans have memorized copyrighted material, such as song lyrics. Do you think that should be prohibited? Maybe the difference isn’t as great as you think.
This is it, isn’t it? Thats why all the effort pours in to make these machines produce rembrandt and tolstoy copies. And why I still have to do my taxes by hand rather than the machine handling it with speed and accuracy.
It’s the core of it all— jealousy of a creative spirit.
Artists are not machines, but living souls.
If you were remotely open enough to see for yourself, then you wouldn’t struggle with engaging in the world in a creative manner and you wouldn’t feel that jealousy but encouragement by what you see pouring out of your fellow humans as a reflection of each other.
No machine will grant you that understanding, you just have to engage directly.
It will never succeed to supplant it, no matter the billions of dollars burned to try.
AI doesn't make art, it makes images - it's like a camera this way. Art is in the composition, the message and the aesthetic of the one using the tool to create an image.
Using an AI tool to create an image of a painting betrays the person who seeks to be “artist” by short circuiting the practice that leads the prospect to their path of enlightenment through mastery.
In our constricted 3d world there is no circumstance where an algorithmically generated image of a painting will equally serve the prospective artist in its procedural work on the prospective artist, internally. There is no other pursuit in art, and any pursuant will come to that conclusion in any number of ways but always through submission to the course of mastery (for which there is no shortcut).
Worse, the companies at the helm of this side of the technology are pushing it in order to stand middle man to humankind’s modus operandi-to create.
Keep your mind open to perspectives beyond the software industry.
I do think a new way of thinking about copyright is needed for AI. Allow tech firms to train on all material, but there should be an AI tax that serves as compensation back to the public commons for what was taken from it and privatized.
The status quo favors large players who can navigate the legal system.
Training on copyright content as research is entirely fair use. Just require that fair use defense to hinge on that research being public, i.e. that it's only a defense of open weight models.
A tax on AI is stupid because the big players can dodge taxes well and have the ear of power now, so any regulation would favor them. It would only serve to prevent challengers to their dominance.
The controversy here is that LibGen doesn't legally distribute its content. Mass-scale training on pirated content is... legally murky, to say the least.
Methodology for comparison: train zstd dictionary on enwik9. Then build my dictionary as most common words in enwik9. Mine does 13% better because of the way I discovered how you can generate dictionary replacement symbols
It's really cool that it can compile itself to a bunch of different languages, but the API isn't consistent enough for complex applications to work with all of its backends.
reply