New set of libraries: "Core Haxe"

Howdy Haxers!

Happy xmas and impending 2023!

So, I’m in the process of writing (and releasing) a set of libraries: “core haxe”. The idea here is to add some common, but fairly complex tools / frameworks to haxe. These are things I seem to write over and over again, and have varying versions of them embedded in different projects. So I thought it was about time to extract them, clean them up, make them “proper” and release them. You can see the GH org here: Core Haxe · GitHub

All of them are considered “WIP” currently and may change on a whim. Currently there are only a very small subset of the libraries I have locally, and will need more time to get the missing ones “up to scratch”, so watch this space! However, I didn’t want to sit on the libs that are ready as a) they might be useful to the community at large and b) having more eyes on them will only improve them (I hope!).

So far this is where they are at:

  • promises - this is basically just a typedef for themshim, however thenshim is included in the lib as I made local changes to it, Ill get round to opening a PR on the original repo

  • logging - this is a log manager that can have various “adaptors” attached… pretty simple, but used all over the other libs (so pretty core)

  • http - its no secret that the haxe std http has some… … … issues. Well, this is a http client that aims to work around those issues. At the very least, since its a lib, it can be updated independently of haxe releases. Note that currently, under the hood it does actually use std http (although shadowed and modified to fix the inconsistencies). However, one of the features of this lib is that you can “swap out” the http provider and use other, more native, ones perhaps. I’m sure as time goes on better http providers will be developed (like async http for hxcpp - which I’m also working on). This lib also comes with a bunch of other goodies like: following redirects, automatic retries, request/response “middleware” to name a few.

  • rest - this is a rest client built off the http lib. It allows creation of fully typed rest api definitions with a tiny amount of effort. This, and the “database” stuff, was the main driving force for this set of libs since I seem to develop very similar code over and over again in this domain.

  • queues-core - this is a major work in progress, and my local version is already vastly different to the GH version, its only been included really since the http lib relies on it.

The main ethos behind these set of libs (all of them) is to bring certain “core” functionality, consistently, to developers across haxe targets as well as a (hopefully) useful “toolbox” to help scaffold fairly complex applications.

That’s it for now, I’ll be releasing the other libs as I get time to polish them a little more (for example, all the “database” ones are “done”, but I need to write some tests and do some clean up)

Let me know if you have any issues, and, for sure PRs are MORE than welcome. Ideally, I’d like this to be a sort of community effort to fill in some of the inconsistencies in haxe and eliminating the “oh, no response headers for target X” type stuff.

Thanks and enjoy!



There’s some existing “core” stuff that around the tink-* libraries (Tag: tink), which would be good if there’s a way to unify these lower level libraries into a single library that is always available.

Think the java standard library (which i would consider to be the benchmark).

1 Like

Oh man I’d love to see a community supported set of aux-libs for haxe like this, good work pushing this out. Promises, logging, database and networking (http/sockets) are really good foundations (though I’d love Promises/coro/async to make its way into the haxe core). @Chii is so right that unifying these into a stdlib would be awesome.

Related priors:

1 Like

One thing I should mention, especially in relation to thx, is that “core haxe” aims to be quite a bit further up the stack, ie, http / rest sort of stuff and not so much about “lists, arrays”… Even when i mention queues, im not talking about queues as in datastructures, im talking about messaging middleware queues like activemq, rabbitmq, etc. Maybe “core haxe” isnt the best name? Not sure… Im certainly happy to consider alternatives (originally it was going to be called “enterprise haxe” but that sounded a little too “corporate” and a little presumptuous also)


I think that terms like Core, Base and Common all have a lower level stdlib ring to them when they’re by themselves. I think adding the term Application or App might improve the reception that it’s for higher level libs.

Maybe play around with the below combinations:

  1. (Core|Base|Common) Application (Libraries|Utilities|Toolkit|Helpers)
    • namespace example: core.application.libraries
  2. Hx(Core|Base|Common) Application (Libraries|Utilities|Toolkit|Helpers)
    • namespace example: hxcore.application.libraries
  3. (Core|Base|Standard|Common) Haxe Application (Libraries|Utilities|Toolkit|Helpers)
    • namespace example: core.haxe.application.libraries
  4. Community (Core|Base|Common) Application (Libraries|Utilities|Toolkit|Helpers)
    • namespace example: community.core.application.libraries

Long namespaces aren’t a problem with modern day autocomplete, just my 2 cents. :wink:

1 Like

Thanks David,

Funnily enough, we’ve all had a lengthy discussion about this on the haxe discord, and have pretty much come up with exactly what you just pointed out (yours with much more brevity :smiley: )

I think it will end up being “Haxe Application Toolkit”… its not supposed to be some intertwined set of libs, i wouldnt even put them in the same “hat” namespace, the GH org is literally a place to put the libs that are semi related to the overarching goal of writing “fairly complex” applications. (obviously some are deps)

Thanks for your 2 cents :slight_smile:



its not supposed to be some intertwined set of libs

I think it will end up being “Haxe Application Toolkit"

If that’s the case my last bit of bike shedding is this: I think toolkit makes it sound intertwined. Maybe a variant of Haxe Application (Utilities|Utils|Packages) would be more appropriate. Alrighty, I’ll leave you be on this now.

Happy New Year~ish from across the pond. :smiley:

1 Like

Thanks Ian for sharing these libs and the naming thought process :slight_smile:

Regarding the naming, maybe there are 2 different aspects :

  1. namespace/package : IMHO, if these libs are not as intertwined as the tink ecosystem, a common namespace is maybe not needed. For example yar3333 has a nice set of libs than could fit into the “CoreApp/Component”… maybe your libs are… “haxe libs” ?
  2. organization : why not host them under your personal account ? If the goal is to be less personal, welcome contributors/community, maybe other libs, the reflection could be widened.

As @Chii and @papercowboy mention, a set of community curated / maintained base libs could be very beneficial : it might help unification, discoverability, prevent reinventing the wheel and having X libaries doing the same job…

  • could be the place for this but AFAIK has limited individual account management and no “organisation” management
  • A list similar to Nadako’s awesome haxe list could be a place to curate a list of useful libs.
  • The tink* libs have successfully attracted a community of users/contributors but feel more like a full-stack framework/ecosystem, opinionated and sometime bleeding edge, which IMO justify the tink.* namespace

As some developers move to other activities, languages, or have less available time, individually maintained libs get less pull requests accepted, throw depreciation warnings, or do not compile with latest Haxe. thx.* for example has a lot of useful core libs which are “complete”, but still need small updates to follow Haxe’s evolution, the same is true for more isolated libs.

Maybe similarly to “HaxeFoundation” hosting officially supported projects/libs, an “Haxe(Community|Commons)” organization managed by a team of core haxe devs could be an umbrella over these projects, help having common testing, documentation, publication to haxelib pipeline, mirror / take over less maintained community libs which require minor fixes, host the Haxe Roundups (?), be a space to help the community collaborate while taking some load off HaxeFoundation…

Haxy new year to all ! <3

1 Like

So, they arent as intertwined as tink, thx, etc. But they are somewhat intertwined, and they all share a similar problem domain. Plus, my personal GH account is just messy, so wouldnt want them there

At this point im literally looking for a “good” catch all name… i think “Haxe Application X” (X being one of the examples above: toolkit, stack, etc, etc). In reality it doesnt make that much difference “bunch of libs for making applications” would be fine :slight_smile:

These are libs im currently using in production applications, so in reality, at this point, am looking for a place to “dump” them online and open them up to the community as a whole.

As for namespaces: yeah, i tend to agree, i dont want there to be a some over arching namespace since they dont actually have to be used together, eg:

You can just use libsqlite3.* for hxcpp access to libsqlite3… or you can go one step above and use sqlite3.* to use sqlite3 on “all” targets (sys, nodejs, hxcpp currently). Or you can go one step above that and use db.core.* which is an abstraction and plug in libsqlite (and later swap it out with mysql if you want). So, as you can see, they are related (if you want them to be), but you can also go to the “bottom of the stack” and just pick bits out you want. Thats the idea anyway, so i think not have some “hat.db.libsqlite3” namespace is important (at least for me anyway)

Anyways, thanks loads for the input gents - naming things is such boring thing! :smiley:

Cheers and happy 2023,

Whenever I’ve named something core, I’ve later come to regret it. :laughing: It’s no more descriptive than “anything I deem important” – acutely subject to opinion and bloat.

Not that I disagree with the premise. :slight_smile:


Howdy again!

So, some more updates to this, not the name change, its fairly inconsequential at this point, so maybe ill change it at some point, maybe not. We’ll see, but its more important to get the actual libs up and running first. Apart from bug fixes, i put on a new set of repos:

(full list here: core-haxe)

  • json-rpc - basic typed json-rpc client (based on the rest client)

  • db-core - database abstraction mean you can use different “plugins” to actually supply the implementation (currently only sqlite and mysql, but i plan on adding others as i get time / need them - eg: Postgres, IndexedDB and cassandra i can see me wanting in the near future). The point here is that you can use the same interface to add, remove, query, etc datasets from a variety of datasource (database types essentially)

  • db-mysql - mysql for db-core

  • mysql - this is a set of classes that will allow for the same interface to be used for mysql dbs, this can be used without any of the db-*. The reason this is important is because the node mysql libs have a totally different interface from the sys ones, so its important (imo) to be able to unify that so you can just use “mysql” across haxe targets

  • db-sqlite - sqlite for db-core

  • sqlite3 - same idea as mysql (ie, being able to use sqlite across haxe targets with the same interface). You also dont need to use db-* to use this.

  • libsqlite3 - these are hxcpp externs for libsqlite3 which should perform better than haxe’s inbuilt libsqlite (plus you can use prepared statements etc)

  • queues-core - this is a queue abstraction allowing you to create different message queues (currently only rabbitmq and some internal impls)

  • queues-rabbitmq - the rabbbitmq plugin for queues-core

  • rabbitmq - this is the externs and whatnot for rabbitmq - currently this is just for nodejs, but the idea is similar to the “sqlite” and “mysql” libs - that you can use the same interface for interacting with rabbitmq regardless of haxe target. Like “sqlite” and “mysql” you dont need queues-* to use this.

I think thats about it! Most (all?) of these repos have readmes now (albeit pretty simple ones), and most dont have tests - im actually unsure of a good testing strategy here - especially for the ones that rely on external servers (like mysql and rabbitmq).



Then maybe “Haxe Application Toolbox”? To me, a toolkit implies that its constituents have a common purpose (like a locksmith toolkit, or a flat repair toolkit), possibly a folding thing where each tool fits into its own form-fitted spot; whereas a toolbox is just a box full of misc tools.

Oooh, that’s another cool name: “aux-haxe”. :slight_smile:


Hey, nice! For json-rpc, there’s also GitHub - vshaxe/vscode-json-rpc: JSON-RPC implementation which we’re using for vshaxe and haxe language server.

1 Like

Yeah, i saw this a while back - I defo think ill end up leaning more towards that type of lib since mine is linked to the rest client and therefore http… which isnt always the case (ie, vscode iirc uses json rpc over pipes) - i just needed something “now” for something i was writing, but for sure the vscode version looks much fuller currently (and not “jsonrpc over http”).


1 Like