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

Original Article ↗ Hacker News Discussion ↗

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.