For using the 32-bit version (from Limits):
22 Limits
Each database runs in memory and/or disk map-on-demand -- possibly partitioned. There is no limit on the size of a partitioned database but on 32-bit systems the main memory OLTP portion of a database is limited to about 1GB of raw data, i.e. 1/4 of the address space. The raw data of a main memory 64bit process should be limited to about 1/2 of available RAM.
The & "where" operator in raw k has stayed with me over the years as a particularly inspired way to deal with column based data.
I would say the language is very interesting. It is probably not interesting enough to get sued for, though ....
I suspect times have changed - there are implementations that have been out there for years (https://github.com/kevinlawler/kona implements k3 with sprinkles of k4, and http://althenia.net/kuc implements an almost-k4 with a JIT and writable closures).
IIRC, when you did your implementation it was when k4 was still a "technology preview" and not their main product (or was just released) - I remember understanding the panic in those action, even though I totally disagree with them. (I didn't know about the threats, but I do remember seeing it appear and disappear within a day, and assumed something was happening behind the scenes)
typedef struct k0{signed char m,a,t;C u;I r;union{G g;H h;I i;J j;E e;F f;S s;struct k0k;struct{J n;G G0[1];};};}K;
Sorry I guess I'm just not seeing the "not much there and actually easy to understand"
Whatever a 'H' is
// remove more clutter
#define O printf
#define R return
#define Z static
...
The q language is very powerful, and expressive - interesting mix of lisp and APL. You can do really powerful analytics without writing tons of code for it.
You really have to see how fast KDB is compared to most nosql products out there.
I barely did any q / kdb; only made a functional and usable UI, and did some prototyping of new ideas in other languages (Java, Max/MSP, Csound). I spent some time looking into q and was thoroughly baffled. Still am. It was really, really fast, though!
As I vaguely understand and can explain it, the k/q system made it easy to do fuzzy searches and deal with missing pieces of data. If the user missed a note, or our pitch detection failed, or our source data was bad, we were still able to find matches. (Yes, I wish I'd been able to understand this more at the time. Bygones, now...)
Sure, you can do the same in R or python, but the whole process is very quick and easy in q.