Show HN: Han – A Korean programming language written in Rust

Original Article ↗ Hacker News Discussion ↗

A new programming language called Han uses Korean (Hangul) keywords and syntax, provoking debate over whether non-English-based languages can be practical beyond niche or educational use. Commenters explore Hangul’s design, typing efficiency, and how tokenizer bias in current LLMs ironically makes Korean code less token-efficient than English despite its visual compactness. Many see cultural and pedagogical value in letting native speakers read code as natural language, but note that tooling, libraries, documentation, and collaboration norms remain overwhelmingly English-centric.

Language design & goals

  • Han is a Korean-language programming language with a full Rust-based toolchain (lexer, parser, AST, interpreter, LLVM backend, REPL, LSP).
  • Current design is mostly “English-like syntax with Korean keywords”: SVO order, f(x) notation, method calls like 목록.추가(값) rather than fully Korean SOV grammar.
  • Keywords and methods use real Korean words (e.g., 함수, 만약, 추가, 삭제), not transliterations, to keep code readable to Korean speakers.
  • Error messages, REPL, and tooling are in Korean, which goes beyond simple macro-based keyword substitution.

Hangul, typing, and tokenization

  • Hangul is visually dense (syllable blocks), but experiments with GPT-4o showed Korean keywords use more tokens (2–3) than common English ones (often 1).
  • Reason given: BPE tokenizers are trained on English-heavy corpora, so English keywords are highly compressed; Hangul syllables are not.
  • Commenters note Korean’s keyboard layout (consonants on the left, vowels on the right) enables very fast, rhythmic typing; far more efficient than Japanese/Chinese input for code.
  • Some discuss Hangul’s design and ease of learning, though deeper historical/phonetic details are often forgotten even by natives.

Non-English languages, ecosystems, and tooling

  • Many ask why non-English programming languages aren’t more common. Suggested reasons:
    • Inertia and global collaboration: English keywords yield the broadest audience.
    • Ecosystem lock-in: libraries, docs, OS APIs, error messages, Stack Overflow, and research are overwhelmingly in English.
    • Input method friction for some scripts (e.g., Japanese) and ASCII expectations in tooling.
  • Several note that keywords are a tiny fraction of the difficulty of programming; the real barrier for non-English speakers is English-only documentation.
  • Others argue localized languages and tooling (including Excel-style translated functions and Scratch’s language-agnostic representation) help learners.

Korean-specific linguistic issues & proposals

  • Native speakers point out subtleties:
    • Verb stems usually require endings; naive translations of English imperative verbs can sound awkward.
    • Pluralization is weaker in Korean; explicit plurals often read unnaturally.
  • Some suggest future versions could more deeply exploit Korean grammar (true SOV structures) rather than merely translating English-like forms.
  • Hanja/Chinese-character keywords are floated as a compact notation, but younger Koreans rarely know them, and Hangul’s purpose was to avoid that burden.

Reactions, critiques, and related work

  • Many praise the project as inspiring, educational, and culturally interesting, especially for Korean learners and students.
  • Skeptical voices worry about fragmentation and reduced interoperability if such languages became widespread; others counter that experimentation and “art projects” are valuable on their own.
  • Related efforts mentioned include Korean languages like Nuri and Yaksok, Chinese and Arabic languages, cuneiform-based experiments, tokenizer adaptation for Ukrainian, and custom encodings (e.g., Serbian YUTF-8) to improve token efficiency.