I think Armory may be such a tool.
7 Likes
Does Tink have that allure?
2 Likes
I actually think Armory looks pretty amazing. It think it could become a very impressive game engine. It’s renderer is mind-blowing. I’m trying to learn it because me and my brothers have dreamed of making an Open Source game for years.
We might need an Armory game, though, to actually show off Armory. Me and my brothers are working as hard as we can to make a game that we will Open Source as soon as we can figure out how exactly we will license it ( which should be soon ). We don’t have much other than the story so far. It will probably be a long time before we actually have a good game.
Regarding Tink, I couldn’t agree more. The “problem” with it is that it can’t be easily sold in a single package, like, say, Ruby on Rails can. It’s an amazing collection of libraries. Maybe if we had a “Tink on Rails” (for web/mobile dev in general) it would be easier.
2 Likes
Could tink_web start to look like it ? Not sure how it relates/integrates with monsoon embedded webserver which is also very interesting.
2 Likes
I’ll just add some food for thought here.
When I started with Haxe back when MTASC was getting discontinued, it was out of a need for an open-source AS compiler. I personally liked the ActionScript syntax, so I was more than happy to get my hands on Haxe, which sported a similar syntax and its very own cross-target API.
However, what really got me into Haxe was its initial Web-oriented heading (it was, after all, described as the language for the Web at some time). The PHP and Javascript targets were a revelation for me at that time (around 2006) because it added value to these targets in the following way:
- Neither Javascript or PHP had dependency management
- PHP introduced namespaces, but not a standard class loader. In Haxe? All standard.
importyour classes and forget. - The remoting API, albeit not quite there in terms of maturity, offered a quite straightforward RPC workflow that worked across targets
- “Forced” single point of entry PHP applications. Building a PHP app in Haxe? Forget putting multiple entry points in multiple PHP files. You have one
index.php, deal with routing in a sensible way. Back in '06, that was not (at least not for PHP) the standard. - Both backend developers and frontend developers could learn the same language
Now, fast forward to 2018:
- Javascript has dependency management through NPM, PHP has dependency management through Composer
- PHP libraries have evolved to a point where classloading is less of an issue
- RPC is less popular than REST these days
- PHP applications evolved in a way that multi-point of entry messes are less of an issue
- Having a common language between frontend and backend is not that much of a problem if concerns are properly separated. With NodeJS in the mix anyway, if there’s a universal language, for better or worse, it’s Javascript.
I cannot speak for other use cases, but as far as Web development is concerned, the languages that Haxe targeted caught up in terms of sophistication and the value that Haxe added roughly 10 years ago is not as clear as it is today. There are a lot of tools and compilers in the wild that lets developers more efficiently write JS and PHP applications without resorting to learning a new language.
The other languages’ standard libraries and communities evolved to a point where I think it’s difficult to justify Haxe based on its cross-platform compiling prowess. It’s my personal opinion here, but I think that if Haxe is going to have high impact in the industry, it’s trough its standard lib and provided APIs. Not by the number of targets it proposes.
Two cents end here!
6 Likes
That brings up a good point. If Haxe is good, why is Haxe good? What actually makes Haxe a good language for anything? Why should I use Haxe?!
If we can’t come up with good answers to these questions, Haxe might not stand the test of time. I very recently found Haxe so I’m not 100% sure what the answers to these questions are, but if we can come up with good answers, these are the kinds of things that need to go on the Haxe website, the kinds of things we need to be telling people about Haxe. These are the things we need to focus on if we want to find a way to make Haxe more popular.
Honestly, I’m still trying to figure this out. Is Haxe really something that I should write programs in? I like the language’s features ( macros, type inference, etc. ); that is what drew me to Haxe, but in light of the fact that there are a lot of other good languages out there that are getting better ( Javascript for one ), does Haxe actually have the value to survive the future? If it does, we theoretically just need to get it noticed and developed and get a larger community around it, but if it doesn’t have value, we need to figure out how to give it value, or we need to find another project.
Maybe it isn’t true, but I feel like Haxe has some great potential. We need to find out what it is and prove it if we want to get other people involved. It seems like the difficulty in doing that is either one of two things and I can’t figure out which one it is:
- Either Haxe has so many different potential applications and uses that it is hard to nail down how to use it.
- Or Haxe really isn’t more useful than the languages that already do the jobs that you could do with Haxe.
Some thoughts on what might make Haxe valuable and what it is competing with:
The reason that I initially liked Haxe was because I knew Python, wasn’t a fan of Java, and wanted to avoid writing C++. I wanted to be able to write code that was faster than interpreted Python. I looked at Cython, which is faster than Python, but there are problems with concurrency in Cython. I also took a quick look at Go before I found Haxe.
If your reason to use Haxe is for the C++ target and you want to build native binaries, without writing C++, I think that puts Haxe in competition with Go, Rust, Nim, and another one I just found, Crystal ( is there anything else? ). That leads to the question of why you would use Haxe over any of these other languages if your target is native binaries.
You can also use Haxe to write web applications, but why use Haxe over Typescript and Node?
Maybe it is an advantage that Haxe is one of the few, or maybe the only, language than can handle all of these different use-caes, but is that enough of a reason to use it over languages that target their individual use-case?
Haxe is kind of cool in that it can utilize the libraries of the platform that you are targeting. For example, Rancher consists of, in part, a Java web server, a Python agent, and a Javascript frontend. You could have alternatively written a program like this in 100% Haxe and utilized the Java, Python, and Javascript targets for each different use-case.
Without marketing it does not matter how good is Haxe as tool, if nobody know about it.
One of the ways to popularize Haxe among developers is a plain advertisement. There is a lot of popular youtube channels with developers who talk about languages trends and with a lot of “how to” programmers videos. This channels has thousends of views and a lot of subscribers. If blogger who has some influence in a masses will tell a few nice words about Haxe, then this will encrease it’s popularity.
I believe, but it’s only IMO, HF should try to do something like this. And maybe community can help and organize Patreon or something for donations for marketing stuff.
Marketing is definitely important, but I think it comes in pair with an end user product which may not be Haxe itself, as mentioned earlier in this topic.
Facebook is not marketing Javascript, instead it is marketing React as a full featured way of making web applications, and this happens to use Javascript. Same goes for Apple with Swift: it is, above all, the language that you will be introduced to when making iOS, macOS or watchOS apps but it would be worth nothing if it didn’t have a whole SDK with it and CocoaTouch, UIKit etc…
What makes it difficult with Haxe is that there are plenty of different way of using it and narrowing it down to a few polished workflows is hard.
We need excellent and unique tools that take advantage of the unique features of Haxe.
OpenFL is somehow such a tool because as far as I know, there is no other tool around that makes it possible to migrate from Flash as easily. I am sure OpenFL is the initial reason of many people giving a try to Haxe.
Armory is promising as well and I am looking forward to seeing what it will become in the future.
Heaps as an end user product looks great too and already made it to publish games in production which is a big plus, but it also has a website with written « soon » on it for more than a year and that could be seen as a red flag for a newcomer.
Haxe Foundation is working on improving Haxe itself and can probably not provide and maintain by itself full-featured products based on Haxe, but if there is any way it can support finished and well-polished software made with Haxe by other companies/people, it should because these tools are what would make Haxe shine (in pair with good marketing).
2 Likes
I think an underrated feature of Haxe is its ability to layer new, more reliable code into existing legacy codebases. I’ve done this myself with a pretty big legacy PHP/JavaScript app, where I got some great benefits from the type system in the Haxe portion of the app but was able to seamlessly leverage an existing PHP framework on the backend (and code sharing with JS was a nice perk.) I’m sure some of the large Haxe partners have similar experiences. To me, the benefits that TypeScript is already known to bring to JS, Haxe can provide for many languages that can be difficult to maintain at scale (Python, PHP, JS, Lua) with portability as a bonus.
I agree with @jeremyfa that direct marketing can be useful but isn’t a solution by itself. In my experience many have already heard of Haxe organically (maybe on Hacker News, Reddit, Twitter), maybe even looked at it, but it didn’t hook them yet. They might’ve had misconceptions about what it can do or what it was for (game dev, Flash.) We should understand where we’re losing potential users and what story will bring them in to investigate more, vs. just pouring in more impressions with paid ads. Then we need to make sure that the tooling and ecosystem is competitive so that they stick around.
Anyway, I think the issues are broadly agreed upon. Haxe Foundation is actively hiring an evangelist, and I’m sure they will consider this giant wall of feedback and existential drama
3 Likes
I also agree with @jeremyfa about importance to marketing one strong point of Haxe.
For me, this will be a direct comparison between Haxe and Xamarin and marketing haxe as cross platform mobile app development tool. If we go further, I will suggest creating ‘Haxe ads’ similar to Unity ads .
Let me explain. Every mobile developer looking to monetize the game / the app and one of the things to do that is with the integration of ads in the game. So if Haxe have separate sdk, and platform/site where publisher and developers can use is a big ‘yes’ for all. For Haxe , team can get from publisher 10-20% , for developers is easy development with Haxe ( for iOs, Android, html5) and easy integration of ads ( so can make money) and why not easy integration with extensions ( mobile payment, push notification ) and so on.
Think about that . Haxe still be open source free project , but will became platform for adversiters and will help in developers in the same time. Win-win situation.
1 Like
The only point we agree is that the Flash target doesn’t require much updates
Hey this caught my eye and makes me worry a little. We are using Haxe with OpenFL to port our games and plan to use HTML5 for web but Flash target to bundle everything with Air to mobile and desktop. This is a great opportunity when working with Haxe imho and it leverages cross platform quite nicely without worrying about the specifics of any native target and the differences in the render pipeline. We serve 500.000 monthly active users and the games are live now with the haxe codebase on Android, iOS and desktop while we work on the HTML5 output.
I understand that the Flash code is working well and does not require a lot of work at the moment. I only hope that means you don’t need to put much effort in keeping it fit for production, and that it does not mean you plan to give up on it completely.
Haxe is right now in this neat little spot where we can code for HTML5 and mobile (through Air) without a lot of effort. Should Air ever cease to exist we might need to invest more for native targets, but we would like to stick to Air as long as possible, and I guess we are not the only company with this strategy coming from an AS3 cross platform background.
Just my 2 cents, thanks.
There is no reason that Haxe would not continue to work with Flash/Air, given that Air is not getting updated much either and that there won’t be any significant change to Actionscript 3 as well.
Haxe is Open Source and can be fixed by anybody to keep it working with Flash if needed (but I suspect HaxeFoundation would take care of it anyway). I would worry more about Air being discontinued in the future than Haxe not supporting Flash, as Air is a closed-source black box that doesn’t seem to evolve much anymore. @rewb0rn if you are already using OpenFL, there is only one step ahead to target native iOS/Android using OpenFL without depending on Air/Flash at all.
3 Likes
I’m just arriving (to Haxe) and my search is for a C++ replacement for developing audio software.
I need both the lack of garbage collection (Go, Crystal, Java, and just about everyone else can leave the room now…) for deterministic timing, and seek a high-level approach as the nitty-gritty audio processing is in it’s own real-time thread as the callback registered with the systems audio driver, and I’ve meanwhile to make a LOT of features and not pull my hair out with the massive scope of projects.
Can Haxe be a higher-level less-painful alternative to C++? That’s a very elite market that not many other languages can fill, certainly not most of the trendy webby ones…
Low-latency audio has other uses beside audio content production and musical performance…
@vectorselector / @ibilon true, but I believe you can disable it in hxcpp (cpp.vm.Gc - Haxe 4.2.1 API) and HL (hl.Gc - Haxe 4.2.1 API). At your own risk, of course. 
And, hooray for open source, you can peek at the VM code and/or adjust it to your liking.
@jcward you can disable it, but AFAIK you can’t destroy Haxe objects by hands, because Haxe classes generated without destructors.
@vectorselector You might want to look into Nim lang. From their website:
Many garbage collector options.
Choose from a deferred RC’ing garbage collector that is fast, incremental and pauseless; or a soft real-time garbage collector that is deterministic allowing you to specify its max pause time; and many others.