Kotlin for data analysis

Original Article ↗ Hacker News Discussion ↗

Kotlin is emerging as an appealing alternative to Python for data engineering and analysis, thanks to its strong static typing, expressive collections API, and support for DSLs, generators, and Jupyter-style notebooks. Commenters note, however, that Python still dominates data science because of its mature ecosystem, tooling, and libraries, making Kotlin a more niche choice that currently demands extra effort and tolerance for JVM tooling. There is also debate over editor support, JVM “baggage,” and whether investment in Kotlin-based data tools can realistically challenge the Python-centric status quo.

Mobile usability of the docs / notebooks

  • Several people struggle to zoom on the Kotlin data-analysis pages on mobile, making notebook content hard to read.
  • Others report that enabling “always allow zoom” / accessibility zoom overrides in Safari and Firefox Android fixes this.
  • Some recall legacy HTML5 boilerplate patterns that disabled zoom and suspect such patterns are still in use.

Kotlin vs Python for data work

  • Strong sentiment that Python dominates data science, LLMs, and analytics because of its ecosystem and “path of least resistance,” not because the language is particularly good.
  • Some describe Python as dreary, slow, and with messy package management and bolted‑on typing; they still use it pragmatically for data work.
  • Others defend Python as clearly useful and mature; criticisms like “slow” or “bad packaging” are seen as underspecified and applicable to many languages.
  • A recurring theme: Kotlin is a joy to write and preferred for many tasks, but its data‑science ecosystem is niche, so most people still reach for Python or sometimes Julia.

Expressiveness: collections, comprehensions, and generators

  • Advocates argue Kotlin is more expressive due to: rich, consistent collections APIs; powerful lambdas; scope functions; and DSL-style APIs (e.g., charting).
  • Python supporters highlight list comprehensions, simple generators, and yield as elegant tools, especially for those used to math/SQL notation.
  • Others counter that comprehensions are special syntax compensating for weak lambdas, and that chained map/filter/sequence operations in Kotlin (or Rust-style iterators) scale better in complexity.
  • It is noted that Kotlin has generator-like sequence {} with yield(), matching Python’s capabilities in practice.

Typing, tooling, and ecosystem

  • Static typing in Kotlin is seen as a major advantage for large codebases; some feel Python’s gradual typing has made it less pleasant.
  • IntelliJ’s Kotlin support is praised as a key part of the value proposition; VS Code / Positron support is viewed as bare‑bones.
  • Kotlin notebooks in IntelliJ require the Ultimate edition, but the Kotlin Jupyter kernel can be installed separately via pip/conda.
  • Some see a need for “stubborn” adopters to grow the Kotlin data ecosystem, but acknowledge the current dominance of Python tools.

JVM and platform concerns

  • Several commenters like Kotlin as a language but dislike the JVM’s complexity and startup overhead, and note clients prefer simpler stacks (Python, Go).
  • Kotlin’s reliance on JVM/Android is seen as both strength (ecosystem) and burden; multiplatform/Native/WASM are mentioned but not yet seen as game‑changers.
  • There is interest in using Kotlin for Spark and in better desktop/data tooling, but support is currently limited or unclear.