A new runtime for kdb+'s language ships closed-source, benchmark-free, and 'likely AI'
k and q are the terse array languages behind kdb+, the database Wall Street uses for tick data and Kx bills as the fastest and most expensive anywhere. 'l' claims to run existing k/q/qSQL unmodified, with SIMD and compression baked in.
The pitch is concrete: run existing k4/q/qSQL unmodified, crunch 86.5M rows on one CPU with 'no decode pass,' compression throughout. For shops reluctantly licensing kdb+ from Kx, an independent compatible runtime is the escape hatch they've long wanted.
The top reply ignored the speed. It flagged the copy, 'the vector as the unit of thought,' as pseudoscientific and 'extremely likely to be AI,' and pointed out l is closed-source with no benchmarks against Shakti or kdb+ itself.
What "l" claims: run kdb+'s language unmodified, minus the Kx bill

q and k are the famously terse array languages created by Arthur Whitney; q runs on top of kdb+, the column database by Kx Systems that Wall Street uses to crunch tick data and that Kx markets as the fastest in the world. It is also one of the most expensive pieces of software a trading desk licenses. "l," from a group called l-labs, is an independent runtime that claims to run existing k4/q/qSQL (tables, dicts, partitions and splays) without modification, with transparent SIMD, automatic parallelism and compression through the whole stack. Its headline number: 86.5M rows in an analytics query on a single CPU with "no decode pass." Its headline slogan: "In K/Q arrays are the unit of thought," extended to "compressed vectors as the unit of execution." What the landing page does not carry: a license, an open-source statement, or a single head-to-head benchmark.
"Vibe-coded" and "genuinely wanted" in the same thread
The first problem was just parsing the pitch. A reader who ended up asking an LLM what k and q even were said the landing page was "giving me mild schizophrenia" before Claude told him it was "the database Wall Street uses for tick data." A k user who at first mistook it for a rebrand of Shakti, Whitney's most recent array language, gave the clearest gloss anyone managed: it's "codegolf for experienced programmers who don't want to give up the keyboard," tools that "combine data access and the ability to compute against that data with as few abstractions as possible."
Then the skepticism. The most-upvoted reply flagged the submission outright:
"lots of unexplained grandiose thinking like 'k and q made the vector the unit of thought.' … 'unit vector of thought' is pseudoscientific language. Extremely likely to be AI."
The technical objection was narrower and harder to wave off: a new runtime for an existing language shipped without comparing itself to the language's other runtimes. A commenter who linked the k wiki's list of existing implementations made the point directly, and Peter Vessenes, an investor and Ethereum security researcher, pressed it in sharper terms: "how well a vibe coded k/q interpreter stands up to Shakti or whatever Mr. Whitney is letting out the door."
The defense, when it came, was concrete. A reply that surfaced l-labs' own benchmark repository drew the line that separates l from the beloved hobby interpreters: "unlike klong/ngn/bqn et al (which are GREAT) this has the goal of full production database compatibility (and full language compatibility)." That is the actual value on offer: a drop-in that could run production kdb+ workloads, not just a fast toy.
The closed-source part drew the most measured take. A commenter who pointed to ktye, a free k implementation called closed, vibe-coded software "a non-starter for many people including myself," then conceded the twist that complicates the whole pile-on: "proprietary license is actually common in the APL and K family of languages." The incumbents l wants to displace are closed and benchmark-shy too. Which sets the bar l actually has to clear, and it isn't a prettier landing page: a reproducible benchmark against kdb+ and Shakti, run in public. Until that exists, the array crowd's verdict stays where the thread left it, interested and waiting for proof.
Get breakdowns like this every day
The top Hacker News stories, unpacked — by email, Telegram, or RSS.
A Postgres pooler that fixes the leak where one client's session bleeds into another
Deploy PgBouncer in transaction mode and a SET you ran on one connection can quietly reappear inside someone else's query. PgDog's pitch: keep the pooler, stop surrendering the Postgres features it silently breaks.