Arthur Whitney releases an open-source subset of K with MIT license

Original Article ↗ Hacker News Discussion ↗

Arthur Whitney has released an MIT-licensed, highly compact subset of his K array programming language, best known as the foundation for the kdb+ database used in quantitative finance. Commenters are split between admiration for the extreme terseness, performance focus, and tiny binaries, and frustration at the cryptic C style, lack of documentation, and limited, buggy functionality in this early subset. The release is seen both as a rare opportunity to study Whitney’s influential style and as a reminder that K’s real-world value lies in proprietary, production-grade implementations still used by banks and hedge funds.

Scope of the Release

  • This is an MIT-licensed, open-source subset of K, not the full commercial language or database.
  • Functionality is currently very limited: described as “a desktop calculator,” missing functions, conditionals, loops, paired syntax, stranding, and tacit functions.
  • Many primitives are unimplemented or buggy; users report easy segfaults and nonsensical results for basic operations.
  • Several commenters suggest it’s better seen as an educational or stylistic artifact than a practical K implementation; other open-source K variants are recommended for actual use.

Code Style and Readability

  • The C source is extremely dense: single-letter variables, many expressions per line, heavy macro use, almost no comments.
  • Some see it as effectively obfuscated or elitist, arguing it’s hostile to maintenance, teams, and long-term evolution.
  • Others frame it as a deliberate “array-language style” of C that becomes readable once you learn the idioms, similar to regexes, APL, J, or dense NumPy/Pandas one-liners.
  • Debugging is said to rely on interactivity and short code: you inspect small fragments in a REPL or rewrite from scratch instead of using a traditional debugger.

Array Languages: Pros, Cons, and Use Cases

  • Supporters argue array languages provide:
    • Extremely high expressiveness for numerical and data-manipulation tasks.
    • Fast development cycles for experts, especially for custom modeling and exploratory work.
    • A mental “shift” that can significantly change how you approach data problems.
  • Critics counter that:
    • Terseness often reduces clarity; more verbose Python/R/Matlab code can be faster to develop and maintain in practice.
    • Ecosystem, libraries, and tooling in mainstream languages often outweigh any syntactic advantage.
    • Some view the style as “write-only” and risky for production systems.

Performance Claims and Pricing

  • The author claims huge performance gaps over mainstream databases and tools; commenters are divided.
  • Some say such speedups are plausible for narrow, well-chosen analytical tasks on columnar, in-memory data.
  • Others are skeptical, noting:
    • Anti-benchmark clauses in commercial licenses.
    • Lack of independent, reproducible benchmarks.
    • Modern columnar/OLAP systems and GPU-backed Python stacks can be very competitive.

Practicalities and Ecosystem

  • Compilation currently requires specific hardware (x86-64 with AVX2 or ARM64) and a narrow toolchain (clang-13); gcc and newer clang versions need workarounds.
  • Documentation and website are widely described as cryptic and unwelcoming.
  • There is interest in packaging and experimenting, but consensus that this release is best treated as a curiosity or learning resource rather than a production-ready tool.