Han – Rustで書かれた韓国語ベースのコンパイル型プログラミング言語

 (github.com/xodn348)
10 ポイント 投稿者 GN⁺ 2026-03-16 | 12件のコメント | WhatsAppで共有
  • 韓国語キーワードで記述する静的型付きのコンパイル型言語で、LLVM IRを通じてネイティブバイナリを生成する
  • Rustで実装されたコンパイラとインタプリタの両方を提供し、hgl CLIでビルド・実行・REPL・LSP機能をサポートする
  • 関数、もし、反復、変数 などすべてのキーワードが韓国語で、変数名や関数名も韓国語で定義できる
  • ファイル入出力、JSON、HTTP、正規表現、日付/時刻、システムコールなど実用的な機能を内蔵し、18個のサンプルを含む
  • ハングルの科学的構造と文化的な広がりをプログラミング言語として実装し、韓国語学習とコーディングを結びつけた新たな試みとして注目される

Han 言語の概要

  • Hanは韓国語キーワードで記述する静的型付きコンパイル言語で、LLVM IRを通じてネイティブバイナリを生成する
    • Rustで書かれたコンパイラツールチェーンとツリーウォーキング型インタプリタを含む
    • hgl コマンドでインタプリタ実行、ビルド、REPL、LSPサーバー起動が可能
  • すべてのキーワードがハングルで構成されており、例: 関数、もし、反復、変数、出力 など
  • ハングルの科学的な文字体系をプログラミング言語として実装し、言語的な美しさと技術的な精密さの融合を目指す

主な機能

  • 韓国語キーワードおよび識別子をサポート: 変数名、関数名、構造体名などを韓国語で記述可能
  • 静的型システム: 整数、実数、文字列、真偽値、なし の5種類の基本型を提供
  • コンパイルおよびインタプリタモード: LLVM IR → clang → バイナリ生成、または即時実行
  • REPLおよびLSPサーバー: hgl repl、hgl lsp コマンドで対話実行とコード補完をサポート
  • 組み込み機能
    • 配列、構造体、クロージャ、パターンマッチング、例外処理、ジェネリクス
    • ファイル I/O、JSON、HTTP、正規表現、日付/時刻、システムコール
    • 書式文字列、ハッシュマップ、数学組み込み関数
  • 18個のサンプルプログラムを同梱: Hello World、HTTP API呼び出しなど

インストールと実行

  • 必須コンポーネント: Rust(1.70+)、clang
  • インストール手順
  • VS Code拡張を提供: シンタックスハイライトとLSPをサポート
  • CLIコマンド
    • hgl interpret <file.hgl> — インタプリタ実行
    • hgl build <file.hgl> — ネイティブバイナリへコンパイル
    • hgl run <file.hgl> — コンパイル後に即時実行
    • hgl repl — 対話モード
    • hgl lsp — LSPサーバー実行

現在の実装状況

  • 完全に動作する機能
    • データ型、制御フロー、関数、文字列、配列、ハッシュマップ、構造体、エラー処理、型検査
    • JSON、HTTP、正規表現、日付/時刻、システム、ファイル I/O、数学関数、モジュール、ジェネリクス
  • 部分実装の機能
    • hgl build 時のクロージャ・文字列・配列メソッドのコード生成は未完成
  • 未実装の機能
    • Null安全性（Option 型なし）、非同期/並列処理、ガベージコレクション、末尾再帰最適化

ハングルとプログラミング

  • ハングルは音韻構造を視覚的に表現した科学的な文字体系で、世宗大王が1443年に創製した
  • Hanはこうしたハングルの構造的な明快さをコード文法に反映している
  • 世界では1,600万人以上が韓国語を学習しており、Hanはコーディングを通じたハングル学習の手段を提供する
  • キーワードの例
    • 関数(function)、もし(if)、反復(for)、戻る(return)、変数(variable)、出力(print) など

設計と構造

  • Rustベースのコンパイラパイプライン
    • Lexer → Parser → AST → Interpreter / CodeGen → LLVM IR → clang → Binary
  • プロジェクト構造
    • src/ — 中核となるコンパイラおよびインタプリタのコード
    • editors/vscode/ — VS Code拡張
    • examples/、spec/、tests/ を含む
  • 設計選択の理由
    • LLVM C APIではなくテキストベースIR生成を採用してビルドを簡素化
    • インタプリタは高速な実行、コンパイラは性能重視
    • Rustのパターンマッチングとメモリ安全性が言語実装に適している

テストとライセンス

  • cargo test で46件のテスト（単体41件、統合5件）を実行
  • MITライセンスで公開

文化的意義

  • Hanはハングルの美しさとプログラミングの精密さを結びつけた実験的な言語
  • 韓国語学習者と開発者の双方に、言語とコードの境界を取り払う新しいアプローチを提示する

関連記事

12件のコメント

 
runableapp 2026-03-17

おかげで有益な情報を得られました。重要なニュースを選んでくれるGeekNewsは、毎日訪れる楽しみがあります。私も現在、ハングルのプログラミング言語を開発している立場として、このような試みが続くことをとても前向きに見ています。

長い海外生活をしながら韓国の変化を見守ってきた立場からすると、日常や産業全般に英語が過度に浸透した現象は、いつも残念に感じていました。パンギョ方言や難解なマンション名、MSGRのようないびつなメニュー、英語だらけの看板は、私たちの言語の自生力を損なっているように見えます。たとえ早期教育で英語の壁が低くなったとしても、母国語が与える直感性は代えがたいものです。まるで海外でハングルの看板がひときわ目に飛び込んでくるように、私たちの脳は母語を処理するときに最も少ないエネルギーを消費するからです。

print("Hello, world!");

出力 "こんにちは!"

どちらのほうが、よりすっと頭に入ってきますか?

AIが言語の壁を取り払いつつありますが、ハングルのプログラミング言語の研究は、私たちの思考体系にある不要な「翻訳レイヤー」を取り除き、脳の効率を最大化する作業です。printよりも「出力」のほうが直感的に感じられるのは当然のことです。汎用性や就職市場の論理のために、すぐ主流になるのは難しいでしょうが、将来はさらに完成度が高く多様なハングル言語が生まれ、生態系を豊かにしてくれることを期待しています。
 
mhcoma 2026-03-16

ハングルだからといって……batmanghijilをやめることはできませんね。
 
coremaker 2026-03-16

シアットプロジェクトを思い出しますね
 
crawler 2026-03-17

開発ではなく会計業務を長くされていた方のようですが、コンパイラを作ってGitHubスターを100個以上も獲得するなんて..
本当にAIの時代が来ましたね
 
savvykang 2026-03-17

async-await ではなく「非同期-待機」でコーディングすると考えると、たしかに楽ですね
 
github88 2026-03-16

プログラミング言語では汎用性が重要なのに……
 
m00nlygreat 2026-03-16

Hacker News の反応が好意的なの、なんだか笑えますね（笑）
 
nottiger 2026-03-16

わあ、すごいですね
 
bichi 2026-03-16

こんにちは、力強くたくましい朝だ！
 
sea715 2026-03-16

わあ
 
xguru 2026-03-16

わあ、Hacker Newsでこういうものを見るのもいいですね。世宗大王様、ありがとうございます。
 
GN⁺ 2026-03-16
Hacker Newsのコメント

  • 韓国語のプログラミング言語に興味があるなら、関数型言語 「Nuri」 を勧めたい。
    Nuri GitHubリンク
    単にキーワードを翻訳するだけのレベルではなく、実際の 韓国語の文法構造をコードに反映できる。
    たとえば「10を5で割って出力する」と書けば、結果として「2」が出力される。
    もう一つの例として「Yaksok」という言語もある。2048ゲームのサンプルコード は全体が韓国語で書かれている。

    • フィードバックに感謝する。「Nuri」も「Yaksok」も 妥当でよく設計された言語だと思うが、私はまず英語話者がRustに翻訳された版に触れられるようにすることに集中している。そのほうがより大きなユーザー層を作れそうだ。
    • 韓国語の単語はほとんど分からないが、「Yaksok」はもしかして日本語の約束（やくそく）と語源が同じ単語なのだろうか。

  • 本当に素晴らしいアイデアだと思う。ハングルは 論理的に設計された文字体系なので、半日あれば学べる。
    ハングル学習用のStackExchange回答

    • こうした 記憶術(mnemonics) は本当に役に立つ。私が書いている韓国語学習ガイド(tolearnkorean.com)にも追加する予定だ。
      ハングルはアルファベット数が英語と似ているので早く覚えられるが、単語の暗記はもう少し難しい。だからAnkiと、私が作ったゲーム型学習アプリを一緒に使っている。
    • これは韓国人ですらよく知らないほど深い知識だ。このサイトをGitHubの参考資料に追加する予定だ。こういう支援者がいてうれしい。
    • そのリンクをREADMEの「Beauty of Hangul」セクションにさっそく追加した。

  • 韓国語ネイティブとして短く意見を述べたい。
    名詞は自然に翻訳できるが、英語の命令形動詞を韓国語に移す際には注意が必要だ。たとえば「find」は「探す」「探し」「探したこと」などにできるが、文脈によっては不自然になりうる。
    また複数形も問題だ。英語は単数・複数を明確に区別するが、韓国語はそうではない。「単語たち」のように複数を明示すると、かえって不自然なことが多い。
    単純なキーワード置換ではなく、英語と韓国語の 構造的な違いを考慮すれば、はるかに強力なプロジェクトになると思う。

  • 大学時代にコンピュータ工学を学びながら、プログラミング言語が英語ベースであることは英語話者にとって 大きな利点だと感じていた。
    留学生の友人たちは英語に慣れていないため、学ぶのにより苦労していた。だからプログラミングを外国語の単位として認めるべきだという冗談がかなり面白かった。

    • 私は逆に考える。英語がよく分からなかった頃でも独学でプログラミングを学べた。結局キーワードは数個しかなく、int が integer の略だと知らなくてもまったく問題なかった。
      本当に難しいのはプログラミングそのものを学ぶことだ。ただし高度な話題や文書が英語でしか提供されていないのは、ESL学習者にとって大きな障壁だ。
    • インドでも英語はIT産業成長の大きな理由だった。地域言語で教育を受けた友人たちは、大学で英語の教科書に追いつくために二倍の努力をしていた。言語の壁が人材の浪費につながる現実が残念だ。
    • 私の非英語圏の友人たちも、キーワードはプログラミングの難しさの1%にも満たないと言っている。変数名やクラス名はすでにUnicodeで書けるので、翻訳する必要はほとんどない。
    • 英語がグローバル標準になったのは合理的だ。多くのプロジェクトでは英語を使うのが自然だ。
    • 本当の問題はキーワードではなく、教科書・論文・文書がすべて英語で書かれていることだ。キーワードをいくつか覚えるだけなら30分で十分だ。

  • 韓国語は分からないが、このスレッドのおかげで 言語学的な洞察をたくさん得られた。
    ハングルの音韻的設計(リンク)、
    韓国語の複数形の特徴(リンク)、
    LLMトークナイザと韓国語の トークン圧縮問題(リンク)、
    そして子音・母音が手の配置で分かれた ハングル配列のリズム感(リンク)が特に興味深かった。

  • こうした試みは 言語の断片化(fragmentation) を招くかもしれないと思う。
    みんながそれぞれの言語でプログラミング言語を作れば、協業や採用が難しくなり、技術共有もしにくくなるだろう。
    個人的には、世界中が一つの言語を使えば戦争や誤解が減ると思う。もちろん文化的多様性は減るだろうが、コミュニケーションの効率性は高まるはずだ。

    • 創作と実験は決して愚かなことではない。作者は芸術的な試みとしてこの言語を作ったのであって、それを政治やビジネスの観点から批判するのは 本質を外した態度だ。
    • それならエスペラントで新しいプログラミング言語を作るという意味か？

  • 単にキーワードを翻訳するというアプローチが興味深い。
    サンプルコードのように

    펀크 투섬(아래이: 목록[정수], 타개트: 정수) -> 목록[정수]:
동안 시작 < 끝:

    こう書けばコードがより 簡潔になるかもしれない。ただし大文字・小文字を区別する利点は失われる。
    言語の密度にかかわらず、情報処理速度は似たようなものだと聞いた。

    • 2000年代初頭には中国語Python翻訳の試みがあった。
      関連ブログ記事
      しかし成功しなかった。すでにほとんどのコンピュータ環境が ラテン文字入力を前提としており、キーワードをいくつか覚えるのも難しくないからだ。
    • いい指摘だ。「Han」は実際の韓国語の単語（関数、もし、など）を使っているが、サンプルの「peongkeu」「araei」のような音訳語を使うと、韓国語話者には不自然に感じられる。
    • ScratchはJSONベースなので多言語切り替えがしやすい。しかしほとんどのプログラマが英語キーワードを維持するのは、文書、ライブラリ、協業環境がすべて英語中心だからだ。
      LLM時代になっても学習データの大半は英語コードなので、英語コードのほうが依然として 効率的である可能性が高い。
    • 日本語の場合は入力モードの切り替えが煩雑なので、プログラミングには 非効率的だ。ハングルでも似た問題があるかもしれない。
    • この例は面白い。

  • 素晴らしいプロジェクトだ。190年ほど前(!)に韓国の大学に通っていて、今は基本的な韓国語しかできないが、サンプルコードを見ながら 新しい単語を学んでいる気分になる。

  • このプロジェクトが本当に気に入った。コードサンプルを見ても何も理解できないのに、非英語圏の開発者が英語ベースの言語を初めて見たとき、どんな感覚だったのかに共感できるようになった。
    Lispは相変わらず括弧天国だが :-)

    • 本当の壁はキーワードではなく、たいていの 文書や議論が英語だけで行われていることだ。
    • 何十年ものあいだ英語を使うのは合理的だった。コメントに感謝する。

  • 中国の Easy Programming Language を思い出した。
    EPLのWikipediaリンク
    約15年前、中国の多くの子どもたちがこの言語で初めてプログラミングを学んだ.