kona VS kdb

At first, I thought you were going to be talking about Kona which is another language. You may wish to consider a more unique name, though Kona isn't super well known.

For anyone interested in using a language like APL that doesn't require special symbols, I'd recommend K. You can try it out using Kona.

There are some open source implementations of J and K that you might enjoy.

> let's say I have a finance team that have never heard of it - why might they be interested?

In my experience it's very good at quickly developing real-time analytics applications with only a small set of developers. A couple of q developers can develop, maintain and operate the server side of 5 or 6 separate applications without breaking a sweat. Changes come in at a high speed too.

It's a highly interactive language. A bit like a lisp, you start up a q process, open a port and then you iterate and update your application live without needing to restart. Typically on our projects we've had a well iterated program running in QA for a day or 2 before opening a PR (which becomes more of a formality for getting the solution to the problem into prod at that stage).

The q language itself is quite wordy. Check the reference page: https://code.kx.com/q/ref/ Many programs written in q consist mainly of the key words with the special operators interspersed. Also see some example libraries: https://github.com/finos/kdb

It's been a fairly stable language to work with, having few breaking changes between successive versions. q code written 8/9/10 years ago on older versions will most likely still run the same today. We have source code on one project at work which hasn't had a code change in 6 years now (despite moving through different versions 2.8->3.0->3.3->3.5->4.0) and it runs daily without a hiccup.

Mostly it's a joy working with it because I feel like I get to tell the computer what I want it to do, without also having to tell it how to do it.